Barrierefreiheit prüfen mit dem Accessibility Tree

Grundlagen Tutorials
Video zum Artikel Abspielen

Testen ist wichtig

Testen während des Programmierens ist nicht nur für das Endergebnis wichtig, sondern auch zum Lernen. Um schnell und effektiv zu lernen, ob dein Ansatz richtig oder falsch war, benötigst du stetiges und klares Feedback. Sonst bleibst du jemand, der ziellos im Nebel stochert, worin dich KI bald überholen wird. Dies ist übrigens auch der Grund, warum Unit-Tests auch beim Entwickeln so hilfreich sind. Sie zeigen dir sofort an, wenn du etwas kaputt gemacht hast.

Web Accessibility Tree ist essentiell

Gerade für Einsteiger ins Thema ist der Accessibility Tree (A11Y Tree) das Tool Nr. 1, um Barrierefreiheit während der Webentwicklung zu prüfen. Meine dringende Empfehlung an alle Web Devs ist, zuerst damit zu üben, bevor ihr euch ins Testen mit Screenreader stürzt. Man nutzt dafür die Devtools im Browser, die Methode fügt sich also deutlich nahtloser in den Prozess ein als ein Screenreadertest.

Der Accessibility Tree ist die Landkarte deiner App oder Website für Screenreader

Für Screenreader und andere assistive Technologien wie z.B. Sprachsteuerung ist der A11Y Tree die einzige und autoritäre Informationsquelle zu deiner Website oder App. Er beschreibt wie eine Landkarte alle Steuerelemente (Controls), mit denen Nutzer deiner App oder Website interagieren können. Wenn ich im Folgenden von Screenreadern schreibe, sind andere Bedienungshilfen mit eingeschlossen.

Es geht bei diesem Thema immer um die angezeigten Controls, das solltest du unbedingt im Kopf behalten. HTML- oder FXML-Elemente sind noch keine Controls, der Browser rendert sie erst zu Controls. Screenreader lesen nicht deinen HTML-Code aus, um deine Website für Nutzer zugänglich zu machen. Stattdessen fragen sie den Browser nach einem Accessibility Tree, um sich orientieren zu können. Das gilt ebenso auch für native Anwendungen, dort fragen sie eben die Anwendung.

So gesehen lesen Screenreader auch nicht den Screen, sondern eine Beschreibung seines Inhalts. Sowohl visuelle Ansicht als auch A11Y Tree reflektieren Änderungen aus dem DOM.

Warum ist das wichtig für Entwickler?

  1. Fehler auf der Ebene des A11y Tree werden voraussichtlich alle Screenreader mehr oder weniger betreffen. Sogar wenn du bloß ein Liebhaber von Tastaturbedienung bist, wirst du Mängel auf der Ebene des A11Y Tree bemerken. Probleme hier abzufangen ist somit sinnvoll.
  2. Jeder Screenreader hat seine eigene konventionen, wie er welche Elemente vorliest. Das ist wahnsinnig inkonsistent und verwirrend, und regelmäßig eine Quelle für Ablenkung und Unsicherheit. Übung mit dem A11Y Tree kann dir mehr Sicherheit und Selbstbewusstsein geben bei der Einschätzung, ob die notwendigen Informationen zumindest prinzipiell für AT zugänglich sind.

Deine wichtigste Aufgabe ist, Zugänglichkeit zu schaffen, indem du bei deiner App oder Website für einen möglichst korrekten A11Y Tree sorgst. Wenn das fehlt, kann der beste Screenreader und die gründlichsten Screenreadertests der Welt wenig ausrichten.

Accessibility Tree im Browser anzeigen

Firefox bietet hier die beste Unterstützung, daher solltest du bitte einen Firefox parat haben.

  1. Öffne irgendeine Seite im Browser oder etwas, woran du gerade arbeitest, oder bleibe einfach auf diesem Artikel. ;-)
  2. Wähle ein Element aus und öffne sein Kontextmenü.
  3. Wähle „Barrierefreiheitseigenschaften untersuchen“

Der A11Y Tree öffnet sich gleich an der Stelle, die deinem ausgewählten Element entspricht. Er ist eine Baumstruktur und folgt einem bestimmten Standard: ARIA (Accessible Rich Internet Applications).1

Barrierefreiheitsansicht in Firefox für diesen Artikel mit ausgewählter Titelüberschrift

Accessibility Tree lesen

