Wie Sie aufhören zu raten, wenn Sie barrierefreie Interfaces erstellen

Haben Sie sich jemals gefragt, warum sich eine gewöhnliche Schaltfläche im Web manchmal merkwürdig verhält, wenn Sie versuchen, sie mit der Tastatur anzuklicken? Oder warum ein Screenreader plötzlich Unsinn erzählt, wenn Sie ein Modal öffnen? Normalerweise liegt das Problem an ARIA-Attributen. Wir sind es gewohnt, sie „nach Augenmaß" hinzuzufügen, in der Hoffnung, dass aria-label oder role="button" magisch schlechte Semantik beheben. Aber Barrierefreiheit ist keine Magie – es sind strenge Interaktionsmuster.

Im w3c/aria-practices Repository liegt das, was ich als „die Bibel des Frontend-Entwicklers" bezeichne. Es ist nicht nur eine langweilige Spezifikation, sondern ein lebendiger Authoring Practices Guide (APG), der genau erklärt, wie Dropdowns, Tabs, Slider und Akkordeons funktionieren sollten, damit absolut jeder sie nutzen kann.

Worum es bei diesem Projekt geht

Das Projekt wird von einer W3C-Arbeitsgruppe geleitet. Im Wesentlichen sind dies die Menschen, die Webstandards erfinden. Im Repository sammeln sie Referenzbeispiele für die Implementierung von Interface-Mustern. Wenn Sie nicht wissen, ob der Fokus nach dem Schließen eines Modals zum Button zurückkehren sollte, oder welche Pfeiltasten Tabs wechseln sollten – hier schauen Sie nach.

Viele Entwickler betrachten Barrierefreiheit (a11y) immer noch als etwas Optionales. Aber wenn ein Projekt wächst, wird das Fehlen einer ordentlichen Tastaturnavigation zur technischen Schuld. Dieses Repository hilft, diese Schuld bereits bei der Komponentenentwicklung zu vermeiden.

Was dieses Repository bietet

Darin finden Sie nicht nur trockene Regeln, sondern funktionierende Codebeispiele. Hier sind einige Dinge, auf die ich in diesem Projekt ständig zurückgreife.

Fertige Designmuster

Für jedes komplexe Element (zum Beispiel Combobox oder Tree View) gibt es einen separaten Bereich. Er beschreibt das erwartete Tastaturverhalten und erforderliche Rollen. Dies eliminiert die Notwendigkeit, das Rad neu zu erfinden. Sie nehmen einfach die Liste der Anforderungen und prüfen Ihre Komponente dagegen.

Referenz-Codebeispiele

Im Ordner examples gibt es Implementierungen in reinem HTML, CSS und JavaScript. Es gibt keine unnötigen Abstraktionen, React oder Vue – nur pure Barrierefreiheitslogik. Das ist praktisch, wenn Sie verstehen müssen, wie Sie id Elemente über aria-controls oder aria-labelledby verknüpfen, damit der Screenreader den Kontext korrekt ansagt.

Testen und Linting

Interessanterweise verwenden die Autoren striktes Linting. Sie validieren HTML durch den NU HTML Validator und JS und CSS durch standardmäßiges ESLint und Stylelint. Wenn Sie sich entscheiden, zum Projekt beizutragen, müssen Sie das JDK für den HTML-Validator installieren. Das zeigt die Ernsthaftigkeit: Selbst in Codebeispielen wird kein einziger Validierungsfehler toleriert.

Wie Sie dies in Ihrer Arbeit nutzen

Ich nutze dieses Repository oft als Checkliste. Zum Beispiel schreibe ich ein benutzerdefiniertes Select. Anstatt nach „wie man ein barrierefreies Select erstellt" zu googeln, gehe ich zu APG und schaue mir den Bereich Select-Only Combobox an.

Dort finde ich:

1. Welche Attribute das übergeordnete Element benötigt.
2. Wie man den aria-expanded-Zustand verwaltet.
3. Was beim Drücken der Tasten Home, End oder PageUp passieren sollte.

Übrigens hat das Repository Skripte für automatisiertes Testen der Beispiele. Der Befehl npm test führt Tests aus, die das Elementverhalten im Browser überprüfen. Das ist ein großartiges Beispiel dafür, wie Sie Barrierefreiheitstests in Ihren eigenen Projekten automatisieren können.

Die technische Seite

Das Projekt läuft auf Node.js. Um lokal damit zu arbeiten, benötigen Sie:

• Node.js und npm zum Ausführen von Lintern und Tests.
• JDK (Java Development Kit) für HTML-Validierung.

Interessanter Punkt: Das Projekt hat automatisches Beheben von Fehlern bei Commits konfiguriert. Wenn Sie Leerzeichen in CSS vermasselt oder camelCase in JavaScript vergessen haben, versucht der Linter, es selbst zu korrigieren, bevor der Code ins Repository gelangt.

Für wen ist aria-practices gedacht?

Vor allem – Komponentenbibliotheksentwickler. Wenn Sie Ihr eigenes Design-System schreiben, ist es keine Option, diese Praktiken zu ignorieren. Das Projekt ist auch für QA-Ingenieure nützlich: Sie können hier genau finden, wie sich ein Interface beim Testen der Barrierefreiheit verhalten sollte.

Ich werde nicht sagen, dass das Lesen dieses Repositories leichte Abendunterhaltung ist. Die Texte sind trocken und es gibt viele Anforderungen. Aber es ist der einzige Weg, Interfaces zu erstellen, die wirklich für jeden funktionieren, nicht nur für diejenigen, die eine Maus verwenden.

Wenn Sie es leid sind, dass Ihre Modals beim Schließen „ans Ende der Seite fliegen", oder endlich verstehen wollen, wozu aria-live dient, klonen Sie einfach dieses Repository und schauen Sie, wie die Profis vom W3C es machen. Link zum Projekt: w3c/aria-practices.