Häufige Probleme mit ARIA und wie ihr diese vermeidet
Du willst also deine Website barrierefrei machen? Sehr gut! Und du hast bereits von ARIA gehört, also Accessible Rich Internet Applications. Na, dann pflastern wir doch einfach alles mit ARIA-Attributen zu und die Website ist barrierefrei, oder? Falsch!
Wenn du nicht weißt, was du tust, wird deine Website am Ende weniger barrierefrei sein! Es gibt einen guten Grund, warum die erste Regel von ARIA lautet: No ARIA is better than Bad ARIA! Ihr solltet grundsätzlich native HTML-Elemente und -Attribute mit der gewünschten Semantik und Funktionalität verwenden.
Foto: © Ketut Subiyanto / pexels.com
Sehen wir uns gemeinsam an, welche Anwendungsfälle es für ARIA gibt und welche verbreiteten Fehler ihr vermeiden solltet.
ARIA, wozu ist das gut?
ARIA besteht aus einer Reihe von Rollen und Attributen, die euch 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.
Personen mit Beeinträchtigungen oder Behinderungen nutzen assistive Technologien, um mit Web-Inhalten zu interagieren. Zum Beispiel surfen blinde Menschen mithilfe von Screenreadern im Internet. Personen mit motorischer Beeinträchtigung können Spracheingabe-Software verwenden, um mit einer Website zu interagieren.
Web-Entwickler:innen können ARIA-Rollen und -Attribute verwenden, um Nutzer:innen assistiver Technologien die Semantik der Inhalte zu vermitteln. Ihr könnt aria-expanded auf ein Element setzen, um anzuzeigen, ob der verknüpfte Bereich ein- oder ausgeklappt ist. Das Attribut aria-selected vermittelt, ob zum Beispiel ein Tab aktuell ausgewählt ist oder nicht.
<h3>
<button type="button" aria-expanded="false" aria-controls="section1" id="header1">
Personal Information
</button>
</h3>
<div id="section1" role="region" aria-labelledby="header1">
<!-- Panel content that is shown/hidden via button -->
</div>
Grundsätzlich solltet ihr ARIA nur für Custom Widgets wie etwa einen ausklappbaren Bereich verwenden. Seht euch den ARIA Authoring Practices Guide an. Dieser beschreibt detailliert, wie ihr semantische Informationen bei üblichen Design-Mustern und Widgets vermitteln solltet.
Häufige Fehler bei der Nutzung von ARIA
Ich habe bereits hunderte Websites auf Barrierefreiheit überprüft. Dabei ist mir aufgefallen: Viele Web-Entwickler:innen haben offensichtlich keine Ahnung was sie tun! Sie verstopfen das DOM mit ARIA-Rollen und -Attributen als ob es kein Morgen gäbe. Ich zeige euch einige der häufigsten Fehler, auf die ich gestoßen bin.
Mit aria-hidden="true" ein fokussierbares Element verbergen
ARIA gibt euch 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 euch, ein Element aus dem Accessibility Tree zu entfernen und es somit vor Screenreader-Nutzer:innen zu verbergen.
<a href="https://www.stuff.com" aria-hidden="true">Interesting Stuff</a>
Das Problem dabei: Wenn ihr ein fokussierbares Element, wie etwa einen Link, aus dem Accessibility Tree entfernt, dann 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 tut ihnen das nicht an!
Ein aria-label definieren, das nicht dem sichtbaren Label entspricht
Stellt euch vor, ihr seid ein Uni-Student in Wien und wollt euch online für eine Vorlesung anmelden. Wegen eines Handtremors wollt ihr die Website mit eurer Spracheingabe-Software bedienen. Ihr findet folgendes Web-Formular vor:
<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, wollt ihr das erste Eingabefeld mit der sichtbaren Beschriftung „Vorname“ auswählen. Also sagt ihr den Sprachbefehl „Vorname klicken“, doch nichts passiert. Was ist hier los?
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 Formular ist somit für Nutzer:innen von Spracheingabe-Software schwer bedienbar und es liegt ein klarer WCAG-Verstoß vor. Übrigens: Es handelt sich um ein echtes Beispiel eines Web-Formulars auf der Website einer großen Universität in Wien.
Das aria-labelledby Attribut verweist auf eine ID, die nicht existiert
Mit dem aria-labelledby Attribut könnt ihr ein HTML-Element programmatisch beschriften, indem ihr auf ein anderes Element verweist. Der Wert sollte eine Liste von einer oder mehreren IDs sein, die auf das Element verweisen, mit dem ihr das aktuelle Element beschriften möchtet. Ein 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. Deshalb prüft bitte genau, ob das mit aria-labelledby referenzierte Element tatsächlich vorhanden ist.
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 menu sind 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 ihr 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
Wie wir gesehen haben, kann bei ARIA sehr viel schiefgehen. Diese Liste an Grundregeln wird euer Leben einfacher machen:
- Verwendet immer native HTML-Elemente, wenn möglich.
- Verändert nicht die Semantik von nativen Elementen, außer es ist wirklich notwendig.
- Setzt ARIA bei Custom Widgets ein und befolgt die Vorgaben im Authoring Practices Guide.
- Alle interaktiven ARIA-Bedienelemente müssen auch mit der Tastatur bedienbar sein.
- Testet euren Code mit assistiven Technologien wie Screenreadern und Spracheingabe-Software.
Nützliche Links
Erstellt am