ARIA und die Accessibility-API veröffentlicht in 2002zuletzt bearbeitet in
Worauf bei ARIA zu achten ist
Auf Webseiten gibt es zahlreiche Komponenten, die mit ARIA-Attributen ergänzt werden müssen, damit sie für Hilfsmittel zugänglich sind. Die erste Anlaufstelle bei der Gestaltung barrierefreier Komponenten sind die WAI-ARIA 1.1 Authoring Practices. In diesem Dokument werden Vorgehensweisen beim Einsatz von ARIA erklärt und mit Angaben zu Rollen, Zuständen und Eigenschaften sowie zur Tastaturbedienung ergänzt.
Ein weiteres unentbehrliches Dokument für die Einarbeitung in ARIA ist Using WAI-ARIA in HTML. Das Dokument beschreibt in Kürze die wichtigsten Konzepte für den Einsatz von ARIA in Webseiten einschließlich fünf einfache Regeln. Zwei dieser Regeln wurden bereits in der Einführung dieser Beitragsserie erläutert:
- Wenn es ein HTML-Element oder -Attribut mit der erforderlichen Semantik oder Verhalten gibt, dann sollte HTML eingesetzt werden und nicht ARIA.
- Mit ARIA sollte die Semantik von HTML nicht verändert werden.
Hinweis: Die Dynamik auf Webseiten wird oft mit fertigen Bausteinen z.B. aus irgendeiner JavaScript-Bibliothek erzeugt. Wenn Code übernommen wird, dann muss überprüft werden, ob die Rollen und Eigenschaften vom Browser korrekt an den Accessibility-Tree sowie Hilfsmittel weitergeleitet werden. Leider muss immer wieder festgestellt werden, dass die allermeisten fertigen Widgets mit Barrierefreiheit nichts zu tun haben und manchmal sogar durch den falschen Einsatz von ARIA zu nicht nutzbaren Widgets führen. Das gilt leider auch dann, wenn die Anbieter ihre Widgets mit den Worten "barrierefrei" oder "accessible" beschreiben.
In erster Linie muss beachtet werden, dass ARIA eine Ergänzungstechnik für HTML, SVG und andere Auszeichnungssprachen ist und dass die ARIA-Attribute nur dann zum Einsatz kommen sollten, wenn die Auszeichnungssprache selbst keine passenden Mittel bietet oder wenn diese Mittel nicht zugänglichkeitsunterstützend sind.
Im Folgenden werden einige Regeln und typische Fallgruben für Webentwickler beschrieben, die bei der Einarbeitung in ARIA auftauchen können.
Tastaturbedienung
Ein wichtiger Baustein barrierefreier Widgets ist die Tastaturbedienung. Alle Komponenten müssen per Tastatur gesteuert werden können. Das bedeutet:
- Jede Komponente muss mit der Tabulatorentaste erreicht werden können.
- Sofern eine Komponente weitere Auswahlmöglichkeiten bietet, so muss die Bedienung mit Pfeiltasten, Tastenkombinationen usw. per JavaScript möglich sein.
Darüber hinaus muss für komplexe Widgets ein Fokus-Management eingeführt werden.
Tastaturbedienung bei Widgets
Es gibt zwei wichtige Regeln für die Tastaturbedienung von Widgets:
Die Tastaturbedienung wird grundsätzlich über JavaScript gesteuert. Wie eine bestimmte Komponente bedient werden soll, wird in den oben verlinkten Dokumenten genau beschrieben. Wenn eine Komponente die Rolle eines Links oder einer Schaltfläche erhält, dann muss die Komponente in der Tab-Reihenfolge stehen und mit Leertaste und Eingabetaste aktiviert werden können. Für komplexere Komponenten müssen weitere Tastaturbefehle berücksichtigt werden; für eine Registernavigation gilt z.B.:
- Nur der aktive Reiter darf in der Tab-Reihenfolge stehen.
- Der Fokus innerhalb der Reiter wird mit Pfeiltasten geändert.
- Die Auswahl eines Reiters (das Einblenden der zugehörigen Inhalte) erfolgt per Leertaste.
Bei Registernavigationen gibt es darüber hinaus einige weitere Tastenbefehle, die über die Grundfunktionalität hinaus berücksichtigt werden müssen. Wichtig ist, dass die Tastaturbedienung in der Verantwortung der Webentwicklung und nicht des Browsers liegt.
ARIA-Attribute beeinflussen die Funktionalität einer Webseite im Browser nicht. Die zusätzliche Kennzeichnung von Elementen mit ARIA-Attributen dient der semantischen Identifizierung z.B. in einem Screenreader. Anhand solcher Informationen kann ein Screenreadernutzer beispielsweise erkennen, welcher Eintrag in einem Menü aktiv ist, ob ein Element ein Button ist (und mit Leertaste ausgeführt werden kann) oder ob jetzt die Pfeiltasten genutzt werden müssen, um etwa in einer Reiternavigation die Auswahl zu ändern.
Für eine Drag-and-Drop-Funktion stellt ARIA beispielsweise zwei spezielle Attribute bereit:
- Ob ein Element gerade verschoben werden kann, wird mit
aria-grabbed="true"
semantisch gekennzeichnet. - Die Vergabe eines
aria-dropeffect
-Attributs für das Zielgebiet wird die Identifizierung eines Zielgebiets erleichtern (was nur sinnvoll ist, wenn es mehrere Zielgebiete gibt).
Obwohl eine barrierefreie Drag-and-Drop-Funktion an sich schon eine Herausforderung ist (Screenreadernutzer müssen wissen, um was es sich handelt und wie die Funktionalität implementiert ist), kommt es im Hinblick auf die Funktionalität (Fokus, Bewegung mit Pfeiltasten usw. auf das JavaScript an. Einige Tastaturbefehle, die für die Tastaturbedienung berücksichtigt werden müssen, sind in der folgenden Tabelle exemplarisch aufgeführt.
Tastenbefehl | Funktion |
---|---|
Leertaste | Markieren oder Entmarkieren eines Inhalts. |
Umschalt+Leertaste | Markieren mehrerer einzelner, aufeinander folgender Inhalte. |
Strg+Leertaste | Markieren mehrerer einzelner, nicht aufeinander folgender Inhalte. |
Strg+M | Beendigung des Markiervorgangs. |
Bei jeder Markierung und jeder Entmarkierung muss das aria-grabbed
-Attribut für die einzelnen ziehbaren Objekte dynamisch angepasst werden. Die aufgeführten Tastenbefehle sind dabei keinesfalls ausschöpfend. Bislang wurde nur der Markiervorgang behandelt und der Ziehvorgang muss genauso für die Tastaturbedienung möglich sein. Darüber hinaus müssen Möglichkeiten berücksichtigt werden, den Drag-and-Drop-Vorgang an verschiedenen Stellen mit Esc abbrechen zu können. Abhängig vom zu markierenden Inhalt können außerdem andere Tastaturbefehle erforderlich sein, z.B. Strg+Pfeiltasten, wenn Texte (und nicht etwa Objekte) markiert werden können. Ausführliche Informationen hierzu sind in den Authoring practices beschrieben.
Besonderheiten bei widget roles
ARIA definiert vier verschiedene Arten von Rollen, wobei für die Webentwicklung vor allem widget roles, document structure roles und landmark roles interessant sind. Die abstract roles dienen der Ontologie im Browser und sind für die Webentwicklung eher von theoretischem Interesse.
Die Besonderheit der widget roles ist, dass die Webentwicklung Komponenten so auszeichnen und an den Accessibility-Tree übertragen lassen können, als ob sie Komponenten des Betriebssystems wären; dabei kommen die meisten dieser Rollen in HTML gar nicht vor. Vor allem für Screenreadernutzer stimmt die Semantik dieser Komponenten mit der Semantik von Komponenten des Betriebssystems überein.
Es gibt allerdings einen entscheidenden Unterschied zwischen Komponenten des Betriebssystems und Komponenten auf Webseiten. Die Tastatursteuerung und das Fokus-Management von Widgets auf Webseiten sind alleinige Aufgabe der Webentwicklung. Und hier kann es relativ unübersichtlich werden — zumindest muss das Event-Handling sorgfältig und ausführlich entwickelt werden. Die Herausforderung potenziert sich auch mit der Komplexität der Widgets, z.B.:
Einige Widgets (z.B. ein Menü) steuern Kindelemente (bei einem Menü kann dass beispielsweise ein menuitem sein). In solchen Fällen muss der Fokus explizit mit
aria-activedescendant
gemanagt werden. Aber nicht alle Rollen unterstützen dieses Attribut: Einige Rollen erfordern Kindelemente mit interaktiven Rollen (z.B. Registernavigationen)Kombinierte Widgets sind eine Herausforderung, wenn es um die Tastaturbedienung geht. Beim Testing muss beachtet werden:
- Alle Komponenten müssen mit der Tastatur erreicht und bedient werden können.
- Alle Komponenten benötigen Rolle und Wert, wobei der Wert typischerweise aktualisiert werden muss. Die Rolle muss funktional (und nicht optisch) bestimmt werden.
- Alle Komponenten benötigen einen Namen/eine Bezeichnung.
- Die Tastaturbedienung (insbesondere Reihenfolge) muss logisch nachvollziehbar sein.
- Die Tastaturbefehle müssen für alle Tastaturnutzer dokumentiert sein.
Besonderheiten bei landmark roles
Die Tastaturbedienung ist grundsätzlich die Sache der Webentwicklung, aber bei landmark roles besteht eine Ausnahme. Wenn landmark roles korrekt ausgezeichnet sind, soll der Screenreader ein Bedienkonzept für die Regionen einer Webseite davon ableiten. Die Webentwicklung muss nur dafür Sorge tragen:
- dass die landmarkroles alle Bereiche der Seite abdecken,
- dass die landmark roles nach Möglichkeit nicht ineinander verschachtelt sind und
- dass landmark roles ggf. mit
aria-label
beschriftet werden
landmark roles können im Screenreader per Tastendruck angesprungen werden (in JAWS 15 ist das mit der Taste "R" möglich). Sie werden semantisch identifiziert (z.B. <div role="navigation">
wird als "Region Navigation") identifiziert. Mit aria-label
und aria-labelledby
können die Regionen genauer beschrieben werden.
Falls die vorgesehenen Rollen semantisch nicht passen, kann auch role="region"
vergeben werden. Diese generische Region ist ebenfalls per Tastatur anspringbar, benötigt aber eine explizite Beschriftung etwa mit aria-label
. Anwendungsbeispiel für role="region"
ist ein scrollbares <div>
:
<div role="region" tabindex="0" class="scrollkasten" aria-label="Allgemeine Geschäftsbedingungen">
<p>... scrollbarer Text ...</p>
</div>
Die Region ist zwar in einem Screenreader ansteuerbar, aber nicht im Browser; deshalb erhält die Region für Tastaturnutzer allgemein ein tabindex="0"
. Wenn der Fokus auf den Inhalt ist, muss das Scrollen mit JavaScript realisiert werden — was selbstverständlich auch für die Tastatur gilt.
Semantik entfernen oder Inhalte verstecken
Zwei ARIA-Attribute sind besonders gefährlich, wenn sie sorglos eingesetzt werden:
- Mit
role="presentation"
kann die Semantik eines Elements (aber nicht der Kindelemente) entfernt werden. Diese Rolle darf nur für Elemente eingesetzt werden, die weder sichtbar noch fokussierbar sind. - Mit
Aria-hidden="true"
wird ein Element samt Kindelemente aus dem Accessibility-Tree entfernt, wodurch sie nicht mehr zugänglich für Screenreader sind. Diese Eigenschaft darf nur für Elemente eingesetzt werden, die weder sichtbar noch fokussierbar sind.
Semantik eines Elements entfernen
Der Einsatz von role="presentation"
dürfte überflüssig sein, wenn HTML richtig eingesetzt wird. Es handelt sich bei dieser Rolle um eine Reparaturtechnik für falsch verwendetes HTML. Dennoch gibt es Situationen, in denen die Rolle zweckmäßig ist, etwa wenn ein Layout mit Tabellen umgesetzt wurde oder wenn rein dekorative Grafiken vorliegen. Die Rolle entfernt das Element und erforderliche Kindelemente aus dem Accessibility-Tree, aber nicht die Inhalte (und auch nicht andere Kindelemente). Aus
<table role="presentation">
<tr>
<td>
Ein Text <abbr title="zum Beispiel">z.B.</abbr> über Tabellen.
</td>
</tr>
</table>
wird
Ein Text <abbr title="zum Beispiel">z.B.</abbr> über Tabellen.
Elemente vor Hilfsmitteln verstecken
Das aria-hidden
-Attribut kann in dynamischen Anwendungen hilfreich sein. Im Prinzip ähnelt es der CSS-Eigenschaft display:none;
, nur dass das ARIA-Attribut keinerlei Einfluss auf die visuelle Darstellung hat, d.h. Inhalte mit aria-hidden="true"
sind für Screenreader unsichtbar:
<p aria-hidden="true">Texte und <span>Kindelemente</span> kriegt ein Screenreader nicht mit, aber am Bildschirm bleibt alles sichtbar.</p>
Weil in der Praxis diese Eigenschaft oft gesetzt und aber oft nicht richtig aktualisiert wird, empfiehlt es sich, die visuelle Darstellung von diesem Attribut abhängig zu machen, indem im CSS
[aria-hidden=true] {
display:none;
}
berücksichtigt wird.
Alternativ kann auf aria-hidden
verzichtet werden zugunsten des entsprechenden HTML5-Attributs. Seit einigen Jahren unterstützen alle Browser hidden
nicht nur am Bildschirm, sondern auch im Accessibility-Tree. Das ARIA-Attribut ist zwischenzeitlich obsolet:
<p hidden>Diesen Text kriegt niemand mit.</p>
Jede Komponente braucht eine Bezeichnung
Eine Komponente hat nur dann einen Namen, wenn im Accessibility-Tree ein Name steht. Für Links und Formularelemente sollten Bezeichnungen mit HTML gesetzt werden:
- In Links ist die Bezeichnung normalerweise der verlinkte Text, aber wenn im Link eine Grafik steht, dann kann der Linktext auch der Alternativtext der Grafik sein. Der Name eines Links kann — nur bei fehlen eines Linktexts — auch durch ein
title
-Attribut bestimmt werden. - Bei Formularelementen sollte die sichtbare Beschriftung per LABEL-Element mit dem Formularelement verknüpft werden, aber es können auch
title
-,alt
- odervalue
-Attribute herangezogen werden, um das Formularelement zu bezeichnen. BeiBUTTON
-Elementen wird der textliche Inhalt (wie bei Linktexten) zur Bezeichnung des Formularelements herangezogen.
Mit ARIA gibt es weitere Attribute: aria-label
und aria-labelledby
ersetzen die vorhandenen Bezeichnungen und aria-describedby
ergänzt vorhandene Bezeichnungen. Beispielsweise ist der Name des folgenden Links
<a href="seite.html" aria-label="Homepage">mehr</a>
nicht "mehr", sondern "Homepage".
Das Attribut aria-describedby
fügt einen zusätzlichen Text einer vorhandenen Bezeichnung hinzu. In einem Screenreader wird der Link
<h2 id="ueberschrift">Homepage</h2>
<p>Teaser-text <a href="seite.html" aria-describedby="ueberschrift">mehr</a>.</p>
als "mehr Homepage" identifiziert.
In der Regel sind diese Attribute nur dann wichtig, wenn die anderen Möglichkeiten mit HTML versagen, aber in komplexen Widgets sind sie oft zwingend einzusetzen, nicht nur um die Komponenten inhaltlich zu identifizieren, sondern ggf. auch um Hinweise zur Tastaturbedienung zu geben.
<div role="region" aria-label="Ihr Warenkorb">
<div class="ziehbereich" role="button" tabindex="0" aria-grabbed="false" aria-label="Bezeichnung des ersten Produkts" aria-describedby="tooltipID"></div>
<!-- weitere ziehbare Inhalte -->
</div>
<div style="display:none;" id="tooltipID" role="tooltip">
Mit Leertaste markieren, mit Strg+M Markiervorgang beenden und anschließend mit Tab-Taste zur Kasse gehen. Mehrere Produkte können mit Strg+Leertaste markiert werden.
</div>
Live-Regionen
Ein Problem entsteht für Screenreadernutzer, wenn auf einer Seite Inhalte dynamisch ausgetauscht werden. Bedient ein Screenreadernutzer Formulare auf einer Webseite und werden an anderer Stelle der Seite Fehlerhinweise angezeigt, erfährt er diese Veränderungen normalerweise nicht, weil der Tastaturfokus nicht dort steht. Dabei geht es um zwei Probleme: Zum einen muss der Screenreader erfahren, dass sich überhaupt etwas auf der Seite geändert hat, und zum anderen sollte die Information für den Screenreadernutzer zugänglich sein, ohne dass er die komplette Seite lesen muss.
Beispiel einer dynamischen Fehlererkennung, wobei der Fehlerhinweis an anderer Stelle steht
HTML verfügt nur bedingt über passende Techniken. ARIA bietet das aria-live
-Attribut. Mit diesem Attribut kann eine Region der Webseite als aktiv gekennzeichnet werden, und Veränderungen innerhalb dieser Region werden dem Screenreadernutzer unmittelbar oder verzögert mitgeteilt.
Als Live-Region wird jede Region einer Webseite verstanden, die
- entweder durch eine Nutzeraktion (z.B. Eingabe)
- oder automatisch (z.B. eine fortlaufende Zeitangabe)
dynamisch aktualisiert wird.
Das aria-live
-Attribut muss nicht explizit gesetzt werden, denn es gibt einige Rollen, die mit ARIA bzw. HTML5 dieses Attribut an den Accessibility-Tree übertragen. Bei den folgenden sechs Rollen und zwei HTML-Elementen handelt es sich bereits um Live-Regionen:
role="alert"
funktioniert mitaria-live="assertive"
undaria-atomic="true"
recht gutrole="status"
undrole="log"
funktionieren mitaria-live="polite"
, aber nicht in jeder Browser-Screenreader-Kombination;role="status"
wird zukünftig mit demOUTPUT
-Element realisiert werden können- auf
role="progressbar"
kann verzichtet werden, weil dasPROGRESS
-Element bereits relativ gut funktioniert role="timer"
undrole="marquee"
funktionieren mitaria-live="off"
Dabei geht es nicht darum, jede Veränderung auf einer Seite einem Screenreadernutzer mitzuteilen. Oft werden Webseiten in einem Screenreader unbrauchbar, weil Live-Regionen falsch zugewiesen werden und z.B. ununterbrochen Aktualisierungen über den Accessibility-Tree an Screenreader übertragen werden.
Eingebettete Anwendungen
//Eine weitere Auszeichnung, die immer wieder auf Webseiten zu finden ist, aber die Zugänglichkeit durchaus einschränkt, ist die Rolle application
. Die landmark role application
sollte nur eingesetzt werden, wenn es keine Alternative gibt. In den allermeisten Fällen, in denen diese Rolle eingesetzt wird, ist die Webseite in einem Screenreader nicht mehr nutzbar.
Als "Anwendung" im Sinne von ARIA werden komplexe Widgets wie Rich-Text-Editoren verstanden. Für die meisten Widgets gilt, dass sie mit einem oder mehrere der anderen spezifizierten Rollen abgebildet werden können; in dem Fall übernimmt der Browser viele Aufgaben, wenn es um das Befüllen des Accessibility-Trees geht. Mit role="application"
wird die Navigation des Screenreaders praktisch außer Kraft gesetzt. Ein Screenreadernutzer verfügt nur noch über die Tabulatortaste, d.h. Screenreader können nur noch die Bezeichnung fokussierbarer Elemente auslesen. Sämtliche Inhalte müssen mit weiteren ARIA-Attributen zugänglich gemacht werden.
Die meisten Webanwendungen sind im Sinne von ARIA Dokumente, die in Teilen mit den widget roles abgebildet werden können.
Es fehlt eine geeignete Rolle
In einigen wenigen Fällen gibt es für Komponenten keine passende Rolle. Das klassische Beispiel dafür ist ein Date-Picker:
Das wichtigste ist, dass die Komponenten fokussierbar sind und dass die Komponenten bedient werden können. Die semantische Auszeichnung ist in diesem Fall:
- Schaltflächen für die Blätterfunktionalität
- eine Tabelle für den Kalender
- aktive Daten sind entweder als Links oder Buttons auszuspielen, je nach dem, ob neue Seiten aufgerufen oder Inhalt der Seite aktualisiert werden.
Ein anderer Fall ist gegeben, wenn zwei ineinander verschachtelte Komponenten nur einen Fokus erhalten können. Wenn beispielsweise in einem gridcell sowohl Text als auch eine Schaltfläche enthalten sind, kann entweder der Gridcell mit dem Text oder die Schaltfläche fokussiert werden. Die Frage stellt sich dann, wie alle Informationen und Funktionen an einem Screenreader übertragen werden können. Wenn davon ausgegangen werden kann, dass die Bedienung der Schaltfläche mit Skripts erledigt werden kann, dann sollte der Gridcell fokussiert werden; in diesem Fall müssen andere Techniken (z.B. zusätzlicher unsichtbarer Text für den Gridcell) genutzt werden, um Rolle und Zustand des Buttons zu vermitteln.
ARIA testen
Abschließend muss auch auf das Testen hingewiesen werden. Es gibt diverse Tools, die Einblick in den Accessibility-Tree geben, aber die Anwendungen sind aus meiner Sicht nur für die Kontrolle einzelner Probleme geeignet. Ob eine komplexe Komponente mit einem Screenreader bedient werden kann, muss eigentlich mit Screenreadern getestet werden.
Browser übertragen ARIA-Attribute unterschiedlich gut an den Accessibility-Tree, abhängig von Version und Betriebssystem. Ebenso variiert die Unterstützung durch Hilfsmittel (Screenreader, Vergrößerungssysteme, Spracheingaben). Es kann durchaus sein, dass ein Browser zwar den Accessibility-Tree korrekt befüllt, aber die Hilfsmittel die verfügbaren Informationen nicht korrekt auswerten. Deshalb müssen verschiedene Hilfsmittel mit verschiedenen Browsern getestet werden.
Der Beitrag ARIA und die Accessibility-API besteht aus folgenden einzelnen Webseiten:
- ARIA ist Silber, HTML ist Gold
ARIA ist eine Ergänzungstechnik. Es sollte vermieden werden, HTML mit ARIA zu reparieren, wenn HTML die erforderliche Semantik bereits bietet.
- Worauf bei ARIA zu achten ist
(Aktuelle Seite)
- Werkzeuge zur Überwachung des Accessibility-Trees
Hinweise zu Werkzeugen, um den Accessibility-Tree zu überwachen.