Barrierefreiheit beim Relaunch einplanen: Checkliste für Website-Redesigns

Barrierefreiheit von Anfang an vs. nachträglich: Der Kostenvergleich

Barrierefreiheit nachträglich einzubauen kostet laut Studien 10x mehr als sie von Anfang an einzuplanen. Wenn du sowieso einen Relaunch planst, ist jetzt der perfekte Zeitpunkt: Die Kosten für Barrierefreiheit verschwinden im Gesamtbudget, und du startest direkt BFSG-konform.

Warum ist der Unterschied so groß? Wenn Barrierefreiheit von Beginn an im Projekt verankert ist, fließt sie in jede Entscheidung ein – von der Farbwahl über die Informationsarchitektur bis zur Komponentenentwicklung. Nachträglich bedeutet dagegen: bestehende Komponenten aufreißen, umbauen, neu testen. Das ist teuer und fehleranfällig.

Ein konkretes Beispiel: Ein Design-System mit barrierefreien Farb-Tokens kostet in der Erstellung vielleicht 2 Stunden mehr. Nachträglich alle Farben in 200 Komponenten anzupassen, weil der Kontrast nicht stimmt, kostet Wochen.

Projektphasen mit Barrierefreiheit: Der vollständige Ablauf

Ein barrierefreier Relaunch besteht aus sechs Phasen, in denen Barrierefreiheit jeweils eine spezifische Rolle spielt. Hier der Überblick – jede Phase wird weiter unten im Detail behandelt:

1. Konzept & Strategie – Anforderungen definieren, Zielgruppen mit Behinderungen einbeziehen
2. Design – Barrierefreie Farbpalette, Typografie, Interaktionsmuster
3. Entwicklung – Semantisches HTML, ARIA, Tastatur-Navigation
4. Content-Migration – Alt-Texte, Überschriften-Hierarchie, Linktexte
5. QA & Testing – Automatisch + manuell + User-Testing
6. Launch & Monitoring – Go-Live-Check, kontinuierliche Überwachung

Phase 1: Konzept – Ausschreibung und Lastenheft richtig formulieren

Sage klar: "Die neue Webseite muss WCAG 2.1 Level AA erfüllen." Fordere: Ein barrierefreies Theme/Template als Basis. Tastatur-Tests in jeder Entwicklungsphase. Alt-Text-Felder für alle Medien-Typen. Und: Einen Barrierefreiheits-Test vor dem Go-Live.

Im Lastenheft oder der Ausschreibung solltest du folgende Formulierungen aufnehmen:

• "Die Webseite muss die Barrierefreiheitsanforderungen nach BFSG und EN 301 549 erfüllen (Konformitätsstufe WCAG 2.1 Level AA)."
• "Der Auftragnehmer weist die Barrierefreiheit durch einen dokumentierten Audit vor Go-Live nach."
• "Alle UI-Komponenten müssen per Tastatur bedienbar sein (WCAG SC 2.1.1 Keyboard)."
• "Das CMS muss Alt-Text-Felder und Strukturierungsmöglichkeiten (Überschriften, Listen, Tabellen) für Redakteure bereitstellen."
• "Barrierefreiheits-Tests sind Bestandteil jeder Abnahme (Sprint-Review / Meilenstein)."

Tipp: Wenn deine Agentur auf diese Anforderungen unsicher reagiert, ist das ein Warnsignal. Eine professionelle Agentur sollte mit WCAG-Anforderungen vertraut sein. Im Zweifel kannst du einen unabhängigen Barrierefreiheits-Audit als Abnahmekriterium vereinbaren.

Phase 2: Design-System mit Accessibility-Tokens

Farbpalette auf Kontrastverhältnisse prüfen (mindestens 4,5:1 für normalen Text nach WCAG SC 1.4.3 Contrast Minimum, 3:1 für großen Text). Schriftgröße mindestens 16px für Fließtext. Klickflächen mindestens 44x44px (WCAG SC 2.5.5 Target Size). Fokus-Styles im Design definieren – nicht dem Entwickler überlassen. Animationen abschaltbar planen (prefers-reduced-motion, WCAG SC 2.3.3).

Ein barrierefreies Design-System enthält folgende Accessibility-Tokens:

Farb-Tokens: Definiere für jede Farbe im System den Kontrastwert zum Hintergrund. Nutze Tools wie Kontrastprüfer, um sicherzustellen, dass alle Text-Hintergrund-Kombinationen WCAG SC 1.4.3 erfüllen. Dokumentiere die erlaubten Kombinationen – so vermeidest du, dass Designer oder Entwickler später kontrastarme Kombinationen verwenden.

Spacing und Touch-Targets: Definiere Mindestgrößen für interaktive Elemente (44x44px) und Mindestabstände zwischen klickbaren Elementen. Das ist besonders wichtig für mobile Nutzung und Menschen mit motorischen Einschränkungen.

