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 immer wiederkehren. Denn seit dem Barrierefreiheitsstärkungsgesetz ist Konformität keine Kür mehr, und 94,8 Prozent (WebAIM Million, 2025) der weltweit meistbesuchten Startseiten zeigen, dass die Nachrüst-Strategie bislang selten aufgeht.
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. 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; nur etwa ein Drittel (Aktion Mensch, 2025) erfüllte grundlegende Anforderungen, zwei von drei Shops waren nicht 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. Die Bundesfachstelle für Barrierefreiheit ordnet den Befund ein, dass nur knapp ein Drittel der Seiten das zentrale Kriterium der Tastaturbedienbarkeit erfüllt (Bundesfachstelle für Barrierefreiheit, 2025).
Diese Zahlen erklären, warum Nachrüsten so teuer ist. 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 kostet einen Bruchteil dessen, was ihre Korrektur an vielen Stellen später verschlingt (Projekterfahrung). 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: Barrierefreiheit von Beginn eines Projekts an einzuplanen sei fast immer deutlich einfacher, kostengünstiger und wirksamer, als eine bestehende Seite später in einem separaten Projekt nachzubessern (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. Diese Gruppe ist digital überdurchschnittlich aktiv: Menschen mit Behinderung nutzen Online-Shops im Schnitt häufiger als Menschen ohne Behinderung (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
Der wirksamste 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 Hunderte Korrekturen
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 erfassen typischerweise nur 30 bis 40 Prozent (Deque, 2021) der Barrieren. 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 sind fast immer teurer zu beheben, als sie es in der Konzeption gewesen wären (Projekterfahrung).
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.
Dass sich dieser Weg lohnt, zeigt auch die wachsende Nachfrage nach Orientierung: Die Zahl der Erstberatungsanfragen bei der Bundesfachstelle für Barrierefreiheit stieg 2023 um 9 Prozent, die Websitebesuche nahmen um 29 Prozent (Bundesfachstelle für Barrierefreiheit, 2023) zu, mit besonderem Interesse an digitaler Barrierefreiheit. Frühe Integration zahlt zudem auf Ziele ein, die über Compliance hinausgehen: bessere Suchmaschinenoptimierung, geringeres Rechtsrisiko und höhere Kundenbindung (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