Für die Nutzung eines Webauftritts mit assistiven Technologien spielt semantisches HTML eine wesentliche Rolle. In der freien Wildbahn erhält das Thema jedoch nicht immer die nötige Priorität. Einer der Gründe mag mangelndes Bewusstsein für seine Bedeutung sein.

Welche praktischen Auswirkungen hat Semantik auf die Nutzung einer Webseite mit assistiven Technologien? Welche Informationen kommen wie bei den Nutzenden an? Ein besseres Verständnis soll dabei unterstützen, den Fokus wieder stärker auf die Umsetzung von semantischem HTML zu richten und WAI-ARIA zu Gunsten der Barrierefreiheit gezielter einzusetzen.

Webseiten wahrnehmen

Visuelle Nutzung

Sehende Menschen erschließen sich eine Webseite aufgrund visueller Hinweise und Gestaltungsmuster. Klar definierte Bereiche, wie Kopf-, Fuß- und Inhaltsbereich, sowie visuelle Hierarchien ermöglichen es, die Seite zu überfliegen. Die visuelle Wahrnehmung der Inhalte und auch die Orientierung erfolgen nicht nur linear, sondern auch in der Fläche unter Einbeziehung des Kontextes. Ein weiteres wichtiges Wahrnehmungsprinzip ist der Abgleich mit bereits gespeicherten Erfahrungen. Für interaktive Elemente bedeutet dies im Idealfall, dass man intuitiv verstehen kann, wie sie zu benutzen sind und was für Auswirkungen eine Aktion hat.

Nicht-visuelle Nutzung

Menschen, die eine Webseite nicht-visuell nutzen, sind darauf angewiesen, dass Informationen zur Bedeutung eines Elements auf einer abstrakten Ebene zur Verfügung stehen und assistive Technologien diese nutzen können. Man bezeichnet das auch als programmatische Ermittelbarkeit. Semantisches HTML ist die Voraussetzung und bietet entsprechende Elemente wie Überschriften, Absätze, Listen, Tabellen und so weiter. Das gilt auch für interaktive Elemente (Links, Schaltflächen, Formularelemente). Doch wie genau hilft diese semantische Auszeichnung Menschen, die assistive Technologien nutzen? Wie genau können beispielsweise Screenreader Semantik „lesen“?

Nutzung mit assistiven Technologien

Wenn ein Browser ein HTML-Dokument aufbereitet, passieren mehrere Dinge:

  1. Zunächst verarbeitet der Browser den Code des HTML-Dokuments und wandelt ihn in eine Objektstruktur um, das sogenannten Document Object Model (DOM). Diese Schnittstelle repräsentiert alle HTML-Elemente und Inhalte der Seite. Das DOM kann als Baumstruktur dargestellt werden. Technologien wie CSS und JavaScript nutzen diese Objektstruktur, um auf die Elemente der Seite zuzugreifen.
  2. Der Browser bereitet die Seite visuell auf. Was wir im Browser sehen, basiert also auf dem DOM, nicht auf dem ursprünglichen HTML-Quelltext.
  3. Der Browser modifiziert den DOM-Baum zu einer vereinfachten Form, die für assistive Technologien sinnvoll ist (den sogenannten Accessibility Tree), und gibt die Informationen an die Barrierefreiheits-Schnittstelle (Accessibility API) des Betriebssystems weiter.
  4. Assistive Technologien können über die Accessibility API Informationen aus dem Accessibility Tree abrufen. Jeder DOM-Inhalt kann also Auswirkungen darauf haben, was im Accessibility Tree als Information zur Verfügung steht.

Every time you add HTML to a page, think what does this expose to the accessibility tree?

— Hidde de Vries, The accessibility tree

Semantisches HTML

Die Barrierefreiheits-API liefert also Informationen über die Objekte einer Webseite. Sie bildet die Struktur der Seite ab, ganz ähnlich dem DOM. Die Informationen des Accessibility Tree sind jedoch auf die wesentlichen, für assistive Technologien relevanten Informationen reduziert. Dazu gehören unter anderem:

Die Rolle eines Elements

