ARIA und HTML

Die meisten Entwickler sind mit der Standard-Auszeichnungssprache unseres modernen Webs, der HyperText Markup Language (HTML), vertraut. Möglicherweise sind Sie jedoch weniger vertraut mit Accessible Rich Internet Applications (ARIA) (früher WAI-ARIA): was es ist, wie es verwendet wird und wann – und wann nicht – es verwenden sollten.

HTML und ARIA spielen eine wichtige Rolle bei der Barrierefreiheit digitaler Produkte, insbesondere wenn es um assistive Technologien (AT) wie Screenreader geht. Beide werden verwendet, um Inhalte in ein alternatives Format wie Braille oder Text-to-Speech (TTS) zu konvertieren.

Sehen wir uns einen kurzen Überblick über ARIA an, warum sie wichtig ist, wann und wie sie am besten verwendet wird.

Einführung in ARIA

ARIA wurde 2008 von der Web Accessibility Initiative (WAI) entwickelt, einer Untergruppe des übergreifenden World Wide Web Consortiums (W3C), das das Internet regelt und regelt.

ARIA ist keine echte Programmiersprache, sondern eine Reihe von Attributen, die Sie HTML-Elementen hinzufügen können, um deren Zugänglichkeit zu verbessern. Diese Attribute kommunizieren Rolle, Status und Eigenschaft über Bedienungshilfen-APIs, die in modernen Browsern zu finden sind, an Hilfstechnologien. Diese Kommunikation erfolgt über die Barrierefreiheitsstruktur.

„WAI-ARIA, die Accessible Rich Internet Applications Suite, definiert eine Möglichkeit, Webinhalte und Webanwendungen für Menschen mit Behinderungen zugänglicher zu machen. Besonders hilfreich sind sie bei dynamischen Inhalten und erweiterten Steuerelementen für die Benutzeroberfläche, die mit HTML, JavaScript und ähnlichen Technologien entwickelt wurden.“

Die WAI-Gruppe

Baum für Barrierefreiheit

ARIA ändert falschen oder unvollständigen Code, um Nutzern von AT ein besseres Erlebnis zu bieten. Dazu werden Teile des Baums für Barrierefreiheit geändert, freigegeben und erweitert.

Sie wird vom Browser erstellt und basiert auf der standardmäßigen DOM-Struktur (Document Object Model). Wie der DOM-Baum enthält der Baum für Barrierefreiheit Objekte, die alle Markup-Elemente, Attribute und Textknoten darstellen. Der Baum für Barrierefreiheit wird auch von plattformspezifischen Bedienungshilfen-APIs verwendet, um eine Darstellung zu liefern, die assistive Technologien verstehen können.

ARIA allein ändern weder die Funktionalität noch das visuelle Erscheinungsbild eines Elements. Das bedeutet, dass nur AT-Nutzende Unterschiede zwischen einem digitalen Produkt mit und einem ohne ARIA bemerken werden. Das bedeutet auch, dass die Entwickler allein dafür verantwortlich sind, den entsprechenden Code und Stil zu ändern, um ein Element so barrierefrei wie möglich zu gestalten.

Die drei Hauptfunktionen von ARIA sind Rollen, Eigenschaften und Status/Werte.

Mit Rollen wird definiert, was ein Element auf der Seite oder in der App ist oder tut.

<div role="button">Self-destruct</div>

Mit Eigenschaften werden Eigenschaften oder Beziehungen zu einem Objekt ausgedrückt.

<div role="button" aria-describedby="more-info">Self-destruct</div>

<div id="more-info">This page will self-destruct in 10 seconds.</div>

Status/Werte definieren die aktuellen Bedingungen oder Datenwerte, die mit dem Element verknüpft sind.

<div role="button" aria-describedby="more-info" aria-pressed="false">
  Self-destruct
</div>

<div id="more-info">
  This page will self-destruct in 10 seconds.
</div>

