Toolkit · Für Entwickler

Web-Barrierefreiheit für Entwickler — gemacht für Ingenieure, die die Ursache beheben statt ein Overlay zu liefern

Der ingenieursorientierte Teil der Website. Semantische HTML-Muster, ARIA-Roles, die in der Produktion funktionieren, screenreader-kompatible Test-Harnesses, CI-Integrationsrezepte und der aktuelle Stand der Tastaturunterstützung nach Framework.

Kuratiert als Einstiegspunkt: die Muster, Tools, Test-Harnesses und Framework-spezifischen Leitfäden, die Entwicklerinnen und Entwickler tatsächlich benötigen, um barrierefreie Features ohne Overlay-Theater zu liefern. Verknüpft mit dem kostenlosen WCAG-2.2-Scanner für einmalige Triage und dem Monitoring-Einkaufsführer für kontinuierliche Abdeckung.

Die vier Engineering-Praktiken, die wirklich etwas bewegen

Klar positioniert. Nicht erschöpfend. Die Muster, die — konsequent angewendet — die meisten Barrierefreiheits-Regressionen vor dem Code-Review eliminieren.

Semantisches HTML zuerst, ARIA danach

Wenn natives HTML die Aufgabe erfüllt, sollten Sie es verwenden. <button> bringt Tastaturunterstützung, Fokus, Rolle und Enter/Space-Aktivierung bereits mit; <label> verknüpft ein Steuerelement mit seiner Beschreibung; <dialog> liefert das Fokus-Trap- und Inert-Verhalten für den Rest der Seite, das man sonst manuell implementieren müsste; <details> ist ein Disclosure-Widget ohne jegliches JavaScript. ARIA ist der Ausweg — nützlich, wenn kein natives Element für die Aufgabe existiert, schädlich, wenn es über ein bereits funktionierendes Element geschichtet wird. Referenz: die WCAG-2.2-Erfolgskriterien und der W3C ARIA Authoring Practices Guide.

Tastaturunterstützung ist kein Abhak-Punkt

Jedes interaktive Element muss allein mit der Tastatur bedienbar sein. Tab und Shift+Tab zum Navigieren; Enter oder Space zum Aktivieren; Esc zum Schließen einer transienten Oberfläche (Modal, Popover, Menü). Der Fokus muss sichtbar sein — niemals outline: none; ohne Ersatz. Der Fokus muss sich sinnvoll bewegen — wenn ein Modal geöffnet wird, wechselt der Fokus hinein; wenn das Modal geschlossen wird, kehrt der Fokus zu dem Element zurück, das es geöffnet hat. Testen Sie mit der Tastatur bevor Sie mit der Maus testen; die Maus verbirgt Fehler, die die Tastatur sofort offenbart.

Barrierefreie Namen und Beschreibungen

Nicht aria-label-Streuer. Der barrierefreie Name stammt standardmäßig aus dem Textinhalt des Elements; aria-labelledby referenziert den Text eines anderen Knotens; aria-label überschreibt alles mit einer fest kodierten Zeichenkette (und sollte das letzte Mittel sein, weil es Übersetzungen umgeht und dazu neigt, vom sichtbaren Label abzuweichen). Die barrierefreie Beschreibung ist davon getrennt — aria-describedby referenziert den Hilfetext- oder Fehlermeldungsknoten. Prüfen Sie im Accessibility-Tree der DevTools, was der Screenreader tatsächlich erhält — Annahmen und Realität weichen häufig voneinander ab.

Im echten CI testen, nicht nur lokal

Eine lokale axe-Prüfung ist ein Plausibilitätstest. Ein grünes CI ist ein Regressions-Gate. eslint-plugin-jsx-a11y in jeden PR einbinden; axe-core-Assertions zu Unit- und E2E-Tests hinzufügen; AT-Driver-Flows auf repräsentativen Seiten ausführen, damit ein echter Screenreader mitwirkt. Die Übersicht der Screenreader-Testtools zeigt, was sich zu automatisieren lohnt und was noch einer manuellen Prüfung bedarf.

