ARIA und HTML

Die meisten Entwickler sind mit der Standardauszeichnungssprache des modernen Webs vertraut: HyperText Markup Language (HTML). Weniger bekannt ist jedoch Accessible Rich Internet Applications (ARIA) (früher WAI-ARIA): Was ist es, wie wird es verwendet und wann sollte es verwendet werden – und wann nicht –?

HTML und ARIA spielen eine wichtige Rolle bei der Barrierefreiheit digitaler Produkte, insbesondere im Hinblick auf Hilfstechnologien wie Screenreader. Beide werden verwendet, um Inhalte in ein alternatives Format zu konvertieren, z. B. in Braille oder Text-to-Speech (TTS).

Hier finden Sie einen kurzen Überblick über die Geschichte von ARIA, warum es wichtig ist und wann und wie es am besten verwendet wird.

Einführung in ARIA

ARIA wurde 2008 von der Web Accessibility Initiative (WAI) entwickelt, einer Untergruppe des World Wide Web Consortium (W3C), das das Internet verwaltet und reguliert.

ARIA ist keine echte Programmiersprache, sondern eine Reihe von Attributen, die Sie HTML-Elementen hinzufügen können, um ihre Barrierefreiheit zu verbessern. Diese Attribute kommunizieren Rolle, Status und Eigenschaft an Hilfstechnologien über Barrierefreiheits-APIs, die in modernen Browsern zu finden sind. Diese Kommunikation erfolgt über die Baumansicht für Barrierefreiheit.

"WAI-ARIA, die Accessible Rich Internet Applications Suite, definiert eine Möglichkeit, Webinhalte und Webanwendungen für Menschen mit Behinderungen barrierefreier zu gestalten. Dies ist besonders hilfreich bei dynamischen Inhalten und erweiterten Benutzeroberflächen-Steuerelementen, die mit HTML, JavaScript und verwandten Technologien entwickelt wurden."

Die WAI-Gruppe

Baumansicht für Barrierefreiheit

ARIA ändert fehlerhaften oder unvollständigen Code, um die Nutzerfreundlichkeit für Nutzer von Hilfstechnologien zu verbessern, indem Teile der Baumansicht für Barrierefreiheit geändert, offengelegt und erweitert werden.

Die Baumansicht für Barrierefreiheit wird vom Browser erstellt und basiert auf der Standardbaumansicht des Document Object Model (DOM). Wie die DOM-Baumansicht enthält auch die Baumansicht für Barrierefreiheit Objekte, die alle Auszeichnungselemente, Attribute und Textknoten darstellen. Die Baumansicht für Barrierefreiheit wird auch von plattformspezifischen Barrierefreiheits-APIs verwendet, um eine Darstellung zu liefern, die von Hilfstechnologien verstanden werden kann.

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

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

Rollen definieren, was ein Element auf der Seite oder in der App ist oder tut.

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

Eigenschaften drücken Merkmale oder Beziehungen zu einem Objekt aus.

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

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

Zustände und 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 in einer Codezeile verwendet werden, sind aber nicht erforderlich. Stattdessen können Sie ARIA-Rollen, ‑Eigenschaften und ‑Status oder ‑Werte schrittweise hinzufügen, bis Sie Ihr endgültiges Ziel in Bezug auf die Barrierefreiheit erreicht haben. Wenn Sie ARIA korrekt in Ihre Codebasis einbinden, haben Nutzer von Hilfstechnologien alle Informationen, die sie benötigen, um Ihre Website, App oder andere digitale Produkte erfolgreich und gleichberechtigt zu nutzen.

Vor Kurzem wurde in den Chrome-Entwicklertools eine Möglichkeit geschaffen, die vollständige Baumansicht für Barrierefreiheit zu sehen. So können Entwickler besser nachvollziehen, wie sich ihr Code auf die Barrierefreiheit auswirkt.

Wann sollte ARIA verwendet werden?

2014 veröffentlichte das W3C offiziell die HTML5-Empfehlung. Damit einher gingen einige große Änderungen, darunter die Hinzufügung von Landmark-Elementen wie <main>, <header>, <footer>, <aside>, <nav>, und Attributen wie hidden und required. Mit diesen neuen HTML5-Elementen und ‑Attributen sowie der verbesserten Browserunterstützung sind bestimmte Teile von ARIA jetzt weniger wichtig.

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

Das führt uns zur entscheidenden Frage: Wann sollten Sie ARIA verwenden? Glücklicherweise hat die WAI-Gruppe die fünf Regeln von ARIA entwickelt, um Ihnen bei der Entscheidung zu helfen, wie Sie Elemente barrierefrei gestalten können.

