Die teuerste Barrierefreiheit ist die, die man nachträglich einbaut. Wer ein digitales Produkt fertig entwickelt und erst dann prüft, ob Screenreader, Tastatur und Kontrast mitspielen, öffnet Baustellen in Code und Design, die andere längst als abgeschlossen betrachten. Accessibility by Design dreht diese Reihenfolge um: Zugänglichkeit wird schon in der Konzeption, in den Design-Tokens und in den ersten Komponenten verankert, nicht in einem Nachbesserungsprojekt kurz vor dem Launch. Dieser Beitrag zeigt, warum die frühe Integration günstiger ist, welche Rollen UX, Entwicklung und Redaktion übernehmen, wie eine Definition of Done Barrierefreiheit verbindlich macht und welche Fehler bei nachträglicher Sanierung regelmäßig wiederkehren. Denn seit dem Barrierefreiheitsstärkungsgesetz ist Konformität keine Kür mehr, und auf 94,8 Prozent (WebAIM Million, 2025) der weltweit meistbesuchten Startseiten fanden sich noch erkennbare WCAG-Verstöße.
Das Wichtigste in Kürze
- Barrieren sind verbreitet: 94,8 Prozent der meistbesuchten Startseiten zeigten erkennbare WCAG-Verstöße, im Schnitt 51 Fehler pro Seite (WebAIM Million, 2025); nur 20 von 65 getesteten Online-Shops waren per Tastatur bedienbar (Aktion Mensch, 2025).
- Wer erst nach dem Launch saniert, zahlt oft zweimal - für die nicht zugängliche Umsetzung und für den Umbau - und riskiert Regressionen im gewachsenen Code. Die W3C Web Accessibility Initiative hält es für am effizientesten und wirksamsten, Barrierefreiheit von Projektbeginn an einzubeziehen.
- Die Verantwortung verteilt sich: UX liefert Kontrast- und Fokus-Tokens, die Entwicklung semantisches HTML mit Tastaturbedienung und korrekten ARIA-Zuständen, die Redaktion Struktur und Alt-Texte, Product und QA die Abnahme gegen WCAG-Kriterien.
- Design-Tokens für Kontrast, Fokus, Typografie und Zielgrößen verankern Zugänglichkeit an der Quelle. Ein Kontrast-Token, das dauerhaft mindestens 4,5:1 für normalen Text hält, beugt Kontrastfehlern in jeder Komponente vor, statt sie einzeln zu jagen.
- In der Definition of Done zählt eine Aufgabe erst als fertig, wenn sie tastaturbedienbar ist, sichtbaren Fokus hat, Kontrastschwellen erfüllt und Formularfehler verständlich meldet. Automatische Tests fanden in einer Auswertung nur rund 57 Prozent der Befunde (Deque, 2021).
- Wiederkehrende Sanierungsfehler sind zugekaufte Overlay-Skripte, fehlende Semantik, nachgerüsteter Fokus und Content-Altlasten. Die Reihenfolge Anforderungen, Tokens, Komponenten, Definition of Done, Schulung und Monitoring beugt ihnen vor.
Warum Nachrüsten teuer wird
Der Zustand des Web spricht eine deutliche Sprache. Die jährliche WebAIM-Million-Analyse der eine Million meistbesuchten Startseiten fand 2025 auf 94,8 Prozent (WebAIM Million, 2025) der Seiten automatisch erkennbare WCAG-Verstöße, im Schnitt rund 51 Fehler pro Startseite (WebAIM Million, 2025). Der Wert verbessert sich nur langsam, 2024 lag er noch bei 95,9 Prozent (WebAIM Million, 2024). Und das sind ausschließlich maschinell messbare Mängel: Die schwerer zu findenden Barrieren in Tastaturbedienung, Fokusführung und verständlichen Fehlermeldungen kommen obendrauf.
In Deutschland zeigt sich dasselbe Bild dort, wo Umsatz direkt am Spiel steht. Ein Test von Aktion Mensch und Google prüfte 2025 insgesamt 65 Online-Shops; nach dem Testbericht war nur etwa ein Drittel (Aktion Mensch, 2025) der untersuchten Shops barrierefrei. Besonders deutlich fiel die Tastaturbedienung aus: Lediglich 20 von 65 (Aktion Mensch, 2025) getesteten Seiten ließen sich allein mit der Tastatur ohne Maus bedienen. Der Testbericht nennt die Tastaturbedienbarkeit die Basis für digitale Barrierefreiheit (Aktion Mensch, 2025).
Warum Nachrüsten teuer wird, zeigt der Weg eines Fehlers durch das Projekt: Eine Barriere, die im Konzept übersehen wird, wandert durch Design, Entwicklung und Redaktion, bis sie am Ende in Dutzenden Templates, Komponenten und Inhalten gleichzeitig steckt. Sie einmal an der Quelle richtig zu bauen erspart die spätere Korrektur an vielen Stellen. Genau hier setzt der Shift-Left-Gedanke an: Prüfung und Qualitätssicherung wandern nach vorne, an den Anfang des Prozesses, statt am Ende als Feuerwehr zu arbeiten.
Nachrüsten heißt oft doppelt zahlen
Was Accessibility by Design bedeutet
Die Web Accessibility Initiative des W3C fasst das Prinzip in einem Satz zusammen: Am effizientesten und wirksamsten sei es, Barrierefreiheit von Beginn eines Projekts an einzubeziehen, damit Arbeit nicht noch einmal gemacht werden muss (W3C Web Accessibility Initiative). Accessibility by Design macht aus diesem Grundsatz eine Arbeitsweise: Zugänglichkeit ist kein Prüfschritt am Ende, sondern ein roter Faden, der durch jede Phase läuft.
Praktisch heißt das, dass jede Disziplin ihren Teil an derselben Anforderung trägt. Die Konzeption definiert Zielgruppen und Nutzungsszenarien inklusive assistiver Technik. Das Design legt Kontraste, Fokuszustände und Abstände als wiederverwendbare Tokens fest. Die Entwicklung baut auf semantischem HTML und prüfbaren Komponenten auf. Die Redaktion liefert strukturierte, verständliche Inhalte. Und der Betrieb hält den erreichten Stand über Monitoring und feste Routinen. Die folgenden sechs Bausteine bilden dieses durchgängige Fundament.
Konzeption
Zielgruppen, Nutzungsszenarien und Anforderungen werden von Beginn an mit assistiver Technik gedacht. WCAG 2.2 AA wird als messbares Projektziel festgeschrieben, nicht als vage Absichtserklärung.
Design-Tokens
Kontrast, Fokus, Typografie und Abstände liegen als zentrale Design-Tokens im System. So entsteht Zugänglichkeit einmal an der Quelle und wird in jeder Komponente automatisch mitgeliefert.
Semantische Komponenten
Buttons, Formulare, Menüs und Dialoge werden mit korrektem HTML, sinnvoller Fokusreihenfolge und ARIA nur dort gebaut, wo es nötig ist. Barrierefreiheit steckt in der Komponente, nicht im Nachtrag.
Redaktion und Content
Überschriftenhierarchie, Alt-Texte, Linktexte und verständliche Sprache entstehen im Redaktionsprozess. Wer Inhalte einpflegt, kennt die Kriterien und die passenden Werkzeuge.
Definition of Done
Barrierefreiheit ist Teil der Abnahmekriterien jedes Tickets. Eine Aufgabe gilt erst als fertig, wenn sie tastaturbedienbar, kontraststark und semantisch korrekt ist.
Betrieb und Monitoring
Nach dem Launch sichern automatisierte Checks, Stichproben und eine feste Redaktionsroutine den Stand. Jede neue Funktion durchläuft dieselben Kriterien wie die erste.
Klare Rollen: UX, Entwicklung, Redaktion
Barrierefreiheit scheitert selten an Unwissen und oft an unklarer Zuständigkeit. Wenn niemand sich verantwortlich fühlt, fällt das Thema zwischen die Disziplinen. Accessibility by Design verteilt die Verantwortung deshalb ausdrücklich statt sie einer einzelnen Person aufzubürden. Die folgende Übersicht zeigt, wer welchen Beitrag leistet und was passiert, wenn die Rolle unbesetzt bleibt.
| Rolle | Beitrag im Prozess | Fehlt die Rolle, entsteht |
|---|---|---|
| UX und Design | Kontrast- und Fokus-Tokens, bedienbare Zustände, klare Beschriftungen und logische Reihenfolge | zu geringe Kontraste und unsichtbare Fokus, die später aufwendig nachjustiert werden |
| Entwicklung | Semantisches HTML, Tastaturbedienbarkeit, korrekte ARIA-Zustände, testbare Komponenten | Div-Suppe ohne Semantik, die Screenreader und Tastatur ausschließt |
| Redaktion | Überschriftenstruktur, Alt-Texte, verständliche Link- und Fehlertexte | inhaltliche Barrieren, die auch technisch saubere Seiten unbenutzbar machen |
| Product und QA | Definition of Done, Priorisierung, Abnahme gegen WCAG-Kriterien | Barrierefreiheit ohne Abnahmekriterium, die im Termindruck stillschweigend entfällt |
Diese Rollenteilung hat einen konkreten Adressaten. Zum Jahresende 2023 lebten in Deutschland rund 7,9 Millionen (Statistisches Bundesamt, 2024) schwerbehinderte Menschen, das entspricht 9,3 Prozent (Statistisches Bundesamt, 2024) der Bevölkerung. Menschen mit Beeinträchtigung nutzen Online-Shops zudem im Schnitt häufiger als Menschen ohne Beeinträchtigung (Aktion Mensch, 2025). Wer die Redaktion mitnimmt, sorgt dafür, dass gute Technik nicht an schwer verständlichen Inhalten scheitert; wie das gelingt, beschreibt der Beitrag zur Schulung der Redaktion für barrierefreie Inhalte. Dasselbe Prinzip gilt über die Website hinaus, etwa für barrierefreie Newsletter und E-Mail-Marketing.
Design-Tokens: Barrierefreiheit ins System schreiben
Ein besonders wirksamer Hebel für frühe Barrierefreiheit liegt im Design-System. Wenn Kontraste, Fokuszustände und Abstände als zentrale Tokens definiert sind, muss niemand sie in jeder Komponente neu erfinden oder gar vergessen. Ein Kontrast-Token, das dauerhaft das WCAG-Verhältnis von mindestens 4,5:1 für normalen Text einhält, macht Kontrastfehler an der Wurzel unwahrscheinlich, statt sie später einzeln zu jagen. Wie man Kontraste richtig setzt und prüft, vertieft der Beitrag zu Farbkontrasten in der Barrierefreiheit.
- Kontrast-Tokens: Text-, Rahmen- und Statusfarben erfüllen die WCAG-Schwellen und werden zentral gepflegt statt pro Seite.
- Fokus-Tokens: Ein sichtbarer, konsistenter Fokusrahmen gilt für alle interaktiven Elemente, damit Tastaturnutzung jederzeit nachvollziehbar bleibt.
- Typografie-Tokens: Schriftgröße, Zeilenhöhe und Zeilenlänge sind auf Lesbarkeit und Skalierbarkeit ausgelegt, wie im Beitrag zur barrierefreien Typografie beschrieben.
- Abstands- und Zielgrößen-Tokens: Touch-Ziele und Klickflächen sind groß genug und ausreichend getrennt, damit motorisch eingeschränkte Nutzer sicher treffen.
Ein Token spart viele Einzelkorrekturen
Definition of Done: barrierefrei heißt fertig
Damit Barrierefreiheit nicht im Termindruck untergeht, braucht sie ein verbindliches Abnahmekriterium. Die Definition of Done legt fest, wann eine Aufgabe wirklich abgeschlossen ist. Wird Zugänglichkeit dort verankert, ist eine Funktion erst dann fertig, wenn sie auch mit Tastatur und Screenreader funktioniert, nicht schon, wenn sie mit der Maus sichtbar arbeitet. Das verschiebt die Prüfung vom teuren Ende an die Stelle, an der die Arbeit ohnehin stattfindet.
Wichtig ist dabei, sich nicht allein auf Werkzeuge zu verlassen. Automatische Prüftools fanden in einer Auswertung nur rund 57 Prozent (Deque, 2021) der Befunde. Kriterien wie sinnvolle Fokusreihenfolge, verständliche Fehlermeldungen oder korrekte Bedienbarkeit lassen sich nur manuell beurteilen. Eine praktikable Definition of Done kombiniert deshalb einen automatischen Check mit einem kurzen manuellen Tastatur- und Screenreader-Test.
- Die Funktion ist vollständig mit der Tastatur bedienbar, die Fokusreihenfolge ist logisch.
- Der Fokus ist jederzeit sichtbar, kein Element wird ohne Rückmeldung fokussiert.
- Texte und Bedienelemente erfüllen die WCAG-Kontrastschwellen aus dem Token-System.
- Überschriften, Beschriftungen und Alt-Texte sind vorhanden und semantisch korrekt.
- Formularfehler werden verständlich gemeldet und programmatisch angekündigt, wie im Beitrag zu barrierefreien Formularen und Validierung beschrieben.
- Ein automatischer Check plus ein kurzer manueller Tastatur- und Screenreader-Test wurden durchgeführt.
Der eine Satz, der den Unterschied macht
Typische Fehler bei nachträglicher Sanierung
Wer erst spät saniert, trifft immer wieder auf dieselben Muster. Sie zu kennen hilft, sie von Anfang an zu vermeiden. Die folgenden sechs Fehlerquellen tauchen in Sanierungsprojekten regelmäßig auf und lassen sich in der Konzeption in der Regel mit weniger Aufwand vermeiden, als sie später zu beheben sind.
Die Overlay-Illusion
Ein zugekauftes Overlay-Skript verspricht schnelle Abhilfe, behebt die zugrunde liegenden Barrieren aber nicht. Warum das keine BFSG-Lösung ist, zeigt der Beitrag zu Accessibility-Overlays.
Fehlende Semantik
Wurde alles aus generischen Containern gebaut, fehlt die Struktur, auf die Screenreader angewiesen sind. Semantik nachzurüsten bedeutet oft, Komponenten neu zu schreiben.
Fokus als Nachtrag
Ohne Fokus-Token muss jede Interaktion einzeln nachgebessert werden. Die Tastaturnavigation wird so zum Flickenteppich statt zu einem durchgängigen Verhalten.
Farbsystem ohne Kontrast
Eine gewachsene Farbpalette ohne Kontrastregeln erzwingt spätere Kompromisse zwischen Marke und Lesbarkeit, die im Token-System von Anfang an vermeidbar gewesen wären.
Content-Altlasten
Fehlende Alt-Texte, wirre Überschriften und nicht barrierefreie PDF-Dokumente summieren sich über Jahre. Ihre nachträgliche Aufarbeitung bindet erhebliche Redaktionszeit.
Niemand ist zuständig
Ohne klare Rollen und Definition of Done bleibt Barrierefreiheit ein Sonderprojekt, das nach dem nächsten Relaunch von vorn beginnt, statt Teil des Alltags zu sein.
Vom Konzept in den Betrieb: die Roadmap
Der Umstieg auf Accessibility by Design gelingt schrittweise und muss kein Großprojekt sein. Wer die folgende Reihenfolge einhält, verankert Zugänglichkeit dort, wo sie entsteht, und macht sie zur Gewohnheit statt zur Ausnahme. Eine barrierefreie Webentwicklung von Grund auf folgt genau diesem Weg.
- Anforderungen festschreiben: WCAG 2.2 AA und die relevanten BFSG-Anforderungen als messbares Ziel in Konzept und Backlog aufnehmen.
- Design-Tokens definieren: Kontrast, Fokus, Typografie und Zielgrößen zentral im Design-System festlegen, bevor Komponenten gebaut werden.
- Komponenten barrierefrei bauen: Semantik, Tastaturbedienung und geprüfte Zustände in die Bausteine legen, aus denen alle Seiten entstehen.
- Definition of Done erweitern: Barrierefreiheit als Abnahmekriterium in jedes Ticket aufnehmen, inklusive kurzem manuellem Test.
- Redaktion befähigen: Das Team über Barrierefreiheit-Schulungen mit Kriterien und Werkzeugen ausstatten, damit Inhalte zugänglich entstehen.
- Betrieb absichern: Nach dem Launch mit einem WCAG-Audit den Stand belegen und über Monitoring dauerhaft halten.
Wie groß der Bedarf an Orientierung ist, zeigt die Bundesfachstelle Barrierefreiheit: Die Zahl ihrer Erstberatungen stieg 2023 um 9 Prozent, die Websitebesuche nahmen um 29 Prozent zu, und digitale Barrierefreiheit war das häufigste Thema der Erstberatungsanfragen (Bundesfachstelle Barrierefreiheit, 2023). Barrierefreiheit zahlt zudem auf Ziele ein, die über Compliance hinausgehen: Nach der W3C Web Accessibility Initiative verbessert barrierefreie Gestaltung häufig das Nutzungserlebnis insgesamt und die Kundenbindung, außerdem mindert sie rechtliche Risiken (W3C Web Accessibility Initiative).
Barrierefreiheit von Anfang an ist keine zusätzliche Aufgabe, sondern eine bessere Reihenfolge. Man baut dieselbe Sache einmal richtig, statt sie zweimal zu bezahlen.
Wer Zugänglichkeit über den gesamten Prozess verteilt, verwandelt BFSG-Konformität von einem Nachbesserungsprojekt in eine Eigenschaft des eigenen Systems. Welche Schritte für Ihr Vorhaben sinnvoll sind und wo Ihr Team ansetzen sollte, klären wir gern unverbindlich über die Kontaktseite oder im Rahmen unserer Leistungen zur digitalen Barrierefreiheit.
Quellen und Studien
Verwandte Artikel
Barrierefreie KI-Chatbots: WCAG-konforme Voice-Bots
Wann KI-Chatbots und Voice-Assistenten unter das BFSG fallen und wie Conversational UI mit ARIA-Live-Regions, Fokus-Management und Textpfad WCAG-konform wird.
Was das BFSG nicht verlangt: Ausnahmen für Inhalte
§ 1 Absatz 4 BFSG nimmt fünf Inhaltsarten aus. So trennen Sie einen gewachsenen Dokumentenbestand - und so endet die Ausnahme still.
Barrierefreiheit halten: Prüfrhythmus nach dem Go-live
Die Pflicht endet nicht mit der Abnahme. Welche Ereignisse eine Nachprüfung auslösen, welche Stichprobe trägt und wie lange Nachweise bleiben.