Alle drei Elemente von ARIA können zwar in einer Codezeile verwendet werden, dies ist aber nicht erforderlich. Ordnen Sie stattdessen ARIA-Rollen, -Eigenschaften und -Zustände/-Werte zu, bis Sie Ihr endgültiges Ziel für die Barrierefreiheit erreicht haben. Durch die korrekte Einbindung von ARIA in Ihre Codebasis wird sichergestellt, dass AT-Nutzer alle Informationen haben, die sie benötigen, um Ihre Website, App oder ein anderes digitales Produkt erfolgreich und fair zu verwenden.

Seit Kurzem gibt es in den Chrome-Entwicklertools eine vollständige Liste der Bedienungshilfen, mit der Entwickler leichter nachvollziehen können, wie sich ihr Code auf die Barrierefreiheit auswirkt.

Wann ist ARIA zu verwenden?

2014 veröffentlichte W3C offiziell die HTML5-Empfehlung. Darunter gab es einige große Änderungen, unter anderem um Orientierungspunkte wie <main>, <header>, <footer>, <aside>, <nav> und Attribute wie hidden und required. Mit diesen neuen HTML5-Elementen und -Attributen sowie der verbesserten Browserunterstützung sind bestimmte Teile von ARIA jetzt weniger kritisch.

Wenn der Browser ein HTML-Tag mit einer impliziten Rolle mit einem ARIA-Äquivalent unterstützt, ist es normalerweise nicht erforderlich, dem Element ARIA hinzuzufügen. ARIA enthält jedoch viele Rollen, Status und Eigenschaften, die in keiner HTML-Version verfügbar sind. Diese Attribute bleiben vorerst nützlich.

Damit kommen wir zur letzten Frage: Wann sollten Sie ARIA verwenden? Glücklicherweise hat die WAI-Gruppe die fünf Regeln von ARIA entwickelt, die Ihnen bei der Entscheidung helfen sollen, wie Elemente zugänglich gemacht werden.

Regel 1: ARIA nicht verwenden

Ja, du hast richtig gelesen. Das Hinzufügen von ARIA zu einem Element macht es nicht grundsätzlich barrierefrei. Laut dem jährlichen WebAIM Million-Bericht zur Barrierefreiheit wurden auf Startseiten mit ARIA durchschnittlich 70% mehr Fehler erkannt als auf Startseiten ohne ARIA. Hauptgrund hierfür ist eine falsche Implementierung der ARIA-Attribute.

Es gibt Ausnahmen von dieser Regel. ARIA ist erforderlich, wenn ein HTML-Element keine Bedienungshilfen unterstützt. Dies könnte daran liegen, dass das Design ein bestimmtes HTML-Element nicht zulässt oder die gewünschte Funktion bzw. das gewünschte Verhalten in HTML nicht verfügbar ist. Diese Situationen sollten jedoch selten sein.

<a role="button">Submit</a>

<button>Submit</button>

Verwenden Sie im Zweifelsfall semantische HTML-Elemente.

Regel 2: Keine (unnötige) ARIA zu HTML hinzufügen

In den meisten Fällen funktionieren HTML-Elemente sofort gut, sodass keine zusätzlichen ARIA-Elemente hinzugefügt werden müssen. Tatsächlich müssen Entwickler, die ARIA verwenden, oft zusätzlichen Code hinzufügen, damit die Elemente bei interaktiven Elementen funktionieren.

<h2 role="tab">Heading tab</h2>

<div role="tab"><h2>Heading tab</h2></div>

Wenn Sie HTML-Elemente wie gewünscht verwenden, sparen Sie Arbeit und erzielen einen leistungsstärkeren Code.

Regel 3: Tastaturnavigation immer unterstützen

Alle interaktiven (nicht deaktivierten) ARIA-Steuerelemente müssen per Tastatur zugänglich sein. Sie können tabindex= "0" jedem Element hinzufügen, das einen Fokus erfordert, der normalerweise nicht über die Tastatur ausgerichtet wird. Vermeiden Sie nach Möglichkeit die Verwendung von Tabindexen mit positiven Ganzzahlen, um potenzielle Probleme mit der Tastaturfokusreihenfolge zu vermeiden.

<span role="button" tabindex="1">Submit</span>

<span role="button" tabindex="0">Submit</span>

Regel 4: Fokussierbare Elemente nicht ausblenden

