Barrierefreiheit und UX: Wie A11y die Nutzererfahrung für alle verbessert

Barrierefreiheit verbessert die UX nicht nur für Menschen mit Behinderung. Sichtbare Fokuszustände helfen jeder Person, die zwischen Maus und Tastatur wechselt. Aussagekräftige Linktexte helfen allen, die Seiten überfliegen. Großzügige Touch-Ziele helfen Menschen mit eingeschränkter Motorik genauso wie jeder Person, die einhändig auf einem ruckelnden Bahnsteig bestellt. Schnelle Performance hilft assistiver Software genauso wie älterer Hardware und schlechtem Mobilfunk. Dieser Mehrwert für die Mehrheit ist der Grund, warum sich barrierefreies Engineering wirtschaftlich rechnet und nicht nur ethisch.

Die Web Content Accessibility Guidelines des W3C beruhen auf vier Prinzipien: Wahrnehmbar, bedienbar, verständlich, robust (WCAG 2.2, W3C). In der UX-Sprache klingt das nach Bedienbarkeitsanforderung, in der Engineering-Sprache nach sauberem Code. Beides ist dasselbe.

Wahrnehmbar verlangt, dass keine Information ausschließlich über einen einzelnen Sinneskanal vermittelt wird: Bildinformationen brauchen Alternativtexte, Audio- und Videoinhalte Transkripte oder Untertitel, farbliche Hinweise zusätzliche textliche Markierung. Bedienbar fordert, dass jede Funktion über Tastatur, Sprache oder Schalter erreichbar ist. Verständlich verlangt vorhersehbares Verhalten und klar formulierte Fehlermeldungen über aria-live-Regionen. Robust adressiert die saubere technische Codierung, sodass assistive Technologien zuverlässig interpretieren können.

Wer Designreviews entlang dieser vier Prinzipien führt, baut UX-Standard und Accessibility-Anforderung in einem Schritt. Die Trennung zwischen „UX-Bug“ und „A11y-Bug“ verschwindet in der Praxis fast vollständig.

• Semantisches HTML vor ARIA. Native HTML-Elemente bringen Fokussierbarkeit, Tastaturverhalten und Screenreader-Unterstützung automatisch mit. Ein Button-Element ist kein div-Element mit Click-Handler. Die erste Regel von WAI-ARIA lautet: No ARIA is better than bad ARIA.
• ARIA-Patterns korrekt anwenden. Wo native Elemente nicht reichen, etwa bei Tabs, Comboboxen oder Treeviews, helfen die ARIA Authoring Practices als Referenzimplementierung (WAI-ARIA Authoring Practices). Sie geben für komplexe Widgets das geprüfte Zusammenspiel aus Rollen, States, Properties und Tastaturverhalten vor.
• Fokus-Management in Single Page Applications. In SPAs kümmert sich der Browser nicht automatisch um den Fokus. Routenwechsel ohne Fokusverlagerung sind in vielen React-, Angular- und Vue-Anwendungen ein häufiger Befund. Korrekt umgesetzt heißt: Nach einem Routenwechsel wandert der Fokus programmatisch auf das h1-Element oder das main-Element, und die Routenänderung wird über aria-live angekündigt.
• Formularzustände für Screenreader. Validierungsfehler, die nur rot blinken, sind für Screenreader unsichtbar. Korrekt ist die Kombination aus sichtbarem Text, programmatisch verknüpftem Label, aria-invalid und einer aria-live-Region. Die Abbruchquote in Formularen sinkt messbar, nicht nur für Menschen mit Behinderung.
• Bewegung als Wahl, nicht als Default. Übermäßige Animationen und Parallax-Effekte können bei Menschen mit vestibulären Erkrankungen Beschwerden auslösen. Die Media-Query prefers-reduced-motion: reduce ist eine Browser-Standardfunktion. Ein Designsystem, das sie nicht respektiert, verfehlt WCAG 2.3.3 und eine elementare UX-Erwartung.
• Sprache und lang-Attribut. Screenreader wählen Aussprache und Stimme auf Basis des lang-Attributs. Ein falsch gesetztes Sprachattribut führt zu maschinell verzerrter Vorlesung. Internationalisierte Anwendungen sollten zusätzlich Inline-Sprachwechsel über lang auf Elementebene auszeichnen.
• Performance als Accessibility-Faktor. Eine schnelle Seite ist eine zugängliche Seite. Ältere Geräte, assistive Software im Hintergrund und langsame Netze sind die Realität vieler Nutzungsgruppen. Largest Contentful Paint, Interaction to Next Paint und Cumulative Layout Shift sind damit auch A11y-Hebel, nicht nur Performance-Themen.