Die Toolchain — 13 kuratierte Tools und Bibliotheken

Jeder Eintrag ist einer Lebenszyklusphase zugeordnet — Lint, Unit-Test, E2E, Laufzeit, Monitoring oder manuelle Prüfung — damit Sie das richtige Tool in das richtige Gate einbinden.

Framework-spezifische Leitfäden

Die Barrierefreiheitsprobleme, die je nach Ökosystem unterschiedlich auftreten — und die vertiefende Behandlung für jedes einzelne.

React

Keys in Listen (falsch gesetzte Keys verwirren Screenreader beim Neuordnen von Elementen). Fokus-Management bei Routenwechseln (ohne dieses bleibt der Fokus auf dem Link, der die Navigation ausgelöst hat, und die neue Seite ist für AT-Nutzer unsichtbar). Portals und Fokus-Traps — ein in document.body gerendertes Modal muss den Fokus trotzdem in sich halten. Hydration-Unstimmigkeiten, die die DOM-Struktur zwischen SSR und Client verändern, können ARIA-Beziehungen stillschweigend zerstören. Unser Tiefen-Artikel über ARIA-Live-Regions in modernen Frameworks behandelt das Live-Region-Ankündigungsmuster, das Reacts Reconciliation häufig bricht.

Vue / Svelte / Solid

Ähnliche Muster; reaktive Zustandsänderungen lösen standardmäßig keine Live-Region-Updates aus. Das Reaktivitätsmodell jedes Frameworks hat eine andere Definition von „der DOM hat sich geändert", und Screenreader sehen — oder sehen nicht — das resultierende Knoten-Update auf subtil unterschiedliche Weise. Vues v-if gegenüber v-show, Sveltes reaktive Deklarationen und Solids feingranulare Reaktivität erzeugen unterschiedliche Accessibility-Tree-Updates für scheinbar identischen Code.

Natives Mobile (iOS + Android)

Eine völlig andere API-Oberfläche. iOS stellt UIAccessibility (und SwiftUIs .accessibilityLabel() / .accessibilityHint()) für VoiceOver bereit; Android stellt AccessibilityNodeInfo für TalkBack bereit. Web-ARIA lässt sich nicht übertragen. Der Artikel über native mobile Barrierefreiheits-APIs ordnet Web-Konzepte ihren nativen Pendants zu, damit webgeschulte Entwicklerinnen und Entwickler aufhören müssen zu raten.

Komponentenbibliotheken

Headless-Bibliotheken (Radix UI, Headless UI, React Aria) übernehmen die schwierigen Teile — Fokus-Management, Tastaturbehandlung, ARIA-Verdrahtung — und überlassen das visuelle Design vollständig Ihnen. Vollwertige Bibliotheken (Material UI, Chakra, Ant) liefern eigenwillige Visualgestaltung, variieren aber stark in der Barrierefreiheitsqualität, und „standardmäßig barrierefrei" bedeutet selten „gegen echte Screenreader geprüft". Unser Survey zu barrierefreien Komponentenbibliotheken bewertet die wichtigsten Optionen anhand echter AT-Tests.

PR-Review-Checkliste für Barrierefreiheit

Ausdrucken, in die PR-Vorlage einfügen oder in einen Bot integrieren. Das Minimum, das jede Reviewerin und jeder Reviewer prüfen sollte.

  • Interaktive Elemente funktionieren allein mit der Tastatur (Tab + Enter + Space + Esc).
  • Fokusindikator auf jedem interaktiven Element sichtbar.
  • Formulareingaben haben ein zugehöriges <label>.
  • Fehlermeldungen sind mit ihren Eingaben verknüpft (aria-describedby oder benachbarter Text).
  • Dynamische Inhaltsänderungen werden bei Bedarf über aria-live angekündigt.
  • Modale Dialoge halten den Fokus fest und geben ihn beim Schließen an das öffnende Element zurück.
  • Bilder haben aussagekräftigen Alt-Text; dekorative Bilder tragen alt="".
  • Listen verwenden <ul> / <ol> / <dl> — kein <div>-Salat.
  • Überschriftenhierarchie ist schlüssig (keine übersprungenen Ebenen).
  • Lint + axe-Tests bestehen im CI vor dem Merge.