Native semantische HTML-Elemente haben eine implizite oder mitgegebene Rolle. Die Rolle liefert Informationen, um was für ein Element es sich handelt. Ein <a>-Element hat beispielsweise die Rolle Link, ein <img>-Element die Rolle Grafik, ein <header>-Element die Rolle Banner. Die Rolle vermittelt die Bedeutung des Elementes und wird von Screenreadern ausgegeben.

<button>Video abspielen</button>

Beispiel: Ein <button>-Element hat die Rolle Schaltfläche. Ein Screenreader gibt aus: Schaltfläche Video abspielen.

In der Praxis hat das konkrete Folgen für die Nutzbarkeit einer Website: Wenn Nutzende wissen, um welche Elemente es sich handelt, dann wissen sie auch, welche Aktionen möglich sind. Gibt der Screenreader beispielsweise die Rolle Link aus, so ist davon auszugehen, dass es sich um einen Verweis auf eine andere Seite oder um einen Sprung-Link auf der aktuellen Seite handelt. Eine Schaltfläche hingegen führt eine Aktion (auf der aktuellen Seite) aus: Es wird ein Video abgespielt, ein Bereich eingeblendet und so weiter.

Ein weiterer Pluspunkt: Nutzende verstehen nicht nur, welche Aktion möglich ist, sie können auch Rückschlüsse darauf ziehen, wie ein Element zu bedienen ist. Sie wissen aufgrund des ausgegebenen Elementtyps, welche Tastaturbefehle zur Verfügung stehen. Das ist wichtig, denn bei nicht-visueller Bedienung sind die Nutzenden auf die Interaktion per Tastatur angewiesen. Eine Schaltfläche (<button>) kann beispielsweise mit der Leer- oder Eingabetaste bedient werden; die Optionen einer Auswahlliste wählt man mit den Pfeiltasten. Native, interaktive HTML-Elemente können standardmäßig mit bestimmten Tasten bedient werden.

Als dritten positiven Effekt kann man festhalten, dass korrekt eingesetzte HTML-Strukturelemente Nichtsehende bei der Orientierung und Navigation unterstützen. Zwei Beispiele:

    Landmarks (<header>, <footer>, <nav>, <main>, <aside> und weitere) definieren die grundlegende Struktur einer Seite. Werden die Elemente korrekt eingesetzt, können Screenreader-Nutzende konstante Bereiche am Seitenbeginn (etwa die Navigation oder den Seitenkopf) mit einem Tastaturbefehl überspringen und direkt zum Inhalt gelangen. Sie können mit Tastaturbefehlen auch zwischen Bereichen hin und her wechseln.

    Gibt es mehrere Navigationsbereiche, so muss es möglich sein, diese auf Basis einer Beschriftung zu unterscheiden. Die Umsetzung erfolgt etwa mit Hilfe eines aria-label-Attributs auf dem <nav>-Element, zum Beispiel aria-label="Hauptnavigation" und aria-label="Bereichsnavigation".

    Überschriften sollten mit den HTML-Elementen <h1> bis <h6> ausgezeichnet werden. Wenn Überschriften den Inhalt einer Seite hierarchisch sinnvoll erschließen, dann bildet diese Struktur eine Art Inhaltsverzeichnis. Screenreader-Nutzende können sich diese Struktur ausgeben lassen. Sie hilft bei der schnellen Orientierung und beim Springen von Überschrift zu Überschrift — dazu gibt es spezielle Tastaturbefehle. Auf ähnliche Weise wird die Überschriften-Hierarchie auf dieser Seite, die Sie gerade lesen, dazu genutzt, um das Inhaltsverzeichnis am Anfang zu erzeugen. Nutzen Sie Überschriften aber nur dann, wenn ihnen auch wirklich substanzieller Inhalt folgt, der gegliedert und überschrieben werden soll. Der Einsatz von zu vielen oder sinnlosen Überschriften kann die Nutzbarkeit einer Webseite auch erschweren. Etwa, wenn man zu einer Überschrift springt und es folgt — entgegen der Erwartung — kein nennenswerter Inhalt.

Wie das Ganze praktisch funktioniert, sehen Sie in einem Video auf Smashing TV. Léonie Watson navigiert mit einem Screenreader und nutzt dabei HTML5 Landmarks und Überschriften.

