Barrierefreies Webdesign ein zugängliches und nutzbares Internet gestalten

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 Extern, englischsprachig: 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 Extern, englischsprachig: 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:

  1. Wenn es ein HTML-Element oder -Attribut mit der erforderlichen Semantik oder Verhalten gibt, dann sollte HTML eingesetzt werden und nicht ARIA.
  2. 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:

  1. Jede Komponente muss mit der Tabulatorentaste erreicht werden können.
  2. 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:

  1. 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.

  2. 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:

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.

TastenbefehlFunktion
LeertasteMarkieren oder Entmarkieren eines Inhalts.
Umschalt+LeertasteMarkieren mehrerer einzelner, aufeinander folgender Inhalte.
Strg+LeertasteMarkieren mehrerer einzelner, nicht aufeinander folgender Inhalte.
Strg+MBeendigung 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 Extern, englischsprachig: 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.:

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:

  1. dass die landmarkroles alle Bereiche der Seite abdecken,
  2. dass die landmark roles nach Möglichkeit nicht ineinander verschachtelt sind und
  3. 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:

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:

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.

Screenshot eines Formulars mit fehlerhafter Eingabe 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

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:

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:

Screenshot eines Datepickers

Das wichtigste ist, dass die Komponenten fokussierbar sind und dass die Komponenten bedient werden können. Die semantische Auszeichnung ist in diesem Fall:

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.