Häufige Engineering-Anti-Muster

Die Muster, die das Code-Review bestehen und dann in der Produktion versagen. Früher erkennen.

  • Das „Overlay-Widget" — JavaScript von Drittanbietern, das vorgibt, einem bestehenden Seitenauftritt Barrierefreiheit hinzuzufügen. Das funktioniert nicht, beschädigt häufig die Assistenztechnologie-Schicht und hat eine eigene Welle von Klagen ausgelöst. Hintergrund: Overlay-Anbieter.
  • role="button" auf einem <div> — fügt die Role-Ankündigung hinzu, ohne das Tastaturverhalten (Enter, Space) oder die Tab-Reihenfolge-Beteiligung. Verwenden Sie <button>.
  • aria-hidden="true" auf fokussierbaren Elementen — erzeugt eine Fokus-Falle, bei der Tastaturnutzer ein Element ansteuern können, das der Screenreader ignorieren soll. Entweder das Element mit tabindex="-1" aus der Tab-Reihenfolge entfernen oder aria-hidden weglassen.
  • Benutzerdefiniertes Dropdown ohne Tastaturbehandlung — ein <div>-basiertes Combobox, das sich per Klick öffnet, aber Pfeiltasten, Home/End, Type-ahead und Esc ignoriert. Der Survey zu barrierefreien Komponentenbibliotheken zeigt, welche Bibliotheken das direkt out of the box richtig lösen.
  • Toast-Benachrichtigungen, die nichts ankündigen — eine transiente Oberfläche ohne role="status" (polite) oder role="alert" (assertive). Sehende Nutzer sehen sie; Screenreader-Nutzer nicht.
  • Generierter DOM, der den Accessibility-Tree zerstört — schwere Wrapper um ein Input (ein benutzerdefiniertes Select aus zwölf verschachtelten <div>s) verstecken oft das eigentliche Steuerelement vor AT. Prüfen Sie, was AT sieht, nicht nur, was der Nutzer sieht.

Toolkit + Monitoring-Pipeline

Die meisten Teams brauchen drei Dinge der Reihe nach: einen einmaligen Triage-Scan, wenn etwas defekt wirkt, eine Engineering-Referenz, wenn sie die zugrundeliegenden Muster verstehen möchten, und eine kontinuierliche Monitoring-Schicht, sobald Barrierefreiheit in der Produktions-Roadmap verankert ist. Unser kostenloser WCAG-2.2-Scanner deckt den ersten Punkt ab — eine öffentliche URL einfügen, einen axe-getriebenen Bericht in einem neuen Tab erhalten. Die Engineering-Inhalte bei der Artikelredaktion decken den zweiten Punkt ab — einschließlich Analysen zu Barrierefreiheitsschulden als technischen Schulden und Barrierefreiheitsvorfällen als SRE-Postmortems für Teams, die Barrierefreiheit im großen Maßstab managen.

Für die kontinuierliche Schicht ist der Monitoring-Einkaufsführer der meinungsstärkste Artikel auf der Website. Er bewertet axe Monitor, Siteimprove, Level Access und Qualibooth — letzteres kombiniert Monitoring mit einer manuellen Audit-Übergabe, dem fehlenden Glied in den meisten rein automatisierten Stacks — nach Abdeckungsbreite, Falsch-Positiv-Rate und wie sauber die Daten in Engineering-Workflows integriert werden können. Der gesamte Sinn des Monitorings besteht darin sicherzustellen, dass die heute gelieferten Korrekturen im nächsten Sprint nicht wieder zurückfallen.

Häufig gestellte Engineering-Fragen

Die Fragen, die in jedem Barrierefreiheits-Kick-off auftauchen. Gespiegelt in den FAQPage-Strukturdaten.