Der Name eines Elements

Der zugängliche Name (accessible name) identifiziert und bezeichnet ein Element näher. Er unterscheidet das Element von anderen Elementen auf der Seite und ermöglicht, direkt damit zu interagieren.

Nutzerinnen und Nutzer von Spracheingabe-Software können beispielsweise eine Schaltfläche mit Hilfe des zugänglichen Namens (der Beschriftung) gezielt ansprechen und bedienen. Ein Screenreader gibt den zugänglichen Namen aus, wenn er das Element fokussiert.

Die WCAG verlangen für alle fokussierbaren, interaktiven Elemente (Links, Schaltflächen, Formularelemente) einen zugänglichen Namen. Das gilt auch für Grafiken, eingebettete Inhalte oder Widgets (zum Beispiel modale Dialoge oder Schieberegler).

Die Beschriftung kann sichtbar sein, es gibt jedoch auch nicht-visuelle Techniken. Die Umsetzung des zugänglichen Namens erfolgt

  • mit Hilfe des Inhalts eines Elements: 
    <a href="barrierefreiheit.html">Barrierefreiheit</a>
    Jemand, der Spracheingabe nutzt, würde sagen: Klick Barrierefreiheit Link. Ein Screenreader liest vor: Barrierefreiheit Link.
  • mit Hilfe eines Attributs: 
    <img src="heidschnucken.png" alt="Zwei Heidschnucken">
    Der zugängliche Name der Grafik ist die Textalternative und wurde in diesem Fall mit Hilfe des alt-Attributs umgesetzt: Er lautet hier Zwei Heidschnucken.
  • mit Hilfe eines verknüpften Elements: 
    <label for="name">Vorname</label>
<input type="checkbox" id="name">
    Der zugängliche Name des Kontrollkästchens (Checkbox) lautet Vorname. Es handelt sich dabei um den Text des verknüpften <label>-Elements. Durch die Verknüpfung gibt der Browser das <label> als zugänglichen Namen für das Eingabefeld weiter. Die Verknüpfung entsteht dadurch, dass das for-Attribut und die id des <input> denselben Wert haben.
  • mit Hilfe von WAI-ARIA: 
    <button aria-label="Schließen">x</button>
    In diesem Fall lautet der zugängliche Name der Schaltfläche Schließen. Er ist mit Hilfe eines aria-label-Attributs umgesetzt.

Hinweise für das Erstellen eines zugänglichen Namens:

  • Verwenden Sie möglichst vorhandenen, sichtbaren Text für den zugänglichen Namen. Es ist beispielsweise nicht sinnvoll, über ein aria-label eine Beschriftung zur Verfügung zu stellen, wenn der Inhalt eines <button>-Elements bereits einen zufriedenstellenden, zugänglichen Namen liefert. Die Gefahr besteht, dass der Wert des aria-label-Attributs von der sichtbaren Beschriftung abweicht. Das Bedienelement lässt sich dann nicht oder nur über Umwege mittels Spracheingabe aktivieren.
  • Manche Web-Autoren verwenden nicht-visuelle Techniken (zum Beispiel versteckten Text), um sichtbare Beschriftungen zu erweitern. Dies geschieht meist in der Absicht, den zugänglichen Namen für nicht sehende Menschen aussagekräftiger zu machen. Stellen Sie in diesem Fall sicher, dass die sichtbare Beschriftung im zugänglichen Namen enthalten ist, am besten zu Beginn.
  • Sorgen Sie für Beschriftungen von Formularelementen, die immer sichtbar sind. Sichtbare Beschriftungen verbessern die Zugänglichkeit für Menschen, die keine Screenreader verwenden, sie machen die Benutzeroberfläche für alle leichter verständlich.
  • Achten Sie auf möglichst kurze, aber klare und verständliche Formulierungen. Die Qualität des zugänglichen Namens ist ein wichtiger Faktor für die Nutzerfreundlichkeit.
  • Bevorzugen Sie native HTML-Techniken. Sie sind einfach, robust und weniger fehleranfällig.

Der Zustand eines Elements

