ARIA korrekt einsetzen: Häufige Fehler bei Rollen und Attributen vermeiden

Auf Ihrer Seite sind technische Zusatzangaben für Vorlese-Software fehlerhaft gesetzt. Dadurch kann Vorlese-Software einzelne Elemente falsch oder unvollständig ankündigen. EverAudit prüft ARIA-Rollen und -Attribute gegen WCAG 4.1.2 (Name, Role, Value) und meldet Verstöße als kritischen Befund.

Was ist das Problem?#

ARIA (Accessible Rich Internet Applications) ergänzt HTML um zusätzliche Semantik für Screenreader — Rollen (role="dialog"), Zustände (aria-expanded) und Beziehungen (aria-labelledby). Diese Zusatzsprache folgt festen Regeln: Jede Rolle erlaubt nur bestimmte Attribute, manche Rollen verlangen bestimmte Attribute zwingend, und alle Werte müssen einem definierten Vokabular entsprechen.

Vier häufige Fehlertypen fasst diese Kategorie zusammen:

• Ungültige Rolle (aria-roles) — ein Tippfehler oder eine nicht existierende Rolle wie role="buton".
• Ungültiger Attributname (aria-valid-attr) — falsch geschriebene aria-*-Attribute.
• Fehlendes Pflicht-Attribut (aria-required-attr) — z. B. role="checkbox" ohne aria-checked.
• Unzulässiges Attribut für die Rolle (aria-allowed-attr) — ein Attribut, das zur gewählten Rolle nicht passt.

Warum prüft EverAudit das?#

ARIA-Fehler sind besonders tückisch, weil sie visuell unsichtbar sind — die Seite sieht für sehende Besucher völlig normal aus, während Screenreader-Nutzer falsche oder unvollständige Informationen erhalten. EverAudit bündelt diese Regelfamilie als prio1-Befund, weil ein fehlerhaftes ARIA-Attribut ein Element für Screenreader-Nutzer effektiv unbrauchbar machen kann, obwohl es funktional einwandfrei aussieht.

Welche Auswirkung hat das?#

Nutzer von Vorlese-Software erhalten irreführende Angaben und bedienen betroffene Elemente womöglich falsch — etwa ein Kontrollkästchen, dessen aktueller Zustand nicht angesagt wird, oder ein Dialogfenster, das nicht als solches erkannt wird. Das führt zu Fehlbedienungen gerade bei komplexeren, interaktiven Komponenten wie Akkordeons, Tabs oder Custom-Dropdowns — also genau dort, wo native HTML-Semantik allein nicht ausreicht.

Wie beheben Sie ARIA-Fehler?#

Prüfen Sie zuerst, ob natives HTML das ARIA-Konstrukt überhaupt ersetzen kann:

<!-- selbstgebaut, fehleranfällig -->
<div role="button" tabindex="0">Absenden</div>

<!-- besser: natives Element bringt alles mit -->
<button type="submit">Absenden</button>

Ist ein Custom-Widget nötig, Pflicht-Attribute vollständig setzen:

<!-- fehlt: aria-checked -->
<div role="checkbox" tabindex="0">Newsletter abonnieren</div>

<!-- korrigiert -->
<div role="checkbox" aria-checked="false" tabindex="0">Newsletter abonnieren</div>

Ungültige Rollen und Attributnamen korrigieren:

<!-- ungültige Rolle -->
<div role="notification">…</div>

<!-- korrigiert: gültige ARIA-Rolle -->
<div role="alert">…</div>

Konkretes Vorgehen:

1. Native Elemente bevorzugen — <button>, <a href>, <details>, <dialog> lösen viele ARIA-Anforderungen automatisch.
2. Rollen-Referenz prüfen, bevor Sie ein Custom-Widget bauen — welche Attribute sind für diese Rolle zulässig und welche zwingend erforderlich?
3. Zustandsattribute aktuell halten — aria-checked, aria-expanded, aria-selected müssen sich per JavaScript mit dem tatsächlichen UI-Zustand synchronisieren.
4. Tippfehler in Rollen- und Attributnamen ausschließen — ARIA-Vokabular ist exakt festgelegt, keine Varianten oder Abkürzungen.
5. Nach dem Fix mit einem Screenreader gegenprüfen, wo möglich — automatisierte Tests finden strukturelle Fehler, nicht ob die Ansage inhaltlich sinnvoll klingt.

Fazit#

ARIA-Fehler bleiben für sehende Besucher unsichtbar, wirken sich aber direkt auf die Nutzbarkeit für Screenreader-Nutzer aus. Die zuverlässigste Vorbeugung ist, native HTML-Elemente zu bevorzugen und ARIA nur dort einzusetzen, wo native Semantik tatsächlich fehlt — dann konsequent nach den geforderten Attribut-Kombinationen.