Unzulässiges ARIA-Attribut (aria-allowed-attr)

Die Regel aria-allowed-attr meldet ein ARIA-Attribut an einem Element, dessen Rolle es nicht unterstützt – aria-selected an einem einfachen <button>, aria-checked an einem Link. Browser geben einen solchen Zustand nicht weiter; die Information, die Sie geben wollten, kommt nie an. Die Lösung ist entweder die richtige Rolle für das Widget oder das Attribut, das diese Rolle unterstützt.

Was die Regel bedeutet

WAI-ARIA 1.2 legt für jede Rolle fest, welche Zustände und Eigenschaften sie unterstützt [3]. Globale Attribute wie aria-label, aria-describedby oder aria-hidden funktionieren fast überall. Widget-Zustände nicht: aria-selected gehört zu tab, option, row, gridcell und einigen weiteren; aria-checked zu checkbox, radio, switch und den ankreuzbaren Menüeinträgen; aria-pressed zu button. Maßgeblich ist die tatsächliche Rolle des Elements – im role-Attribut oder die, die HTML ihm gibt: <button> ist ein Button, <a href> ein Link, <li> ein Listeneintrag.

axe meldet jedes Attribut als Fehler, das nicht auf der Liste der Rolle steht. Einen Menschen fragt es, wenn das Attribut in ARIA 1.2 veraltet ist, etwa aria-grabbed oder aria-dropeffect, und wenn es die Rolle eines unbekannten eigenen Elements nicht sicher bestimmen kann.

Zwei verwandte Probleme prüfen andere axe-Regeln: einen falsch geschriebenen Attributnamen (aria-labeledby) und einen Namen an einem Element, das keinen tragen darf, etwa aria-label an einem einfachen <div>. aria-allowed-attr lässt beides durch.

Wen es betrifft

Wer einen Screenreader nutzt, erfährt die Rolle und nichts weiter: „Bewertungen, Schalter“ statt „Bewertungen, Registerkarte, ausgewählt, 2 von 3“. Welcher Tab aktiv ist oder auf welcher Seite der Navigation man steht, bleibt offen. Wer per Sprache steuert, kann das Element womöglich nicht so ansprechen, wie es aussieht. Alle, die sich auf den Barrierefreiheitsbaum verlassen, bekommen weniger, als Sehende mit der Maus sehen.

Warum die Prüfung anschlägt

  • Tabs aus einfachen Buttons, mit aria-selected an jedem Button, aber ohne role="tab" oder role="tablist".
  • Navigation, die die aktuelle Seite mit aria-selected="true" am Link markiert statt mit aria-current="page".
  • Umschalt-Buttons mit aria-checked, obwohl ein Button aria-pressed unterstützt.
  • Akkordeon- oder Menüeinträge mit aria-expanded am <li> statt am Button darin.
  • Eine Rolle, die beim Umbau entfernt oder geändert wurde, während die Attribute blieben.
  • Kopierte Code-Schnipsel aus einer älteren ARIA-Version mit veralteten Attributen wie aria-grabbed.

So beheben Sie es

  1. Klären Sie, was das Widget ist: eine Gruppe von Tabs, ein Umschalter, eine Navigation. Schlagen Sie das Muster im ARIA Authoring Practices Guide nach [5].
  2. Geben Sie jedem Element die Rolle, die das Muster vorsieht; dann ist das Attribut gültig.
  3. Oder lassen Sie das Element, wie es ist, und tauschen Sie das Attribut gegen eines, das seine Rolle unterstützt – aria-pressed am Button, aria-current am Link.
<!-- Vorher: einfache Buttons mit einem Zustand, den nur Tabs kennen -->
<div class="reiter">
  <button class="reiter__tab ist-aktiv" aria-selected="true">Technische Daten</button>
  <button class="reiter__tab" aria-selected="false">Bewertungen</button>
</div>
<div class="reiter__panel" id="panel-daten"><p>Gewicht: 1,2 kg</p></div>
<!-- Nachher: Tab-Rollen, damit aria-selected unterstützt und angesagt wird -->
<div class="reiter" role="tablist" aria-label="Produktdetails">
  <button class="reiter__tab" role="tab" id="tab-daten" aria-selected="true"
          aria-controls="panel-daten">Technische Daten</button>
  <button class="reiter__tab" role="tab" id="tab-bewertungen" aria-selected="false"
          aria-controls="panel-bewertungen" tabindex="-1">Bewertungen</button>
</div>
<div class="reiter__panel" role="tabpanel" id="panel-daten" aria-labelledby="tab-daten"><p>Gewicht: 1,2 kg</p></div>
<div class="reiter__panel" role="tabpanel" id="panel-bewertungen" aria-labelledby="tab-bewertungen" hidden><p>4,6 von 5</p></div>