Manche HTML-Elemente können unterschiedliche Zustände annehmen, beispielsweise Kontrollkästchen (Checkbox) oder Auswahlschalter (Radio-Button). Der jeweilige Zustand (aktiviert oder nicht aktiviert) wird bei nativen HTML-Elementen von Haus aus an den Accessibility Tree und damit an die assistive Technologie weitergegeben.

WAI-ARIA füllt semantische Lücken

ARIA steht für Accessible Rich Internet Applications. Es ist eine technische Spezifikation der WAI, der Web Accessibility Initiative des W3C. Mit WAI-ARIA lassen sich JavaScript-Widgets und Webseiten mit dynamischen Inhalten zugänglich machen: Eine Schaltfläche blendet ein Menü ein, eine Statusmeldung wird angezeigt oder eine Fehlermeldung einem Formularelement hinzugefügt. ARIA-Attribute können in diesen Fällen das Verständnis bei der Nutzung mit einem Screenreader verbessern.

Als Widgets bezeichnet man Konstrukte aus HTML und CSS, denen mittels JavaScript Interaktionsverhalten gegeben wird. Für solche Komponenten hält die HTML-Spezifikation nur bedingt Elemente bereit, die entsprechende semantische Informationen zur Verfügung stellen.

Der ARIA-Webstandard bietet einen Satz von Attributen, um fehlende Semantik zu ergänzen, und erweitert damit das semantische Vokabular. Die Informationen, die bei einer semantischen HTML-Auszeichnung automatisch über die Accessibility API ausgegeben werden (Rolle, Name, Zustand), können mit Hilfe sogenannter ARIA-Rollen, -Zustände und -Eigenschaften (roles, states und properties) ausgedrückt werden.

Um es gleich vorweg zu sagen, die erste und wichtigste von 5 ARIA-Regeln des W3C-Dokuments Using ARIA lautet verkürzt: Wenn möglich, nutze das native HTML-Element, bevor du es mit ARIA-Attributen neu erfindest.

If you can use a native HTML element or attribute with the semantics and behaviour you require already built in, instead of re-purposing an element and adding an ARIA role, state or property to make it accessible, then do so.

— First Rule of ARIA Use

Drei Kategorien von ARIA-Attributen

Man unterscheidet drei wichtige Kategorien von Attributen:

ARIA-Attribute für Rollen (roles)

Mit den roles ist es möglich, nicht-semantischen Element eine Rolle zuzuweisen.

<div role="button">Video abspielen</div>

Beispiel: Ein <div>-Element, das mittels JavaScript klickbar gemacht werden soll, liefert semantisch keine Informationen. Dafür ist im Beispiel role="button" zuständig. Nur aufgrund der Auszeichnung mit dem Attribut ist das Element aber noch längst nicht tastaturbedienbar.

Wichtig: Der Browser verhält sich durch das role-Attribut nicht in gleicher Weise, wie er es bei einem nativen <button>-Element täte. ARIA-Attribute ändern nicht das Verhalten des Browsers und damit auch nicht das Verhalten der Elemente. Der Browser weiß also vorläufig nichts von der Fokussierbarkeit oder davon, dass die Schaltfläche auf bestimmte Tastatureingaben reagieren soll. ARIA-Attribute ändern lediglich die Darstellung im Accessibility Tree und damit die Ausgabe in assistiven Technologien.

Um die <div>-Schaltfläche tastaturbedienbar zu machen, muss explizit dafür gesorgt werden, dass sie über die TAB-Taste fokussiert werden kann. Der Einsatz eines tabindex-Attributs (mit dem Wert 0) macht die Schaltfläche per Tastatur fokussierbar.

Wenn Sie ein nicht-interaktives Element wie ein <div> verwenden und ein onclick-Attribut ergänzen oder einen entsprechenden EventListener per JavaScript registrieren, ist die Tastaturfunktionalität jedoch nicht automatisch gegeben, selbst wenn das Element ein tabindex-Attribut hat oder mit Hilfe eines Skripts fokussiert wird. Sie müssen zusätzlich das keydown- oder keyup-Ereignis überwachen und einen entsprechenden EventListener registrieren, damit die Schaltfläche mit Eingabe oder Leerzeichen bedient werden kann.