Es geht um Controls und ihre Beschreibung, wie oben schon erklärt wurde. Jedes Element im A11Y Tree beschreibt ein Control und lässt sich auf ein DOM-Node zurückführen. In der Barrierefreiheitsansicht auf der rechten Seite werden die Eigenschaften des ausgewählten Control angezeigt. Die allerwichtigsten Eigenschaften eines jeden Control sind

  1. name ist die individuelle Bezeichnung für dieses Control. Sie ist i.d.R. aus dem Text des entsprechenden DOM-Node abgeleitet und wird von Screenreadern vorgelesen, auch wenn das Control noch Kindelemente hat.
  2. role beschreibt semantisch, welche Art von Control es ist, was es kann und welche Inhalte es anzeigt. Der ARIA-Standard legt fest, welche Rollen es gibt.
  3. description (optional) ist ein zusätzlicher Hilfetext. Er entspricht vom Prinzip her einem Tooltip, also ein Ort für Hinweise, die sich nicht sofort aufdrängen sollen, sondern nur bei Interesse sichtbar werden.

Hier ein paar Beispiele für Rollen ohne und mit Interaktionsfähigkeit:

Damit ein Screenreader die Spezialfähigkeiten eines Control nutzen kann, muss jeweils die richtige Rolle gesetzt sein. Bei semantisch geschriebenem HTML ist das meistens bereits der Fall, weil der Browser für viele HtML-Tags eine sinnvolle Rolle ableiten kann. Das heißt also: Je besser dein HTML, desto weniger Arbeit hast du hinterher mit Nachbessern.

Viele Rollen erfordern noch jeweils bestimmte zusätzliche Eigenschaften, damit ihre Funktionsweise vollständig beschrieben ist und Screenreader damit richtig umgehen können. Auch für Tastaturnavigation ohne Screenreader machen Fehler sich schnell bemerkbar. Zu einem vol funktionsfähigen button gehört z.B.:

Hier jede Rolle und ihre Anforderungen zu beschreiben würde den Rahmen dieses Artikels sprengen, der Standard ist sehr umfangreich. Um den Lernprozess abzukürzen, kannst du natürlich auch mich und meine Dienstleistungen in Anspruch nehmen.

Accessibility Tree korrigieren

Nochmal zur Erinnerung: Das DOM ist die Grundlage, und somit auch dein HTML. Der Browser bemüht sich, aus dem DOM einen möglichst guten A11Y Tree zu erstellen. Je semantischer dein HTML, desto besser das Ergebnis.

<a href="/register/">Registrieren</a>

Bild mit Alternativtext

<img src="/images/doc.png" alt="Hund"/>

Button

<button type="button">Submit</button>

Kaputter Fake-Button

Die HTML-Tags div und span führen zu recht armseligen A11Y Trees ohne Semantik.

<span id="submitButton" class="btn btn-primary">Submit</span>

Reparierter Button

Hier musst du entweder sinnvollere Elemente nutzen (bevorzugt), oder mit speziellen HTML-Attributen den A11Y Tree ergänzen.

<span role="button" tabindex="0" id="submitButton" class="btn btn-primary">Submit</span>

Die aria-*-Attribute können besonders für komplexere Fälle zum Patchen des A11Y Tree genutzt werden.

<button aria-label="Toggle Menu" aria-expanded="false">
  <svg class="menu-icon" aria-hidden="true"></svg>
</button>

Bitte versuche, möglichst viel gutes und semantisches HTML zu schreiben und ARIA-Attribute nur als Notfall-Override für den letzten Schliff zu nutzen. Das hilft übrigens auch der SEO, und automatisierte A11Y-Tests kommen zu genaueren Ergebnissen. Der Umgang mit den ARiA-Attributen in komplexeren Szenarien erfordert zudem sehr viel Einarbeitungszeit. Du kannst die Referenzen unten nutzen und es auf eigene Faust versuchen, schneller und effizienter ist jedoch das Hinzuziehen von Expertise und Erfahrungswerten.

Fazit

Du hast nun eine einsteigerfreundliche Methode an der Hand, mit der du starten solltest und die du dir am besten beim Entwickeln angewöhnen solltest. Mit der Zeit wirst du sicherer werden im Umgang mit A11Y-Themen und du wirst besser nachvollziehen können, warum ein Screenreader eigentlich dies oder jenes (nicht) vorliest.

Referenzen

Fußnoten

  1. Ich frage mich, warum es noch keinen Validator gibt, der diese Datenstruktur validieren könnte. Das wäre eigentlich naheliegender als das HTML zu validieren. Vermutlich weil der Standard definiert wurde, lange bevor JSON populär wurde. ↩