Focus-Styles: Gestalte sichtbare, deutliche Focus-Indikatoren als Teil des Designs – nicht als Entwickler-Nachgedanke. Der Fokusring muss nach WCAG SC 2.4.7 (Focus Visible) für alle interaktiven Elemente klar erkennbar sein. Ein gut gestalteter Focus-Style kann sogar das visuelle Design aufwerten.

Typografie: Definiere eine Schrift-Hierarchie mit ausreichenden Größen und Zeilenabständen. Mindestens 1,5-facher Zeilenabstand für Fließtext (WCAG SC 1.4.12 Text Spacing). Vermeide reine Großbuchstaben-Texte für längere Passagen.

Phase 3: Entwicklung – Semantisches HTML, ARIA und Tastatur

Die Entwicklungsphase ist der Kern der technischen Barrierefreiheit. Hier werden die Design-Vorgaben in barrierefreien Code umgesetzt.

Semantisches HTML: Nutze die richtigen HTML-Elemente für ihren Zweck. <nav> für Navigation, <main> für den Hauptinhalt, <button> für Aktionen, <a> für Links. Vermeide <div>-Suppen mit Click-Handlern – Screenreader und Tastatur-Nutzer können diese nicht bedienen.

ARIA richtig einsetzen: ARIA (Accessible Rich Internet Applications) ergänzt semantisches HTML dort, wo native Elemente nicht ausreichen – zum Beispiel bei komplexen Widgets wie Tabs, Akkordeons oder Modals. Die erste Regel von ARIA lautet: Wenn ein natives HTML-Element den Zweck erfüllt, nutze es statt ARIA.

Tastatur-Navigation (WCAG SC 2.1.1): Alle interaktiven Elemente müssen per Tastatur erreichbar und bedienbar sein. Teste mit Tab, Shift+Tab, Enter und Escape. Achte auf eine logische Tab-Reihenfolge und stelle sicher, dass kein Tastatur-Trap entsteht (SC 2.1.2), also kein Element, aus dem der Nutzer per Tastatur nicht mehr herauskommt.

Skip-Links: Implementiere einen "Zum Inhalt springen"-Link als erstes fokussierbares Element. So können Tastatur-Nutzer die Navigation überspringen und direkt zum Hauptinhalt gelangen (WCAG SC 2.4.1 Bypass Blocks).

Formulare: Jedes Formularfeld braucht ein programmatisch verknüpftes Label (<label for="...">). Fehlermeldungen müssen klar beschrieben und dem Feld zugeordnet sein (SC 3.3.1 Error Identification). Pflichtfelder müssen nicht nur visuell, sondern auch programmatisch gekennzeichnet sein (aria-required="true").

Phase 4: Content-Migration – Inhalte barrierefrei übertragen

Bei einem Relaunch werden bestehende Inhalte migriert. Das ist die perfekte Gelegenheit, Barrierefreiheitsmängel im Content zu beheben.

Alt-Texte für Bilder: Jedes informative Bild braucht einen beschreibenden Alt-Text (WCAG SC 1.1.1 Non-text Content). Rein dekorative Bilder erhalten ein leeres alt-Attribut (alt=""). Bei der Migration: Prüfe jeden Alt-Text auf Aussagekraft – "Bild1.jpg" oder "Logo" ist kein hilfreicher Alt-Text.

Überschriften-Hierarchie: Stelle sicher, dass die Überschriften eine logische Struktur bilden (h1 > h2 > h3). Überspringe keine Ebenen. Screenreader-Nutzer navigieren primär über Überschriften – eine saubere Hierarchie ist für sie wie ein Inhaltsverzeichnis.

Aussagekräftige Linktexte (WCAG SC 2.4.4): Vermeide generische Linktexte wie "hier klicken" oder "mehr erfahren". Der Linktext muss auch ohne umgebenden Kontext verständlich sein. Statt "Mehr erfahren" besser "Barrierefreiheits-Checkliste herunterladen".

Videos und Multimedia: Stelle Untertitel für Videos bereit (SC 1.2.2) und Audiodeskription für visuelle Inhalte (SC 1.2.5). Bei der Migration ist das die Gelegenheit, fehlende Untertitel nachzurüsten.

Dokumente: PDFs und andere Dokumente, die auf der Webseite verlinkt sind, müssen ebenfalls barrierefrei sein (getaggte PDFs mit Lesereihenfolge). Alternativ: HTML-Version anbieten.

Phase 5: Testing-Matrix – Automatisch, manuell und mit Nutzern

Eine gründliche Teststrategie kombiniert drei Ebenen:

1. Automatische Tests: Nutze den BFSG-Scanner von bf-check.de und weitere Tools wie axe oder Lighthouse, um systematisch nach technischen Barrieren zu suchen. Automatische Tests decken etwa 30-40 % aller WCAG-Kriterien ab – vor allem technische Aspekte wie fehlende Alt-Texte, Kontrastprobleme und fehlende Labels. Mehr dazu in unserem Tool-Überblick.