<div role="button" tabindex="0" onclick="playVideo()"
    onkeyup="if (event.keyCode == 32 || event.keyCode == 13) { playVideo() }">
        Video abspielen
</div>

Auf die beschriebene Weise ist es möglich, semantische Elemente nachzubauen. In der Regel sind solche Custom Controls jedoch nicht sinnvoll — sie sind viel aufwendiger und fehleranfälliger als funktional vergleichbare, native HTML-Elemente. Sinnvoll ist der Einsatz von ARIA-Rollen hauptsächlich bei Komponenten, für die es in HTML keine Entsprechung gibt, zum Beispiel bei einer Registernavigation (Tab Panel).

ARIA-Attribute für Zustände (states)

States sind Attribute, die den Zustand eines Elements wiedergeben. Der Wert ändert sich dynamisch aufgrund von Nutzereingaben. Ein wichtiges und hilfreiches Attribut ist beispielsweise aria-expanded. Es kann den Wert true oder false, also wahr oder falsch annehmen. Das Attribut vermittelt den Zustand von ein- und ausblendbaren Bereichen. Beispiele für weitere State-Attribute sind aria-checked, aria-selected oder aria-hidden (vergleiche Barrierefrei Verstecken).

<button aria-expanded="true">Menü</button>

Beispiel: Ein <button> blendet bei Aktivierung Inhalt ein. Der Wert von aria-expanded wechselt beim Drücken der Eingabetaste dynamisch von false zu true (muss per JavaScript implementiert werden) und der Screenreader gibt nach der Aktivierung der Schaltfläche erweitert aus. Wird der Bereich über die Schaltfläche geschlossen, so lautet die Ausgabe reduziert. Ist die Auszeichnung gar nicht vorhanden, schweigt der Screenreader nach entsprechender Aktion. Menschen, die nicht-sehend navigieren, können in dem Fall nicht erfassen, was beim Tastendruck passiert ist.

ARIA-Attribute für Eigenschaften (properties)

Properties sind Attribute, die das Element näher beschreiben oder Beziehungen zu anderen Elementen herstellen. Der Unterschied zu den states ergibt sich nur durch die Definition: Im Gegensatz zu den states wird der Wert der properties selten(er) dynamisch geändert, ist also tendenziell konstant. Typische Beispiele für properties sind das aria-label, aria-labelledby oder aria-activedescendants.

<button aria-label="Schließen">x</button>

Beispiel: Mit Hilfe eines aria-label-Attributs kann man einem Schließen-<button>, der mit einem x beschriftet ist, einen zugänglichen Namen (Schließen) geben. Der Wert ist eine Zeichenfolge. Achtung: Ein aria-label Attribut überschreibt eine vorhandene Beschriftung oder einen vorhandenen Link-Text.

Auch mit aria-labelledby kann man einen zugänglichen Namen zur Verfügung stellen. Das Attribut verweist auf ein anderes, im Dokument vorhandenes HTML-Element (zum Beispiel eine Überschrift) und nutzt dessen Text-Inhalt für die Beschriftung. Der Wert von aria-labelledby ist die eindeutige id des verknüpften Elements (es können auch mehrere Elemente verknüpft werden). Wie aria-label überschreibt auch aria-labelledby einen bereits vorhandenen zugänglichen Namen.

Widgets

WAI-ARIA ermöglicht es, Widgets so zu beschreiben, dass sie von assistiven Technologien zuverlässig interpretiert werden können und für Nutzende verständlich sind. Ein klassisches Beispiel ist eine Registernavigation (Tab Navigation). Mit diesem Bedienmuster lässt sich die von Desktop-Anwendungen bekannte Technik im Browser nachahmen.

Eine Tab Navigationbesteht aus einer meist horizontalen Navigationsleiste mit Reitern. Die Auswahl eines Reiters (Tab) blendet einen zugehörigen Inhalt ein (Registerkarte oder Tab Panel). Das Gerüst besteht aus HTML, für das Verhalten wird JavaScript eingesetzt. HTML hält für ein derartiges Konstrukt jedoch keine semantische Auszeichnung bereit.

