Dialog ohne zugänglichen Namen (aria-dialog-name)

Die Regel aria-dialog-name meldet ein Element mit role="dialog" oder role="alertdialog", das keinen zugänglichen Namen hat. Öffnet sich der Dialog, sagt ein Screenreader „Dialog“ und nichts darüber, wofür er da ist. Die Lösung ist fast immer ein einziges Attribut: aria-labelledby, das auf die sichtbare Überschrift des Dialogs zeigt.

Was die Regel bedeutet

Ein Dialog ist ein Fenster über der Seite: ein Cookie-Banner, ein Login-Formular, eine Rückfrage „Artikel entfernen?“, ein ausklappender Warenkorb. Sein Name ist das, was assistive Technologien vorlesen, wenn der Fokus hineinspringt. axe akzeptiert drei Wege, ihn zu vergeben:

  • aria-labelledby, das auf ein Element mit Text zeigt, meist die Überschrift;
  • aria-label mit dem Namen als Text, wenn es keine sichtbare Überschrift gibt;
  • ein nicht leeres title-Attribut – gültig, aber der schwächste der drei Wege.

Die Regel prüft nur Elemente mit ausdrücklichem role="dialog" oder role="alertdialog", und nur solange sie angezeigt werden. Ein natives <dialog>-Element ohne role-Attribut prüft sie gar nicht, obwohl es genauso einen Namen braucht.

Das ist eine Best Practice, kein eigener WCAG-Verstoß. Sachlich gehört sie zu zwei Kriterien: 4.1.2 Name, Rolle, Wert, weil ein Dialog ein Bedienelement ist, dessen Name für assistive Technologien verfügbar sein soll, und 2.4.6 Überschriften und Beschriftungen, weil ein Name nur hilft, wenn er den Zweck des Dialogs beschreibt.

Wen es betrifft

Vor allem blinde und sehbehinderte Menschen, die einen Screenreader nutzen. Springt der Fokus in einen namenlosen Dialog, hören sie „Dialog“ und dann das Element, das den Fokus bekommen hat – oft nur „Schließen, Schalter“. Ob der Dialog eine Einwilligung, ein Passwort oder die Bestätigung einer Löschung will, müssen sie erst erkunden. Auch wer mit Bildschirmlupe nur einen Ausschnitt sieht, profitiert von einem klaren Namen.

Warum die Prüfung anschlägt

  • Modal-Bibliotheken und UI-Kits, die role="dialog" an den Container setzen, die Benennung aber dem Entwickler überlassen – und der übergibt nie einen Titel.
  • Cookie-Banner, als Dialog gebaut, mit einer Überschrift, die nicht mit dem Container verknüpft ist.
  • Eine sichtbare Überschrift ohne ID, sodass aria-labelledby nichts hat, worauf es zeigen kann.
  • aria-labelledby auf eine ID, die es nicht gibt, weil die Überschrift umbenannt oder entfernt wurde.
  • Bestätigungsdialoge (role="alertdialog") mit nur einer Meldung und zwei Buttons.
  • Chat- und Newsletter-Pop-ups, die Skripte von Drittanbietern einfügen.

So beheben Sie es

  1. Geben Sie der sichtbaren Überschrift des Dialogs eine id und verweisen Sie mit aria-labelledby darauf. Sichtbarer und gesprochener Name sind dann gleich.
  2. Ohne Überschrift nehmen Sie aria-label mit einem kurzen, genauen Namen – „Cookie-Einstellungen“, nicht „Dialog“.
  3. Verknüpfen Sie bei einem alertdialog zusätzlich die Meldung mit aria-describedby, damit sie zusammen mit dem Namen vorgelesen wird.
  4. Beheben Sie es einmal in der Modal-Komponente; jeder Dialog, der darauf aufbaut, erbt den Namen.
<!-- Vorher: Der Dialog hat eine Überschrift, aber nichts verbindet sie mit ihm -->
<div class="cookie-modal" role="dialog" aria-modal="true">
  <h2 class="cookie-modal__titel">Cookie-Einstellungen</h2>
  <p>Wir nutzen nur Cookies, die den Shop am Laufen halten.</p>
  <button class="btn btn--primaer">Notwendige Cookies akzeptieren</button>
</div>
<!-- Nachher: aria-labelledby benennt den Dialog nach seiner sichtbaren Überschrift -->
<div class="cookie-modal" role="dialog" aria-modal="true" aria-labelledby="cookie-titel">
  <h2 class="cookie-modal__titel" id="cookie-titel">Cookie-Einstellungen</h2>
  <p>Wir nutzen nur Cookies, die den Shop am Laufen halten.</p>
  <button class="btn btn--primaer">Notwendige Cookies akzeptieren</button>
</div>

Ein natives <dialog> braucht denselben Namen, auch wenn diese Regel es nicht prüft:

<!-- Natives dialog-Element: genauso benennen -->
<dialog class="rueckfrage" aria-labelledby="rueckfrage-titel" aria-describedby="rueckfrage-text">
  <h2 id="rueckfrage-titel">Artikel entfernen?</h2>
  <p id="rueckfrage-text">Die Wanderschuhe werden aus Ihrem Warenkorb entfernt.</p>
  <button>Entfernen</button> <button>Abbrechen</button>
</dialog>

So prüfen Sie es von Hand

  1. Öffnen Sie jeden Dialog der Seite – Cookie-Banner, Login, Warenkorb, Rückfragen. Die Regel sieht nur Dialoge, die während der Prüfung angezeigt werden.
  2. Wählen Sie in den Entwicklertools des Browsers den Dialog-Container aus und prüfen Sie seinen Namen im Bereich „Barrierefreiheit“.
  3. Öffnen Sie den Dialog mit einem Screenreader wie NVDA (kostenlos) oder VoiceOver und hören Sie hin: Beim Hineinspringen sollten Name und „Dialog“ angesagt werden.
  4. Prüfen Sie, ob der Name sagt, wofür der Dialog da ist. „Modal“ oder „Popup“ bestehen die Regel und helfen niemandem.

Zugehöriges WCAG-Kriterium

Keines direkt – aria-dialog-name ist eine Best Practice. Sachlich gehört sie zu 4.1.2 Name, Rolle, Wert und 2.4.6 Überschriften und Beschriftungen. Ein Dialog, der den Tastaturfokus festhält oder verliert, ist eine eigene Frage nach 2.1.2 Keine Tastaturfalle.

So meldet Reviseberg diese Regel

Reviseberg führt aria-dialog-name auf jeder gecrawlten Seite aus. In der Befundliste steht die Regel als Best Practice mit Schweregrad, der Zahl der Elemente und Seiten und den Punkten, die ein Fix zurückbringt; sie zählt nie gegen ein WCAG-Kriterium und erscheint in keinem Konformitätsbericht und keiner Erklärung zur Barrierefreiheit. Im Detail sehen Sie Selektor und HTML-Ausschnitt jedes Dialogs und alle betroffenen Seiten. Die Regel sieht nur Dialoge, die beim Scannen der Seite angezeigt werden: Ein Cookie-Banner, das beim Aufruf erscheint, wird geprüft, ein Dialog, der bis zu einem Klick versteckt bleibt, nicht – den prüfen Sie von Hand. Befunde können Sie mit Begründung als „ignorieren“, „nicht behebbar“ oder „Fehlalarm“ markieren, etwa bei einem Widget eines Drittanbieters, das Sie nicht ändern können; jede Entscheidung wird protokolliert.

Verwandte Regeln

  • undefined – der Schließen-Button im Dialog hat oft auch keinen Namen.
  • undefined – Inhalt hinter einem offenen Modal, per aria-hidden versteckt, aber per Tastatur erreichbar.
  • undefined – die Prüfung des Tastatur-Agenten auf Fokus, der eine Komponente nicht mehr verlassen kann.

Dialoge Ihrer Website prüfen – kostenloser Scan

Häufige Fragen

Ist ein Dialog ohne Namen ein WCAG-Verstoß?

axe-core führt aria-dialog-name als Best Practice, und so meldet Reviseberg die Regel auch. Sie unterstützt 4.1.2 und 2.4.6, und Screenreader-Nutzende merken den Unterschied sofort.

Soll ich aria-label oder aria-labelledby nehmen?

aria-labelledby, wo immer der Dialog eine sichtbare Überschrift hat – dann passt der gesprochene Name zu dem, was man sieht. aria-label nur, wenn es keine Überschrift gibt.

Warum meldet die Regel mein <dialog>-Element nicht?

Sie prüft nur Elemente mit ausdrücklichem role="dialog" oder role="alertdialog". Ein natives <dialog> ist trotzdem ein Dialog – benennen Sie es mit aria-labelledby.

Gibt aria-modal="true" dem Dialog einen Namen?

Nein. Es sagt assistiven Technologien, dass der Inhalt dahinter gesperrt ist; der Name muss weiterhin aus aria-labelledby, aria-label oder title kommen.

Quellen

  1. Deque University, axe-core 4.13 Regel aria-dialog-name – https://dequeuniversity.com/rules/axe/4.13/aria-dialog-name
  2. W3C, ARIA Authoring Practices Guide: Dialog (Modal) Pattern – https://www.w3.org/WAI/ARIA/apg/patterns/dialog-modal/
  3. W3C, Accessible Rich Internet Applications (WAI-ARIA) 1.2, Rolle dialog – https://www.w3.org/TR/wai-aria-1.2/#dialog
  4. W3C, Understanding SC 4.1.2 Name, Role, Value – https://www.w3.org/WAI/WCAG22/Understanding/name-role-value
  5. W3C, Understanding SC 2.4.6 Headings and Labels – https://www.w3.org/WAI/WCAG22/Understanding/headings-and-labels

Sehen Sie, was ein Scan auf Ihrer Website findet

Eine Seite in rund 30 Sekunden, ohne E-Mail. Der vollständige Bericht umfasst bis zu 100 Seiten und einen Tastatur-Durchlauf.