Regel 1: ARIA nicht verwenden

Ja, Sie haben richtig gelesen. Wenn Sie einem Element ARIA hinzufügen, wird es nicht automatisch barrierefreier. Im jährlichen WebAIM Million-Bericht zur Barrierefreiheit wurde festgestellt, dass auf Startseiten mit ARIA durchschnittlich 70% mehr Fehler erkannt wurden als auf Startseiten ohne ARIA. Das liegt hauptsächlich an der unsachgemäßen Implementierung der ARIA Attribute.

Es gibt Ausnahmen von dieser Regel. ARIA ist erforderlich, wenn ein HTML-Element keine Unterstützung für Barrierefreiheit bietet. Das kann daran liegen, dass das Design kein bestimmtes HTML-Element zulässt oder die gewünschte Funktion oder 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: HTML nicht mit (unnötigem) ARIA ergänzen

In den meisten Fällen funktionieren HTML-Elemente so, wie sie sind, und müssen nicht mit zusätzlichem ARIA ergänzt werden. Tatsächlich müssen Entwickler, die ARIA verwenden, häufig 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 vorgesehen verwenden, haben Sie weniger Arbeit und der Code ist leistungsfähiger.

Regel 3: Immer Tastaturnavigation unterstützen

Alle interaktiven (nicht deaktivierten) ARIA-Steuerelemente müssen über die Tastatur zugänglich sein. Sie können jedem Element, das einen Fokus benötigt, der normalerweise keinen Tastaturfokus erhält, `tabindex= "0"` hinzufügen. Vermeiden Sie nach Möglichkeit die Verwendung von Tab-Indexen mit positiven Ganzzahlen , um potenzielle Probleme mit der Reihenfolge des Tastaturfokus zu vermeiden.

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

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

Regel 4: Fokusierbare Elemente nicht ausblenden

Fügen Sie Elementen, die einen Fokus haben müssen, nicht role= "presentation" oder aria-hidden= "true" hinzu. Das gilt auch für Elemente mit tabindex= "0". Wenn Sie diesen Elementen diese Rollen und Status hinzufügen, wird an die Hilfstechnologie gesendet, dass diese Elemente nicht wichtig sind und übersprungen werden sollen. Das kann zu Verwirrung führen oder Nutzer stören, die 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 mitgeteilt werden, bevor er weiß, wie er damit interagieren kann. Achten Sie darauf, dass alle Elemente einen barrierefreien Namen für Nutzer von Hilfstechnologien haben.

Barrierefreie Namen können der Inhalt sein, der von einem Element umgeben ist (im Fall von einem <a>), Alternativtext oder eine Beschriftung.

In allen folgenden Codebeispielen ist der barrierefreie Name „Red leather boots“.

<!-- 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, z. B. indem Sie die Baumansicht für Barrierefreiheit mit den Chrome-Entwicklertools untersuchen oder ihn mit einem Screenreader testen.

ARIA in HTML

Die Verwendung von HTML-Elementen allein ist zwar die beste Vorgehensweise, in bestimmten Situationen können jedoch ARIA-Elemente hinzugefügt werden. Sie können ARIA beispielsweise mit HTML in Mustern kombinieren, die aufgrund von Umgebungsbeschränkungen eine höhere Unterstützung für Hilfstechnologien erfordern, 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. Am wichtigsten ist, dass Sie die Standard-HTML-Rollen nicht überschreiben, Redundanz reduzieren und sich der unbeabsichtigten Nebenwirkungen bewusst sind.

Hier einige Beispiele:

<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 immer vorsichtig sein, wenn Sie es verwenden. Die Codebeispiele in dieser Lektion sind zwar recht einfach, aber das Erstellen barrierefreier benutzerdefinierter Muster kann schnell kompliziert werden.

Es gibt viele Dinge zu beachten, einschließlich, aber nicht beschränkt auf: Tastaturinteraktionen, Touch-Oberflächen, Unterstützung für Hilfstechnologien/Browser, Übersetzungsanforderungen, Umgebungsbeschränkungen, Legacy-Code und Nutzereinstellungen. Ein wenig Programmierkenntnisse können schädlich oder einfach nur ärgerlich sein, wenn sie falsch eingesetzt werden.

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 Codierungslösungen als „richtig“ angesehen werden. Wichtig ist, dass Sie weiter lernen, testen und versuchen, unsere digitale Welt für alle offener zu gestalten.