Fokussierbares Element in aria-hidden (aria-hidden-focus)

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-hidden auf die Seite dahinter setzen, deren Links aber in der Tab-Reihenfolge lassen.
  • Karussells, die inaktive Folien mit aria-hidden verstecken, 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

  1. 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?
  2. Sehen Sie sich in den Entwicklertools die Barrierefreiheitseigenschaften des fokussierten Elements an. „Ignored“ oder kein Name heißt: vor Hilfstechnik versteckt.
  3. Gehen Sie dieselben Stellen mit laufendem Screenreader durch und achten Sie auf Stille oder Links ohne Zusammenhang.
  4. Ö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.

Verwandte Regeln

  • undefined – Fokus auf etwas, das niemand sieht.
  • undefined – ein Dialog ohne Namen.
  • undefined – fokussierbare Inhalte, wo Hilfstechnik keine erwartet.

Menüs und Dialoge prüfen – kostenloser Scan

Häufige Fragen

Ist aria-hidden="true" an einem Icon falsch?

Nein. Ein dekoratives Icon zu verstecken ist richtig – solange das Icon selbst nicht fokussierbar ist und keinen Link oder Button enthält.

Warum ist inert besser als tabindex="-1"?

inert gilt für alles darin, auch für später hinzugefügte Inhalte, und blockiert zusätzlich Mausklicks. tabindex="-1" müssen Sie an jedem einzelnen Element setzen und wieder entfernen.

Besteht display: none die Regel?

Ja. Nicht angezeigte Inhalte können keinen Fokus bekommen. Es ist die richtige Wahl, wenn der versteckte Inhalt nicht animiert werden muss.

Quellen

  1. W3C, Understanding SC 4.1.2 Name, Role, Value – https://www.w3.org/WAI/WCAG22/Understanding/name-role-value
  2. Deque University, axe-core 4.13 Regel aria-hidden-focus – https://dequeuniversity.com/rules/axe/4.13/aria-hidden-focus
  3. W3C, WAI-ARIA 1.2: aria-hidden – https://www.w3.org/TR/wai-aria-1.2/#aria-hidden
  4. MDN, HTML-Attribut inert – https://developer.mozilla.org/de/docs/Web/HTML/Global_attributes/inert

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.