Barrierefreiheit ist kein Nischenthema mehr. Laut dem WebAIM Million Report 2026 hatten 95,9 % der eine Million meistbesuchten Startseiten erkannte WCAG-Fehler – im Schnitt 56,1 pro Seite, ein Anstieg von gut 10 % gegenüber dem Vorjahr. Gleichzeitig ist die rechtliche Lage in der EU konkret geworden: Seit dem 28. Juni 2025 gilt in Deutschland das Barrierefreiheitsstärkungsgesetz (BFSG), das den European Accessibility Act umsetzt.
Die schwierigere Frage ist deshalb nicht mehr „ob", sondern „was konkret". Dieser Artikel ergänzt unsere BFSG-Checkliste: Dort geht es um Einordnung, Audit und erste Prüfpunkte. Hier geht es um die Arbeit am Produkt – welche Anforderungen in Komponenten, Formularen, Texten, Designsystemen und Release-Prozessen landen sollten.
Wichtig: Dieser Beitrag ist keine Rechtsberatung. Ob und in welchem Umfang ein Angebot rechtlich verpflichtet ist, hängt vom Einzelfall ab. Für die juristische Bewertung – insbesondere zum BFSG – sollten Unternehmen qualifizierten Rat einholen.
WCAG 2.2 ist der technische Arbeitsstandard
Die Web Content Accessibility Guidelines 2.2 sind 2026 der maßgebliche technische Referenzrahmen – nicht WCAG 3.0. WCAG 2.2 ist seit dem 5. Oktober 2023 W3C-Empfehlung und ergänzt gegenüber 2.1 neun zusätzliche Erfolgskriterien, etwa zu Fokus-Sichtbarkeit und Zielgrößen. WCAG 3.0 existiert dagegen nur als Arbeitsentwurf (zuletzt aktualisiert im März 2026) und wird voraussichtlich erst gegen Ende des Jahrzehnts zur Empfehlung – Teams sollten ihre Arbeit also weiter an 2.2 ausrichten.
Auch regulatorisch ist WCAG der Anker: Die europäische Norm EN 301 549, an der sich BFSG und EAA orientieren, referenziert in ihrer aktuellen harmonisierten Fassung WCAG 2.1 Level A und AA; eine Aktualisierung auf 2.2 ist in Vorbereitung. Praktisch heißt das: WCAG ist kein Audit-Dokument für den Schluss, sondern ein Produktstandard. Jede neue Komponente und jeder wichtige Flow sollte gegen die vier Prinzipien geprüft werden.
| WCAG-Prinzip | Bedeutung | Typische Prüfung |
|---|---|---|
| Wahrnehmbar | Inhalte ohne perfekte Sicht, Farbe oder Audio verständlich | Kontrast, Alt-Texte, Untertitel |
| Bedienbar | Funktionen per Tastatur, Touch, Maus, Hilfstechnik nutzbar | Tastaturpfad, Fokus, Zielgrößen |
| Verständlich | Sprache, Navigation, Fehlermeldungen nachvollziehbar | Labels, Fehlertexte, klare Sprache |
| Robust | Markup und Zustände funktionieren mit Screenreadern | Semantik, ARIA-Zustände, Tests |
Die meisten Barrieren entstehen an fünf Stellen
Barrierefreiheit scheitert selten an exotischen Sonderfällen, sondern an einer Handvoll wiederkehrender Fehler. Die WebAIM-Million-Analyse zeigt das Jahr für Jahr: Sechs Fehlerkategorien machen rund 96 % aller erkannten Probleme aus. Wer sie systematisch abräumt, schließt den Großteil der messbaren Barrieren – und genau diese Fehler sind im Code reproduzierbar lösbar.
Die gute Nachricht: Diese Fehler haben klare Verantwortliche und klare Lösungen. Es geht nicht um ein Spezialprojekt, sondern um Disziplin in Design, Code und Content.
| Häufiger Fehler | Anteil der Seiten | Lösung | Verantwortlich |
|---|---|---|---|
| Geringer Textkontrast | 83,9 % | Kontrast-Tokens, dokumentierte Farbkombinationen | Design |
| Fehlende Alt-Texte | 53,1 % | Pflichtfeld für relevante Bilder, leere Alt für Deko | Content |
| Fehlende Formularlabels | 51 % | Sichtbare, programmatisch verknüpfte Labels | Entwicklung |
| Leere Links | 46,3 % | Sprechende Linktexte statt reiner Icons | Content/Entwicklung |
| Leere Buttons | 30,6 % | Zugänglicher Name für jeden Button | Entwicklung |
Tastatur, Fokus und Formulare zuerst
Tastaturbedienung ist der schnellste Weg, echte Probleme sichtbar zu machen. Wenn ein Dialog, Menü, Filter, Slider oder Checkout-Schritt nicht ohne Maus funktioniert, ist die Oberfläche für viele Nutzer blockiert. Verbindlich sollte daher gelten: Alle interaktiven Elemente sind per Tastatur erreichbar, die Fokusreihenfolge folgt der logischen Struktur, der Fokus ist jederzeit klar sichtbar, modale Dialoge halten den Fokus und geben ihn beim Schließen zurück – und es gibt keine Tastaturfallen.
Fokus ist dabei Navigation: Wer ihn entfernt, entfernt Orientierung. Der Klassiker outline: none ohne gleichwertigen Ersatz gehört verboten. Gute Fokuszustände sind deutlich sichtbar auf hellen wie dunklen Flächen, nicht nur über Farbe erkennbar, konsistent über Buttons, Links, Inputs und komplexe Widgets – und nicht durch overflow: hidden abgeschnitten.
Formulare verdienen besondere Sorgfalt, weil sie über Umsatz, Leads, Buchungen und Bewerbungen entscheiden. Jedes Eingabefeld braucht ein sichtbares, programmatisch verknüpftes Label; Pflichtfelder sind eindeutig erkennbar; Fehlermeldungen nennen Problem und Lösung und werden nicht nur farblich markiert; Erfolgs- und Statusänderungen werden für Screenreader angekündigt. Mehrstufige Formulare, Checkout, Login und Datei-Uploads sollten immer manuell mit Tastatur und Screenreader getestet werden.
Kontrast und verständliche Inhalte
Kontrast betrifft mehr als Fließtext. Auch Icons, Platzhalter, Labels, Fehlermeldungen, Status-Badges, Fokusrahmen, Disabled- und Hover-Zustände müssen geprüft werden. Gute visuelle Barrierefreiheit beginnt im Design: Text bleibt lesbar beim Zoomen, Farbe ist nie das einzige Signal für Status oder Fehler, interaktive Ziele sind groß genug, und Animationen respektieren reduzierte Bewegungseinstellungen. Wenn ein Designsystem Farb-Tokens nutzt, müssen die erlaubten Kombinationen dokumentiert sein – ein Button-Token allein reicht nicht.
Barrierefreiheit ist außerdem nicht nur Code. Unklare Texte schließen genauso aus wie fehlende Labels. Überschriften beschreiben den folgenden Abschnitt, Linktexte sind auch ohne umliegenden Satz verständlich, Buttons benennen die Aktion konkret, und Alternativtexte beschreiben relevante Bildinhalte statt dekorativer Stimmung. SEO und Accessibility ziehen hier in dieselbe Richtung – klare Struktur hilft Nutzern, Screenreadern und Suchmaschinen gleichermaßen, wie wir in Qualität ist messbar zeigen.
Accessibility gehört ins Designsystem und in die CI
Wenn Barrierefreiheit pro Seite neu gelöst wird, bleibt sie teuer und fehleranfällig. Für Unternehmen mit mehreren Websites, Apps oder Portalen gehört sie ins Designsystem. Dort sollten für zentrale Komponenten Tastaturverhalten, Fokuszustände, erlaubte Kontrastkombinationen, Screenreader-Namen, Fehlermuster und Responsive-Verhalten dokumentiert sein. Entscheidend ist die technische Umsetzung: Buttons, Inputs, Dialoge, Tabs, Tabellen und Navigation müssen als geprüfte Komponenten bereitstehen und tatsächlich verwendet werden.
Beim Testen gilt: automatisiert prüfen, manuell entscheiden. Tools wie axe, Lighthouse oder Playwright-basierte Checks finden fehlende Labels, viele Kontrastfehler und ungültige ARIA-Attribute schnell und gehören in die CI – decken aber erfahrungsgemäß nur einen Teil der relevanten Kriterien ab. Ergänzt um manuelle Tastaturtests, Screenreader-Tests mit realistischen Aufgaben und Regressionstests nach Änderungen an Designsystem, Navigation und Formularen entsteht ein belastbarer Mix. Bei ARIA gilt die robuste Grundregel: erst semantisches HTML, dann ARIA nur dort, wo es wirklich gebraucht wird – ein echter button bringt Rolle und Tastaturverhalten bereits mit.
Reihenfolge: was zuerst, was später
Barrierefreiheit scheitert selten an einem fehlenden Attribut, sondern daran, dass niemand zuständig ist. Deshalb braucht es klare Verantwortlichkeiten – Produktmanagement priorisiert, Design definiert Zustände, Entwicklung setzt Semantik und Tests um, Content pflegt Sprache und Struktur, QA prüft Tastatur und Screenreader – und eine pragmatische Reihenfolge statt eines unübersichtlichen Komplettprojekts.
Konkret bedeutet das: kritische Nutzerflows (Kauf, Login, Kontakt, Buchung, Suche) identifizieren und mit Tastatur und Screenreader testen; Formularlabels, Fehlermeldungen, Fokus und Kontrast korrigieren; wiederkehrende Komponenten einmal im Designsystem reparieren; Content-Struktur, Linktexte und Alternativtexte verbessern; automatisierte Checks in Entwicklung und CI ergänzen und Accessibility als Akzeptanzkriterium für neue Features aufnehmen. Das Ziel ist kein einmaliges Häkchen, sondern ein Produktprozess, in dem neue Barrieren gar nicht erst entstehen.
Rechtlich bleibt die Linie dieselbe: sorgfältig, aber nicht panisch. Nicht jedes Angebot ist gleich betroffen, und die genaue Pflicht hängt vom Einzelfall ab. Technisch ist die Richtung jedoch eindeutig – wer heute nach WCAG 2.2, mit sauberem Designsystem und belastbaren Tests baut, reduziert Risiken und verbessert die Produktqualität.
Nächste Schritte
Drei Fragen sortieren die Prioritäten schneller als jedes Tool-Ergebnis:
- Flows: Welche drei Nutzerflows sind geschäftskritisch – und funktionieren sie mit Tastatur und Screenreader?
- Komponenten: Gibt es ein Designsystem, in dem Fokus, Kontrast und Tastaturverhalten dokumentiert und geprüft sind?
- Prozess: Ist Accessibility ein Akzeptanzkriterium für neue Features – oder ein nachgelagertes Audit?
Wenn Sie hier Lücken sehen, helfen wir pragmatisch und priorisiert. Sehen Sie sich unsere Leistung Barrierefreiheit an oder buchen Sie direkt ein Erstgespräch.