Ist aria-label besser als sichtbare Textbeschriftungen?
Nein. Sichtbarer Text ist fast immer besser — er hilft sehenden Nutzern, sehenden Nutzern mit kognitiven Einschränkungen, Sprachsteuerungsnutzern (die sagen, was sie sehen) und Übersetzungstools. Greifen Sie auf aria-label nur zurück, wenn kein sichtbarer Text vorhanden ist (Schaltflächen mit nur einem Symbol) oder wenn der sichtbare Text tatsächlich nicht der gewünschte barrierefreie Name ist.
Sollte ich ARIA-Roles für alles verwenden?
Nein. Die erste Regel von ARIA lautet „ARIA nicht verwenden". Native HTML-Elemente bringen die richtige Rolle, das richtige Tastaturverhalten und die richtige Semantik im Accessibility-Tree von Haus aus mit. Verwenden Sie ARIA nur dann (und ausschließlich dann), wenn kein natives Element passt — beispielsweise eine Tab-Liste, ein Baum oder ein benutzerdefinierter Dialog, bei dem Sie kein <dialog> verwenden können.
Wie teste ich Barrierefreiheit im CI?
Drei Ebenen, geordnet nach Aufwand. (1) Lint: eslint-plugin-jsx-a11y bei jedem PR. (2) Unit-Tests: @testing-library/jest-dom plus jest-axe (oder @axe-core/react) für jede Komponente. (3) End-to-End: @axe-core/playwright auf repräsentativen User Journeys. Ein Pa11y- oder Lighthouse-CI-Gate auf Staging ergänzt die unteren Ebenen.
Sind axe-core und Lighthouse dasselbe?
Lighthouse verwendet axe-core intern für sein Barrierefreiheits-Audit, führt aber nur eine ausgewählte Teilmenge der Regeln aus und präsentiert sie innerhalb eines umfassenderen Performance-/SEO-/Best-Practices-Berichts. axe-core selbst ist die Engine — wenn Sie den vollständigen Regelsatz benötigen oder ihn erweitern möchten, verwenden Sie axe-core direkt. Für die meisten Teams: Lighthouse für Trendverfolgung, axe-core als eigentliches Gate.
Was ist das Mindest-Setup für Barrierefreiheitstests in einem React-Projekt?
eslint-plugin-jsx-a11y zur bestehenden ESLint-Konfiguration hinzufügen (wird standardmäßig mit create-react-app und Next.js mitgeliefert). @testing-library/jest-dom und jest-axe zum Unit-Test-Setup hinzufügen und expect(await axe(container)).toHaveNoViolations() in mindestens einem Test pro Komponente aufrufen. Das ist die Untergrenze — sie erkennt ca. 40 % der echten WCAG-Probleme mit nur wenigen Stunden Einrichtungsaufwand.
Muss ich mit echten Screenreadern testen?
Ja, für jedes Produktfeature, das Nutzerinnen und Nutzer von Assistenztechnologien tatsächlich verwenden. Automatisierte Tools erkennen strukturelle Fehler (fehlende Labels, Kontrast, Role-Unstimmigkeiten), aber nicht die erlebnisbezogenen Probleme (Fokus springt in die Fußzeile, Live-Regions kündigen nichts an, ein „barrierefreies" Modal hält den Fokus im falschen Teilbaum fest). Planen Sie mindestens eine manuelle Prüfung pro größerem Release mit NVDA unter Windows und VoiceOver unter macOS / iOS.

Nächste Schritte

Führen Sie eine schnelle Prüfung mit dem kostenlosen WCAG-2.2-Scanner durch, wenn Sie eine bestimmte Seite testen. Lesen Sie den Überblick der Screenreader-Testtools, bevor Sie AT-driver in CI integrieren. Und wenn Barrierefreiheit von „einmaligem Audit" zu „dauerhaftem Produktionsanliegen" wird, ist der Monitoring-Einkaufsführer der konkreteste Artikel auf der Website für die Anbieterauswahl.