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-labelmit 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-labelledbynichts hat, worauf es zeigen kann. aria-labelledbyauf 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
- Geben Sie der sichtbaren Überschrift des Dialogs eine
idund verweisen Sie mitaria-labelledbydarauf. Sichtbarer und gesprochener Name sind dann gleich. - Ohne Überschrift nehmen Sie
aria-labelmit einem kurzen, genauen Namen – „Cookie-Einstellungen“, nicht „Dialog“. - Verknüpfen Sie bei einem
alertdialogzusätzlich die Meldung mitaria-describedby, damit sie zusammen mit dem Namen vorgelesen wird. - 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
- Ö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.
- Wählen Sie in den Entwicklertools des Browsers den Dialog-Container aus und prüfen Sie seinen Namen im Bereich „Barrierefreiheit“.
- Ö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.
- 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.