WAI-ARIA
WAI-ARIA (Web Accessibility Initiative - Accessible Rich Internet Applications) ist ein empfohlener Webstandard des W3C.[1] Er soll HTML, aber auch SVG, und besonders Webanwendungen besser zugänglich machen, insbesondere für blinde Anwender, die Screenreader verwenden.[2][3]
Dies erreicht WAI-ARIA, indem dem HTML-Markup weitere Attribute hinzufügt werden, die von Browsern und unterstützenden Technologien erkannt und verwendet werden können, um den Benutzern mitzuteilen, was vor sich geht.
Nötig geworden ist WAI-ARIA erst durch die schlechte Angewohnheit, native HTML-Elemente durch Eigenkreationen oder Komponenten aus Frameworks zu ersetzen. So vermeiden viele Profis den Einsatz des button-Elements, da „es so schwierig zu stylen sei“. Ben Myers zeigt in einem Tutorial, wie man ein div zu einem button umbauen kann und wie viele Zeilen JavaScript dafür nötig sind.[4]
Für solche Anwendungsfälle rüstet WAI-ARIA die Semantik und damit die Zugänglichkeit nach. WAI-ARIA kann HTML also ergänzen und verbessern, wichtig ist aber auch, ob Browser und andere Ausgabegeräte wie Screenreader WAI-ARIA überhaupt verstehen. Hier bietet PowerMapper Übersichtstabellen.[5]
Inhaltsverzeichnis
Die 5 ARIA-Regeln
Für viele Webdesigner und Programmierer bleibt Barrierefreiheit ein Buch mit sieben Siegeln, das sie eigentlich überhaupt gar nicht aufschlagen wollen.[6] Dabei gibt es bereits heute eine gesetzliche Pflicht auf der europäischen, aber auch der nationalen Ebene.
Wie tief muss man sich jetzt einarbeiten? Viele Experten empfehlen den 80-20-Ansatz des Pareto-Prinzips[7]. 80% aller Problme können in relativ kurzer Zeit gelöst werden, für die verbleibenden 20% steigt der Aufwand immer mehr an.[8] [9]
Deshalb wurden Regeln entwickelt, die ein Aufblähen des Codes durch aria- und role-Attribute ohne wirklichen Nutzen verhindern sollen:
- Verwende kein ARIA, wenn du die gleiche Semantik mit einem nativen HTML-Element oder -Attribut erreichen kannst.[10]
- Ändere nicht die Semantik von nativem HTML[11]
- Alle interaktiven ARIA-Steuerelemente müssen mit der Tastatur bedienbar sein.
- Entferne keine semantische oder fokussierbare Elemente (mit
role="presentation"
oraria-hidden="true
" bei einem focussierbaren Element)[12] - Stelle sicher, dass alle interaktiven Elemente einen zugänglichen Namen haben (Accessibility API accessible name).[13]
<button>Absenden</button> <!-- Der Textinhalt ist der Name. -->
<label for="name">Name</label>
<input type="text" id="name">
<div aria-label="Einstellungen"><svg></svg></div> <!-- Das aria-label ordnet einen Namen zu. -->
<div aria-labelledby="meinName">
<h1 id="meinName">Überschrift</h1>
</div>
Wie du siehst, kommen die ersten beiden Elemente mit nativem HTML aus - es ist also ziemlich einfach!
ARIA verwenden
Wie im oberen Code-Snippet zu erkennen, hilft ARIA, bei bedeutungsleeren Elementen wie divs oder spans eine Semantik nachzurüsten.
role-Attribut
Mit dem role-Attribut können sogenannte Landmark-Roles als Orientierungspunkte verwendet werden.[14] Da Screenreader so die einzelnen Teile der Webanwendung erkennen, können diese dann per Tastendruck ("R" in JAWS) angesteuert werden.
Viele native HTML-Elemente haben bereits „eingebaute“ Rollen. Eine vollständige Übersicht findest du unter default-Rollen.
Anders ist es bei SVG. Text in SVG kann vom Browser oder Screenreader gelesen werden, die <text>-Elemente haben aber keine Semantik:
In diesem Beispiel erhielten die SVG-Elemente landmark-roles in Form von ARIA-Attributen. So können Screenreader die Text-Elemente anhand ihrer Semantik erkennen.
- Wenn es ein passendes HTML-Element gibt, verwende dieses ohne Angabe einer WAI-ARIA-Rolle.
- Verändere nicht die Semantik der HTML-Elemente.
- Sollten Elemente nicht bestimmungsgemäß eingesetzt werden, wie es zum Beispiel bei Layout-Tabellen der Fall ist, entferne die Semantik des Elements durch
role="none"
.[16]
Zustände und Eigenschaften
Häufig sind aus JavaScript-Bibliotheken übernommene Komponenten (widgets) entgegen ihrer Versprechungen nicht barrierefrei. Durch aria-Attribute können zusätzliche Information über ein Objekt geliefert werden, die ein Teil einer Definition der Rolle eines Objekts bilden. Die Ausdrücke Zustände (status) und Eigenschaften (properties) beziehen sich auf ähnliche Merkmale. [17]
<div className="dd-wrapper"> <div className="dd-header"> <div className="dd-header-title"></div> </div> <div className="dd-list"> <button className="dd-list-item"></button> <button className="dd-list-item"></button> <button className="dd-list-item"></button> </div> </div>
Ein listbox-Widget aus inhaltsleeren divs und Klassen. Formal korrektes HTML und wird vom Validator auch nicht bemängelt, ein Screenreader kann es aber nicht vorlesen.
<div className="dd-wrapper">
<button className="dd-header" aria-haspopup="listbox" aria-expanded="false" aria-controls="dropdown-list" id="dropdown-button">
<span className="dd-header-title">Dropdown</span>
</button>
<div className="dd-list" role="listbox" id="dropdown-list" aria-labelledby="dropdown-button">
<button className="dd-list-item" role="option" aria-selected="false">Heino</button>
<button className="dd-list-item" role="option" aria-selected="false">Micheal Jackson</button>
<button className="dd-list-item" role="option" aria-selected="false">Nina Hagen</button>
</div>
</div>
Angereichert mit role- und aria-Attributen können Screenreader nun die Semantik nachvollziehen.
<label for="top3">Künstler(in): </label> <select id="top3" size="5"> <option>Heino</option> <option>Michael Jackson</option> <option>Nina Hagen</option> </select>
Das linke, untere Beispiel ist zwar barrierefrei. Trotzdem ist es wohl klar, dass die Verwendung nativer HTML-Elemente unter Ausnutzung ihres Standardverhaltens Webentwicklern viel Arbeit spart und garantiert barrierfrei ist.
Eine vollständige Liste aller ARIA-Attribute findet sich in der Referenz:
- Setze HTML ein, wenn es ein HTML-Element oder -Attribut mit dem gewünschten Verhalten gibt.
- Mit ARIA sollte die Semantik von HTML nicht verändert werden.
aria-Attribute und CSS
Du kannst aria-Attribute anstelle von Klassen als Selektoren für eine Gestaltung mit CSS verwenden.
[aria-checked] {
width: 1em;
height: 1em;
}
[aria-checked="true"] {
color: blue;
}
[aria-checked="false"] {
color: green;
}
Dabei kann sowohl der Attributselektor verwendet, als auch nach dem aktuellen Wert selektiert werden.
Mit JavaScript kann der Wert von aria-Attributen bequem mit getAttribute ausgelesen und setAttribute gesetzt werden.
ARIA Live Regions
Mit JavaScript ist es möglich, Teile einer Seite dynamisch zu ändern, ohne dass die gesamte Seite neu geladen werden muss - zum Beispiel, um eine Liste von Suchergebnissen spontan zu aktualisieren oder um eine diskrete Warnung oder Benachrichtigung anzuzeigen, die keine Benutzerinteraktion erfordert. Während diese Änderungen für Benutzer, die die Seite sehen können, in der Regel visuell erkennbar sind, sind sie für Benutzer von Hilfsmitteln möglicherweise nicht offensichtlich.
ARIA-Live-Regions schließen diese Lücke und bieten eine Möglichkeit, dynamische Inhaltsänderungen programmatisch so darzustellen, dass sie von unterstützenden Technologien angekündigt werden können.[18]
Live-Ticker
In einem Live-Ticker eines Spiels oder Rennen haben wir als Ausgangslage die Teilnehmer und dann eine fortlaufende Kette von Ereignissen, die neu eingeblendet werden. In Abhängigkeit davon ändern sich eventuell auch die Platzierungen in der Tabelle oder Torschützenliste.
Dementsprechend müssen Screenreader informiert werden, welche Elemente der Webseite neuen Inhalt aufweisen:
<main id="ticker">
<h2>Live Ticker </h2>
<p id="match">Red Roosters vs. Black Scorpions</p>
<div id="ticker-grid" role="log" aria-live="polite" aria-atomic="true">
<p class="event"><span>⚽ Walter Frosch</span><span class="time">4'</span><span class="result">1:0</span><span class="time"></span><span class="player"></span></p>
</div>
</main>
<aside>
<h2>Tabelle</h2>
<table id="ranking" aria-live="polite" aria-relevant="additions text">
<tr>
<th>Platz</th>
<th>Team</th>
<th>Spiele</th>
<th>Tore</th>
<th>Punkte</th>
</tr>
...
</aside>
aria-live
Timer
Ein weiteres Beispiel ist ein Timer mit einer einfachen Uhr, die die verbleibende Zeit anzeigt. Die Uhr wird immer wieder aktualisiert, wobei die neue verbleibende Zeit den aktuellen Inhalt überschreibt.
<p>verbleibende Zeit: <output id="clock" aria-live="assertive"></output></p>
<fieldset aria-controls="alerts">
<legend>Gleich gibt's ne Pause …</legend>
...
<button id="set">Start!</button>
<button id="stop">Stop!</button>
</fieldset>
<p role="alert" id="alert" aria-live="polite">relax</p>
Wir haben zwei Elemente, die aktualisiert werden (output und p):
- die verbleibende Zeit
aria-live="assertive"
: Zeitänderungen werden sofort angezeigt. - und die Alert-Meldung
-
aria-live="polite"
: Für die Warnmeldungen wird sichergestellt, dass die Warnmeldung höflich angekündigt wird (es wird gewartet, bis die aktuelle Screenreader-Ansage zu Ende ist, bevor sie gelesen wird). -
role="alert"
wird durch JS erst hinzugefügt, wenn die Meldung aufploppen soll. Sie wird entsprechend durch CSS formatiert und vom Screenreader vorgelesen.
Für die letzten 10 Sekunden eines Countdowns sicherlich richtig, aber bei einem länger laufenden Timer würde man das sicher anders regeln wollen:
- Die Uhr hätte
aria-live="off"
- Wir wollen nicht, dass Benutzer durch die dauernden Zeitansagen gestört werden. - die (fast schon vergessene) Alarmmeldung ist auf
aria-live="assertive"
eingestellt - die Meldung hat Vorrang!
aria-atomic
Bei der ersten Ausführung der Funktion wird die gesamte hinzugefügte Zeichenfolge angekündigt. Bei nachfolgenden Aufrufen werden nur die Teile des Inhalts angesagt, die sich im Vergleich zum vorherigen Inhalt geändert haben. Wenn sich zum Beispiel die Uhrzeit von „17:33“ auf „17:34“ ändert, werden assistive Technologien nur „34“ ansagen, was für die Benutzer nicht sehr nützlich ist.
aria-relevant
Siehe auch
- Wie viel ARIA ist zuviel?
Ein Plädoyer für native HTML-Elemente, deren Standardverhalten bereits barrierefrei ist!
- Webseiten auf Barrierefreiheit testen
- Sprachausgabe
Wie hört sich meine Webseite im Screenreader an?
Quellen
- ↑ W3C: WAI ARIA
- ↑ W3C: ARIA in HTML
- ↑ hessendscher: Einführung in WAI ARIA
- ↑ How (Not) to Build a Button (30.09.2019 Ben Meyers)
Natürlich empfiehlt er im Schlussabsatz den Einsatz eines nativen <button>-Elements! - ↑ WAI-ARIA Screen reader compatibility (PowerMapper.com)
- ↑ SELF-Blog: Barrierefrei - Brauch' ich das? - Ja! vom 02.05.2024
- ↑ Pareto-Prinzip (wikipedia.de.org)
- ↑ How to Use the 80/20 Rule in Web Accessibility? (Mari-Ell Mets)
- ↑ Best intention barriers (ARIA edition) Marcus Hermann
- ↑ ARIA and HTML (web.dev)
- ↑ 5 Rules of ARIA (DEV Community)
- ↑ WebAIM: Introduction to ARIA - Accessible Rich Internet Applications (webaim.org)
- ↑ Using ARIA (www.w3.org)
- ↑ W3C: WAI-ARIA roles
- ↑ html5doctor: On HTML belts and ARIA braces
(The Default Implicit ARIA semantics they didn’t want you to know about) vom 14. April 2015 - ↑ role="presentation" oder "none"?
In der ARIA-Spezifikation 1.1 wird die Rollenone
als Synonym für die Rollepresentation
eingeführt, weil das Wort none die eigentliche Bedeutung besser vermittelt.
W3C ARIA 1.1: 5.4 Definition of Roles #none - ↑ W3C: Definitions of States and Properties (all aria-* attributes)
- ↑ MDN: ARIA Live Regions