Die meisten WCAG-Verstöße sind keine Einzelfälle, sondern strukturelle Defekte in wiederverwendeten Komponenten. Das zeigt der aktuelle WebAIM Million Report 2025 deutlich: 94,8 Prozent der eine Million meistbesuchten Startseiten weltweit weisen mindestens einen automatisch erkennbaren WCAG-Verstoß auf, im Schnitt 51 Fehler pro Seite (WebAIM Million Report 2025). Wer Buttons, Inputs, Dropdowns, Modals und Datatables einmal sauber baut, multipliziert Accessibility über das gesamte Produkt.
Eine accessible Komponentenbibliothek liefert garantiert Tastaturbedienbarkeit per Default, sichtbare Fokuszustände, programmatisch korrekte Labels und Beschreibungen, ARIA-Rollen und States nach APG, kontrastsichere Tokens, Focus-Trap in Dialogen, Live-Region-Patterns für asynchrone Statuswechsel. Solche Bibliotheken können selbst gebaut oder auf Basis erprobter Headless-Patterns wie React Aria, Radix UI oder Adobe Spectrum aufgesetzt werden. Entscheidend ist nicht die Wahl der Library, sondern die Konsequenz, mit der die Komponenten verbindlich für das Produkt gesetzt werden.

Ohne automatisierte Prüfung schleichen sich Regressionsfehler ein, die in keinem Release-Audit auffallen. Drei Bausteine haben sich bewährt. Erstens, eingebettete Prüfungen mit der Open-Source-Engine axe-core von Deque in Unit- und Integration-Tests; Verstöße brechen den Build. Zweitens, Lighthouse oder Pa11y in der Pipeline mit konfigurierten Mindest-Scores auf den wichtigsten Seitentypen. Drittens, Visual-Regression-Tests mit Fokus-State-Snapshots, um unterdrückte Fokus-Stile vor Produktion zu entdecken.
Automatisierte Tests erfassen einen Teil der WCAG-Anforderungen, vor allem strukturelle Codeprobleme. Inhaltliche Fragen wie die Qualität eines Alternativtexts oder die Sinnhaftigkeit einer Tab-Reihenfolge bleiben Aufgabe manueller Tests. Beides zusammen ist der Standard moderner Engineering-Teams.

Custom-Komponenten ohne Tastaturverhalten, häufig als Showcase moderner Framework-Features gebaut, sind ein Klassiker. Aggressive Lazy-Loading-Strategien können Screenreader-Nutzung erschweren, wenn Inhalte erst bei Sichtbarkeit nachgeladen werden. JavaScript-Magie zur „Verbesserung“ nativer Browserfunktionen produziert in Audits oft die meisten Findings. Faustregel: Wenn eine native Lösung existiert, ist sie meistens die zugänglichere.

Wir bei BAYOOTEC entwickeln seit über 20 Jahren digitale Produkte für den Mittelstand, für internationale Konzerne und für Behörden, häufig in regulierten Branchen wie Medizintechnik, Energie oder Finanzdienstleistungen. Accessibility ist in diesem Umfeld kein optionales Feature, sondern Teil derselben Qualitätslogik wie Security, Datenschutz und Wartbarkeit. Im Engineering-Strang heißt das: Accessibility ist Teil der Definition of Done, Komponentenbibliotheken werden mit accessibility-geprüften Patterns aufgesetzt, automatisierte A11y-Checks laufen in der CI/CD-Pipeline neben Linting und Tests. Wo es projektrelevant ist, ergänzen unsere Kolleginnen und Kollegen vom Schwesterunternehmen UID die UX-Strategie- und Nutzungsforschungsseite.

Gute UX entsteht aus dem Zusammenspiel von Konzeption, Inhalt, Design und Engineering. Die Frage, ob Accessibility zur spürbaren Eigenschaft eines Produkts wird oder zur späten Korrekturaufgabe, entscheidet sich aber am Code: Im Markup, in den Komponenten, im Routing, in der Performance, in der Pipeline. An jeder Stelle dieser Kette wird festgelegt, was eine Nutzerin oder ein Nutzer im Alltag tatsächlich erlebt. Wer A11y im Engineering-Standard verankert, baut Produkte für eine breite Nutzungsvielfalt, nicht nur für den „durchschnittlichen“ Anwendungsfall.