Die aktuelle Seite in einer Navigation braucht keine neue Rolle, nur das Attribut, das ein Link unterstützt:

<!-- Vorher: Links können nicht "ausgewählt" sein -->
<nav aria-label="Hauptmenü"><a href="/shop/" aria-selected="true">Shop</a> <a href="/ueber-uns/">Über uns</a></nav>
<!-- Nachher: aria-current ist an jedem Element erlaubt -->
<nav aria-label="Hauptmenü"><a href="/shop/" aria-current="page">Shop</a> <a href="/ueber-uns/">Über uns</a></nav>

Eine Rolle bringt Tastaturverhalten mit: Tabs wechselt man mit den Pfeiltasten. Wer role="tab" ohne dieses Verhalten ergänzt, behebt die Regel und lässt das Widget halb fertig.

So prüfen Sie es von Hand

  1. Wählen Sie das Element in den Entwicklertools Ihres Browsers aus und öffnen Sie den Bereich „Barrierefreiheit“: Ein nicht unterstütztes Attribut fehlt dort bei den Zuständen.
  2. Gehen Sie mit einem Screenreader wie NVDA (kostenlos) oder VoiceOver zu den Tabs oder zur Navigation und achten Sie auf „ausgewählt“ oder „aktuelle Seite“.
  3. Prüfen Sie bei einem Widget mit neuer Rolle auch das Tastaturmuster – Pfeiltasten bei Tabs, Leertaste oder Enter bei Umschaltern.
  4. Was die Regel nicht sieht: ob die gewählte Rolle die richtige für das Widget ist.

Zugehöriges WCAG-Kriterium

4.1.2 Name, Rolle, Wert, Stufe A: Rollen und Zustände müssen korrekt weitergegeben werden. Eine Tab-Gruppe, die nicht als solche angesagt wird, verliert außerdem Struktur nach 1.3.1 Info und Beziehungen.

So meldet Reviseberg diese Regel

Reviseberg führt aria-allowed-attr auf jeder gecrawlten Seite aus. In der Befundliste steht die Regel mit Schweregrad, WCAG 4.1.2 und Stufe A, der Zahl der Elemente und Seiten und den Punkten, die ein Fix zurückbringt. Im Detail sehen Sie Selektor, HTML-Ausschnitt mit dem Attribut und alle betroffenen Seiten. Veraltete Attribute und unklare Rollen landen in der Warteschlange „Mögliche Probleme“. Dort entscheidet ein Mensch; sie kosten nichts und zählen nie als bestanden. Befunde können Sie mit Begründung als „ignorieren“, „nicht behebbar“ oder „Fehlalarm“ markieren; jede Entscheidung wird protokolliert.

Verwandte Regeln

  • undefined – das Attribut ist erlaubt, sein Wert aber nicht.
  • undefined – ein Zustand, den die Rolle braucht, fehlt.
  • undefined – ein tab außerhalb einer tablist oder eine option außerhalb einer listbox.

Website auf nicht unterstütztes ARIA prüfen – kostenloser Scan

Häufige Fragen

Ist aria-label an einem <div> erlaubt?

aria-allowed-attr hat nichts dagegen, weil aria-label ein globales Attribut ist. Ein <div> ohne Rolle darf aber keinen Namen tragen, und Browser ignorieren das Label oft. Geben Sie ihm eine Rolle oder zeigen Sie den Text sichtbar an.

Warum ist aria-current in Ordnung, aria-selected aber nicht?

aria-current ist global und genau dafür gedacht: die aktuelle Seite, den aktuellen Schritt oder das aktuelle Datum in einer Reihe. aria-selected ist ein Widget-Zustand für Tabs, Optionen und Ähnliches.

Kann ich das Attribut einfach entfernen?

Wenn es nichts trug, was die Rolle ausdrücken kann, ja. Trug es echte Information – welcher Tab offen ist –, geben Sie dem Element lieber die richtige Rolle. Sonst verschwindet diese Information.

Prüft die Regel meine eigenen Elemente (Custom Elements)?

Ja, wenn sie eine role haben. Ohne Rolle weiß axe nicht, welche Attribute erlaubt sind, und fragt einen Menschen.

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-allowed-attr – https://dequeuniversity.com/rules/axe/4.13/aria-allowed-attr
  3. W3C, Accessible Rich Internet Applications (WAI-ARIA) 1.2 – https://www.w3.org/TR/wai-aria-1.2/
  4. W3C, ACT-Regel: ARIA state or property is permitted – https://www.w3.org/WAI/standards-guidelines/act/rules/5c01ea/
  5. W3C, ARIA Authoring Practices Guide: Tabs Pattern – https://www.w3.org/WAI/ARIA/apg/patterns/tabs/

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.