Häufige Probleme mit ARIA

ARIA (Accessible Rich Internet Applications) besteht aus einer Reihe von Rollen und Attributen, die dabei helfen können, Web-Inhalte barrierefrei für Menschen mit Beeinträchtigung aufzubereiten. Die aktuelle Version WAI-ARIA 1.2 wurde im Dezember 2021 vom W3C veröffentlicht. Im Prinzip sind sie hilfreich, aber es gilt der Grundsatz: No ARIA is better than Bad ARIA! Man sollte grundsätzlich native HTML-Elemente und -Attribute mit der gewünschten Semantik und Funktionalität verwenden.

Dies sind die häufigsten Fehler bei der Nutzung von ARIA.

Mit aria-hidden=“true“ ein fokussierbares Element verbergen

ARIA gibt die volle Kontrolle über den Accessibility Tree. Dieser stellt eine angepasste Version des DOM für assistive Technologien dar. Das Attribut aria-hidden ermöglicht, ein Element aus dem Accessibility Tree zu entfernen und es somit vor Screenreader-Nutzer:innen zu verbergen. Das Problem dabei: Wenn ein fokussierbares Element, wie etwa einen Link, aus dem Accessibility Tree entfernt wird, verbleibt das Element dennoch in der Tab-Reihenfolge. Wenn ein:e Screenreader-Nutzer:in mit der Tab-Taste navigiert und damit den Link fokussiert, wird der Screenreader „leer“ oder etwas ähnliches vorlesen. Bitte nicht machen!

Ein aria-label definieren, das nicht dem sichtbaren Label entspricht

Als Beispiel: die Website wird von jemandem mit einer Spracheingabe-Software bedient. Die Person kommt zu einem Formular, das so aussieht:

<form action="">
    <div class="form-field">
        <label for="firstname">Vorname</label>
        <input type="text" aria-label="First Name" name="firstname" id="firstname">
    </div>
    <div class="form-field">
        <label for="lastname">Nachname</label>
        <input type="text" aria-label="Last Name" name="lastname" id="lastname">
    </div>
    <!-- Other fields -->
</form>

Um das Formular auszufüllen, möchte die Person das erste Eingabefeld mit der sichtbaren Beschriftung „Vorname“ auswählen. Sie sagt den Sprachbefehl „Vorname klicken“, doch nichts passiert. Warum?
Wie der Code oben zeigt, ist das label Element programmatisch mit dem Eingabefeld über das for Attribut verknüpft. Allerdings überschreibt das aria-label Attribut den programmatischen Namen des input Elements mit „First Name“. Das heißt, der Name des Bedienelements enthält nicht die sichtbare Beschriftung.

Das aria-labelledby Attribut verweist auf eine ID, die nicht existiert

Mit dem aria-labelledby Attribut kann man ein HTML-Element programmatisch beschriften, indem man auf ein anderes Element verweist. Code-Beispiel:

<nav aria-labelledby="sidenav-title">
    <h2 id="sidenav-title">Related Content</h2>
    <ul>
        <!-- List of links -->
    </ul>
</nav>

Falls kein Element mit der ID „sidenav-title“ im DOM vorhanden wäre, würde das nav Element keine programmatische Beschriftung erhalten. Die Folge wäre eine suboptimale Erfahrung für Screenreader-Nutzer:innen.

Navigations-Menü mit role=“menubar“ oder role=“menu“

Viele Websites enthalten eine Seitennavigation, die wie eine Menüleiste mit ausklappbaren Untermenüs gestylt ist. Aufgrund dieser visuellen Darstellung denken viele Web-Entwickler:innen, dass sie die folgenden semantischen Rollen setzen sollten:

<ul role="menubar">
    <li role="none">
        <a role="menuitem" href="/">Home</a>
    </li>
    <li role="none">
        <a role="menuitem" aria-haspopup="true" aria-expanded="false" href="#">About</a>
        <ul role="menu" aria-label="About">
            <li role="none">
                <a role="menuitem" href="/overview">Overview</a>
            </li>
            <li role="none">
                <a role="menuitem" href="/administration">Administration</a>
            </li>
        </ul>
    </li>
</ul>

Allerdings wecken diese semantischen Rollen eine gewisse Erwartungshaltung bei den Nutzer:innen. Die Rollen menubar und menusind für Menü-Widgets gedacht, die den Nutzer:innen eine Liste an Aktionen anbieten und wie Menüs von Betriebssystemen bedienbar sind. Das heißt: Sie sollten ein konkretes Set an Tastatur-Interaktionen implementieren.

Wenn man zum Beispiel eine Seitennavigation mit role=“menubar“ definiert, dann erwarten Screenreader-Nutzer:innen, das Menü mit den Pfeiltasten bedienen zu können. Wenn das nicht funktioniert, dann sorgt das für Verwirrung. Eine bessere Alternative ist die Anwendung des Disclosure Pattern für die Seitennavigation.

Grundregeln für den Einsatz von ARIA

  1. Verwende immer native HTML-Elemente, wenn möglich.
  2. Verändere nicht die Semantik von nativen Elementen, außer es ist wirklich notwendig.
  3. Setze ARIA bei Custom Widgets ein und befolge die Vorgaben im Authoring Practices Guide.
  4. Alle interaktiven ARIA-Bedienelemente müssen auch mit der Tastatur bedienbar sein.
  5. Teste den Code mit assistiven Technologien wie Screenreadern und Spracheingabe-Software.

Nützliche Links

Quelle: Häufige Probleme mit ARIA und wie ihr diese vermeidet

nach oben