Fügen Sie role= "presentation" oder aria-hidden= "true" nicht zu Elementen hinzu, die im Fokus sein müssen, einschließlich Elementen mit tabindex= "0". Wenn Sie diese Rollen/Status zu Elementen hinzufügen, wird dem AT mitgeteilt, dass diese Elemente nicht wichtig sind und sie übersprungen werden sollen. Dies kann zu Verwirrung führen oder Nutzende stört, wenn sie versuchen, mit einem Element zu interagieren.

<div aria-hidden="true"><button>Submit</button></div>

<div><button>Submit</button></div>

Regel 5: Barrierefreie Namen für interaktive Elemente verwenden

Der Zweck eines interaktiven Elements muss einem Nutzer vermittelt werden, bevor er weiß, wie er damit interagieren kann. Achten Sie darauf, dass alle Elemente einen zugänglichen Namen für Personen haben, die AT-Geräte verwenden.

Barrierefreie Namen können Inhalte sein, die von einem Element (bei einem <a>), alternativem Text oder einem Label umgeben sind.

Für jedes der folgenden Codebeispiele lautet der barrierefreie Name „Rote Lederstiefel“.

<!-- A plain link with text between the link tags. -->
<a href="shoes.html">Red leather boots</a>

<!-- A linked image, where the image has alt text. -->
<a href="shoes.html"><img src="shoes.png" alt="Red leather boots"></a>

<!-- A checkbox input with a label. -->
<input type="checkbox" id="shoes">
<label for="shoes">Red leather boots</label>

Es gibt viele Möglichkeiten, den barrierefreien Namen eines Elements zu prüfen. Sie können zum Beispiel den Baum für Bedienungshilfen mit den Chrome-Entwicklertools prüfen oder ihn mit einem Screenreader testen.

ARIA in HTML

Die Verwendung eigener HTML-Elemente hat sich bewährt, in bestimmten Situationen können jedoch auch ARIA-Elemente hinzugefügt werden. Sie können beispielsweise ARIA mit HTML in Mustern kombinieren, die aufgrund von Umgebungseinschränkungen eine höhere AT-Unterstützung benötigen, oder als Fallback-Methode für HTML-Elemente, die nicht von allen Browsern vollständig unterstützt werden.

Natürlich gibt es Empfehlungen für die Implementierung von ARIA in HTML. Das Wichtigste: Überschreiben Sie nicht die Standard-HTML-Rollen, reduzieren Sie die Redundanz und achten Sie auf unbeabsichtigte Nebenwirkungen.

Sehen wir uns einige Beispiele an.

<a role="heading">Read more</a>

<a aria-label="Read more about some awesome article title">Read More</a>

<ul role="list">...</ul>

<ul>...</ul>

<details>
  <summary role="button">more information</summary>
  ...
</details>

<details>
  <summary>more information</summary>
  ...
</details>

Komplexität von ARIA

ARIA ist komplex und Sie sollten bei der Verwendung immer vorsichtig sein. Die Codebeispiele in dieser Lektion sind recht simpel, das Erstellen barrierefreier benutzerdefinierter Muster kann jedoch schnell kompliziert werden.

Es gibt viele Dinge zu beachten, einschließlich, aber nicht beschränkt auf: Tastaturinteraktionen, Touch-Oberflächen, AT-/Browser-Unterstützung, Übersetzungsanforderungen, umgebungsbezogene Einschränkungen, Legacy-Code und Nutzereinstellungen. Ein wenig Programmierwissen kann bei falscher Anwendung nachteilig – oder einfach nur lästig – sein. Halten Sie Ihren Code einfach.

Abgesehen von diesen Warnungen ist die digitale Barrierefreiheit keine Alles-oder-Nichts-Situation, sondern ein Spektrum, das einige Grauzonen wie diese zulässt. Je nach Situation können mehrere Programmierlösungen als „richtig“ angesehen werden. Wichtig ist, dass Sie immer wieder dazulernen, Tests durchführen und versuchen, unsere digitale Welt für alle offener zu gestalten.

Überprüfen Sie Ihr Wissen

Testen Sie Ihr Wissen über ARIA und HTML