2. Manuelle Tests: Ergänze automatische Tests durch manuelle Prüfungen:

• Tastatur-Test: Navigiere die gesamte Seite nur mit Tastatur (Tab, Enter, Escape, Pfeiltasten). Ist alles erreichbar? Ist der Fokus immer sichtbar?
• Screenreader-Test: Teste die wichtigsten Seiten mit NVDA (Windows, kostenlos) oder VoiceOver (macOS/iOS). Werden alle Inhalte korrekt vorgelesen?
• Zoom-Test: Vergrößere auf 200 % – sind alle Inhalte noch lesbar und bedienbar (SC 1.4.4 Resize Text)?
• Farb-Test: Prüfe, ob Informationen auch ohne Farbe verständlich sind (SC 1.4.1 Use of Color).

3. User-Testing mit Menschen mit Behinderungen: Der wertvollste Test. Lade Screenreader-Nutzer, Menschen mit motorischen Einschränkungen oder kognitiven Behinderungen ein, deine Seite zu testen. Kein automatisches Tool und kein manueller Test ersetzt die Erfahrung echter Nutzer. Organisationen wie die "Aktion Mensch" oder lokale Inklusionsbeauftragte können bei der Vermittlung helfen.

Erstelle eine Testing-Matrix, die dokumentiert, welche Seiten mit welcher Methode getestet wurden. Ein systematisches Audit hilft dir, den Überblick zu behalten.

Phase 6: Go-Live-Checkliste und Post-Launch-Monitoring

Vor dem Launch solltest du folgende Punkte abhaken:

• Automatischen BFSG-Scan durchführen (bf-check.de)
• Tastatur-Test der gesamten Seite bestanden
• Screenreader-Test der wichtigsten Seiten bestanden
• Zoom-Test bis 200 % bestanden (SC 1.4.4)
• Barrierefreiheitserklärung veröffentlicht
• Feedback-Mechanismus für Nutzer eingerichtet
• Alle Formulare mit Labels und Fehlermeldungen versehen
• Alt-Texte für alle informativen Bilder vorhanden
• Fokus-Reihenfolge auf allen Seiten logisch
• Skip-Link zum Hauptinhalt funktioniert

Post-Launch-Monitoring ist genauso wichtig wie die Prüfung vor dem Launch. Barrierefreiheit ist kein einmaliges Projekt, sondern ein laufender Prozess:

• Monatlich: Automatisierten Scan durchführen (neue Inhalte können neue Barrieren einführen)
• Quartalsweise: Manuelle Stichproben bei neuen Seiten und Funktionen
• Jährlich: Vollständiges Audit mit allen drei Testebenen
• Laufend: Nutzer-Feedback auswerten und Barrieren zeitnah beheben

Häufige Fehler bei Relaunches

Aus zahlreichen Relaunch-Projekten lassen sich typische Stolperfallen identifizieren:

• Barrierefreiheit erst in der QA-Phase berücksichtigen: Wenn das Design fertig und die Entwicklung abgeschlossen ist, bleibt nur noch Flickwerk. Barrierefreiheit muss ab Phase 1 mitgedacht werden.
• Overlay-Tools als Lösung einplanen: Automatische Accessibility-Overlays sind keine konforme Lösung und können sogar zusätzliche Barrieren schaffen. Sie halten weder einer WCAG-Prüfung noch einer behördlichen Kontrolle stand.
• Nur die Startseite testen: Teste alle relevanten Seitentypen – Produktseiten, Formulare, Checkout-Prozess, Blog-Artikel, 404-Seite.
• Custom-Komponenten ohne ARIA: Individuelle UI-Komponenten (Slider, Tabs, Akkordeons) werden oft ohne korrekte ARIA-Attribute entwickelt. Screenreader können sie dann nicht bedienen.
• Content-Migration ohne Alt-Text-Prüfung: Alte Inhalte werden 1:1 übertragen – inklusive fehlender oder nichtssagender Alt-Texte. Die Migration ist die Chance, das aufzuräumen.
• Fokus-Styles deaktivieren: Manche Designer empfinden den Browser-Fokusring als "hässlich" und entfernen ihn per CSS (outline: none). Das verstößt direkt gegen WCAG SC 2.4.7 und macht die Seite für Tastatur-Nutzer unbedienbar.
• Keine Verantwortlichkeit nach dem Launch: Ohne klare Zuständigkeit verwässert die Barrierefreiheit mit jeder Content-Änderung und jedem neuen Feature.

Dieser Artikel ersetzt keine Rechtsberatung. Bei konkreten Fragen zur BFSG-Konformität deiner Webseite wende dich an einen spezialisierten Berater oder nutze unseren kostenlosen BFSG-Scanner für eine erste Einschätzung.

Häufig gestellte Fragen