Ist das Widget mit den korrekten ARIA-Rollen (role="tablist", role="tab" und role="tabpanel") ausgezeichnet, können Nutzende verstehen, um welche Komponente es sich handelt (Reiter, Registerkarte). Aufgrund des eingesetzten state-Attributs aria-selected wissen sie, ob der fokussierte Reiter ausgewählt ist oder nicht.

Jedem Widget-Typ ist ein zu erwartendes Interaktionsmuster zugeschrieben. Bei korrekter Screenreader-Ausgabe wird vorhersehbar, wie man damit interagieren kann, also welche Tasten für die Navigation zuständig sind.

Der ARIA Authoring Practices Guide des W3C unterstützen mit ausführlichen Informationen. Sie finden für jeden Widget-Typ:

  • Erläuterungen zur Bedeutung und Funktion der Widgets,
  • eine Auflistung der einzusetzenden ARIA-Rollen und -Attribute,
  • eine Beschreibung der zu erwartende Tastaturbedienung und
  • Praxis-Beispiele.

Da die Umsetzung von Widgets nicht ganz trivial ist, sollte sie sorgfältig geprüft werden:

  • Prüfen Sie, ob sie überhaupt ein ARIA-Widget benötigen, oder ob Sie nicht auch mit nativen Mitteln zurechtkommen.
  • Sie möchten eine bestimmte Funktion umsetzen? Gibt es gängige Widget-Typen, an denen Sie sich orientieren können?
  • Prüfen Sie, ob Sie alle für das Widget notwendigen ARIA-Rollen einsetzen.
  • Sorgen Sie für die ARIA-Rollen, aber auch für die erforderliche Zustands- oder Eigenschaftsattribute.
  • Setzen Sie nicht nur ARIA-Attribute ein. Machen Sie sich auch mit den erwarteten Interaktionsmustern für die Tastatur vertraut und sorgen Sie für die entsprechende Tastaturbedienung und das Fokusmanagement.
  • Erlangen Sie ein Verständnis davon, wie die Verwendung von ARIA-Attributen die Nutzung mit assistive Technologien beeinflusst.
  • Hilfreich ist, sich Praxis-Beispiele aus den Authoring Practices mit dem Screenreader anzuhören. Vergleichen Sie die Beispiele mit der eigenen Umsetzung.

Zusammenfassung

  1. Semantik ist für die Nutzbarkeit einer Webseite mit assistiven Technologien unabdingbar. Es sollte zu jeder Zeit sichergestellt sein, dass für jedes Element die richtige Rolle, ein zugänglicher Name und falls nötig der entsprechende Zustand über den Accessiblity Tree abgebildet und damit von der assistiven Technologie ausgegeben wird.
  2. Native HTML-Elemente bringen semantische Informationen mit. Der Browser sorgt dafür, dass sie an den Accessibility Tree übergeben werden. Interaktive HTML-Elemente sind fokussierbar und tastaturbedienbar. Eine Reihe von Browser-Funktionen sind im Standard definiert und müssen nicht nachgebaut werden.
  3. Verwenden Sie also möglichst native HTML-Elemente. Wenn Sie diese nachbauen, müssen Sie bei interaktiven Elementen für die Fokussierbarkeit sorgen, eine Rolle, den zugänglichen Namen und gegebenenfalls Zustände über entsprechende Attribute zur Verfügung stellen und explizit für die erwartete Tastaturbedienbarkeit sorgen.
  4. Orientieren Sie sich bei der Umsetzung von benutzerdefinierten Bedienelementen (Custom Controls) und Widgets an dem ARIA Authoring Practices Guide oder anderen bewährten Musterlösungen.
  5. ARIA ist ein Versprechen: ARIA-Attribute kann man nicht sehen, aber Sie versprechen mit einer bestimmten Auszeichnung Menschen, deren Hilfsmittel diese Attribute lesen, eine bestimmte Bedeutung und ein Interaktionsmuster. Halten Sie sich an ihr Verspechen.

Ressourcen

Weiterführende Informationen, darunter Links auf zusätzliche Ressourcen, bieten unter anderem diese englischsprachigen Artikel: