Die Regel aria-hidden-focus meldet Inhalte, die mit aria-hidden="true" vor Hilfstechnik versteckt sind, aber trotzdem den Tastaturfokus bekommen. Screenreader-Nutzende tabben auf einen Link, den es für ihre Software nicht gibt – und hören nichts oder etwas ohne Zusammenhang. Die Lösung: den Inhalt auch vor der Tastatur verstecken, meist mit dem Attribut inert.
Was die Regel bedeutet
aria-hidden="true" entfernt ein Element und alles darin aus dem Barrierefreiheitsbaum. Aus der Tab-Reihenfolge entfernt es nichts. Ein Link darin bekommt also weiter den Fokus, aber Hilfstechnik soll ihn ignorieren: Name, Rolle und Zweck sind verschwunden. Das verletzt 4.1.2, das für jedes Bedienelement einen Namen und eine Rolle verlangt.
Die Regel ist erfüllt, wenn jedes fokussierbare Element in einem aria-hidden-Container aus der Tab-Reihenfolge genommen ist – durch inert, disabled, tabindex="-1" oder durch Verstecken mit display: none oder visibility: hidden.
Wen es betrifft
Zuerst Screenreader-Nutzende: Der Fokus landet dort, wo ihre Software die Beschreibung verweigert. Sehende Tastatur-Nutzende trifft es auch, wenn der versteckte Inhalt zugleich außerhalb des Bildschirms liegt – jeder Tab-Halt in einem geschlossenen Menü ist einer, den sie nicht sehen.
Warum die Prüfung anschlägt
- Off-Canvas-Menüs, die geschlossen
aria-hidden="true"tragen, deren Links aber tabbar bleiben. - Modale Dialoge, die
aria-hiddenauf die Seite dahinter setzen, deren Links aber in der Tab-Reihenfolge lassen. - Karussells, die inaktive Folien mit
aria-hiddenverstecken, während Links und Buttons darin fokussierbar bleiben. - Dekorative Hüllen um Icons, die einen echten Link oder Button enthalten.
- Kopien für Animationen – ein doppelter Lauftext, vor Screenreadern versteckt, samt Links.
So beheben Sie es
Setzen Sie inert auf alles, was Sie verstecken: Es nimmt den Inhalt mit einem Attribut aus der Tab-Reihenfolge und aus dem Barrierefreiheitsbaum, und alle aktuellen Browser unterstützen es.
<!-- Vorher: vor Screenreadern versteckt, per Tab weiter erreichbar -->
<nav class="offcanvas" aria-label="Menü" aria-hidden="true">
<a href="/shop/">Shop</a>
<a href="/konto/">Mein Konto</a>
</nav>
<!-- Nachher: inert versteckt es vor beiden, bis das Menü aufgeht -->
<nav class="offcanvas" aria-label="Menü" inert>
<a href="/shop/">Shop</a>
<a href="/konto/">Mein Konto</a>
</nav>
Öffnet sich das Menü, entfernen Sie inert wieder (menu.inert = false). Bei einem modalen Dialog macht <dialog> mit showModal() den Rest der Seite von selbst inert. Müssen Sie aria-hidden behalten, setzen Sie tabindex="-1" auf jedes fokussierbare Kindelement – und stellen es später wieder her.
So prüfen Sie es von Hand
- Schließen Sie alle Menüs, Dialoge und Karussell-Folien und gehen Sie die Seite mit Tab durch. Landet der Fokus auf etwas, das Sie nicht sehen?
- Sehen Sie sich in den Entwicklertools die Barrierefreiheitseigenschaften des fokussierten Elements an. „Ignored“ oder kein Name heißt: vor Hilfstechnik versteckt.
- Gehen Sie dieselben Stellen mit laufendem Screenreader durch und achten Sie auf Stille oder Links ohne Zusammenhang.
- Öffnen Sie die Komponenten wieder und prüfen Sie, dass ihr Inhalt erreichbar ist, sobald er sichtbar ist.
Zugehöriges WCAG-Kriterium
4.1.2 Name, Rolle, Wert, Stufe A. Verwandt: 2.4.3 Fokus-Reihenfolge, weil der Fokus Inhalte besucht, die eigentlich nicht da sind, und 1.3.1 Info und Beziehungen.
So meldet Reviseberg diese Regel
Reviseberg führt aria-hidden-focus auf jeder gecrawlten Seite aus. In der Befundliste steht die Regel mit Schweregrad, WCAG 4.1.2, der Zahl der betroffenen Elemente und Seiten und den Punkten, die ein Fix zurückbringt; im Detail sehen Sie Selektor und HTML-Ausschnitt des versteckten Containers. Weil die Ursache meist eine Komponente im Template ist, behebt ein Fix oft alle Seiten auf einmal. Liegt der versteckte Inhalt zusätzlich außerhalb des Bildschirms, zeigt der Durchlauf des Tastatur-Agenten dasselbe Menü auf der von Ihnen festgelegten Reise womöglich als undefined.