Das Wichtigste in 60 Sekunden / tl;dr
- Ein Accessibility-Menü kann individuelle Darstellungswünsche unterstützen. Es macht eine ansonsten unzugängliche Website aber nicht barrierefrei.
- Die tragende Basis sind semantisches HTML, verständliche Namen und Beschriftungen, logische Überschriften, vollständige Tastaturbedienung und sichtbare Fokuszustände.
- Automatische Tests finden viele typische Fehler schnell. Ob ein Ablauf wirklich verständlich und bedienbar ist, muss zusätzlich manuell geprüft werden.
- Beim Paulus-Ausbau kamen Skip-Link, Sprachkennzeichnung, Fokusverbesserungen, reduzierte Bewegung und gespeicherte Darstellungsoptionen zusammen.
- Mein wichtigster Lernpunkt: Accessibility ist kein einmaliges Feature. Jede neue Navigation, jedes Dialogfenster und jedes Formular kann neue Barrieren einführen.
01
Warum ich die Paulus-Website im März 2026 umgebaut habe
Der Ausgangspunkt war kein Gesetzestext und auch kein Kundenauftrag. Die Website war visuell sauber und responsiv, aber ich wollte genauer wissen, wie sie sich für Menschen verhält, die sie nicht mit Maus, Standardschrift und normalen Animationseinstellungen bedienen.
Am 7. und 8. März 2026 entstand daraus ein größerer Ausbau. Ich ergänzte einen Skip-Link zum Hauptinhalt, verbesserte Fokuszustände und Tastaturwege, synchronisierte die Dokumentsprache und entwickelte ein Einstellungsmenü für verschiedene visuelle und motorische Bedürfnisse. Die Einstellungen werden lokal im Browser gespeichert.
Gerade das sichtbare Menü ist leicht zu zeigen. Rückblickend ist es aber nur die Oberfläche eines größeren Themas: Eine Website muss bereits in ihrer normalen Ausführung verständlich und bedienbar sein.
02
Die eigentliche Arbeit ist weitgehend unsichtbar
Barrierefreiheit beginnt in der normalen Oberfläche. Die folgenden Grundlagen helfen Screenreadern und Tastaturnutzern, verbessern aber häufig auch Wartbarkeit, SEO und Bedienbarkeit für alle anderen.
Semantische Struktur
Überschriften, Navigation, Hauptinhalt, Buttons, Links und Formulare müssen ihrer tatsächlichen Aufgabe entsprechend ausgezeichnet sein. Ein klickbares div bleibt trotz Styling ein schlechtes Bedienelement.
Dokumentsprache
Das lang-Attribut folgt auf der Paulus-Website der deutschen oder englischen Ansicht. Screenreader können dadurch Aussprache und Sprachregeln passend wählen.
Tastatur und Fokus
Interaktive Elemente müssen in einer logischen Reihenfolge erreichbar sein. Der Fokus muss sichtbar bleiben und darf in Menüs oder Dialogen weder verschwinden noch stecken bleiben.
Sprung zum Inhalt
Ein Skip-Link erlaubt es, wiederkehrende Navigation direkt zu überspringen. Er bleibt im normalen Layout unscheinbar und wird sichtbar, sobald er Tastaturfokus erhält.
Bewegung und Kontrast
Systempräferenzen wie reduced motion sollten respektiert werden. Text, Bedienelemente und Fokusmarkierungen brauchen ausreichenden Kontrast, nicht erst nach Öffnen eines Zusatzmenüs.
Namen und Rückmeldungen
Icons, Eingabefelder, Fehlermeldungen und Statusänderungen benötigen verständliche, programmatisch ermittelbare Bezeichnungen. Visuelle Nähe allein stellt diese Beziehung nicht her.
WCAG 2.2 ordnet diese Anforderungen unter anderem den Prinzipien wahrnehmbar, bedienbar, verständlich und robust zu. Die Leitlinien sind keine Komponentenbibliothek, sondern überprüfbare Erfolgskriterien für Inhalte und Abläufe.
05
Automatische 100 Punkte sind ein Startpunkt, kein Zertifikat
Die vorhandenen Lighthouse-Prüfungen der Paulus-Website erreichten im Accessibility-Bereich 100 Punkte. Das ist erfreulich, weil typische technische Fehler nicht übersehen wurden. Es sagt aber nicht, dass jede Seite, jeder Zustand und jeder Nutzerfluss vollständig barrierefrei ist.
Automatische Werkzeuge können beispielsweise fehlende Alternativtexte, geringe Kontraste, unbeschriftete Formfelder oder bestimmte ARIA-Fehler erkennen. Ob ein Alternativtext sinnvoll ist, eine Fokusreihenfolge logisch wirkt oder eine Fehlermeldung wirklich weiterhilft, erfordert menschliche Beurteilung.
Das W3C formuliert diese Grenze eindeutig: Evaluierungswerkzeuge unterstützen die Prüfung, können Barrierefreiheit aber nicht allein feststellen. Deshalb kombiniere ich technische Checks mit realer Bedienung.
Vier sinnvolle Prüfebenen
Automatisiert
Lighthouse, axe oder WAVE für schnell erkennbare Regelverstöße und Regressionen.
Tastatur
Alle Wege mit Tab, Shift+Tab, Enter, Leertaste und Escape durchlaufen, ohne Maus.
Darstellung
Zoom, schmale Viewports, Textabstände, Dark Mode, hoher Kontrast und reduzierte Bewegung prüfen.
Assistive Technik
Relevante Abläufe mit Screenreader oder Sprachsteuerung testen und bei hohem Anspruch betroffene Nutzer einbeziehen.
Dass das Thema nicht „erledigt“ ist, zeigt der WebAIM-Million-Bericht 2026: Auf 95,9 Prozent der untersuchten Startseiten wurden automatisch erkennbare WCAG-Fehler gefunden. Da automatische Tests nur einen Teil der Probleme entdecken, liegt die vollständige Konformität laut Bericht noch niedriger.
06
BFSG: relevanter Anlass, aber nicht der einzige Grund
Seit dem 28. Juni 2025 gelten in Deutschland über das Barrierefreiheitsstärkungsgesetz Anforderungen für bestimmte Produkte und Dienstleistungen. Im E-Commerce betrifft das insbesondere Dienstleistungen, die über Websites oder Apps auf den Abschluss eines Verbrauchervertrags ausgerichtet sind.
Das bedeutet nicht, dass jede Unternehmenswebsite automatisch unter dieselben Pflichten fällt. Auch Ausnahmen sind relevant: Nach Angaben der Bundesfachstelle sind Kleinstunternehmen mit weniger als zehn Beschäftigten und höchstens zwei Millionen Euro Jahresumsatz grundsätzlich ausgenommen, soweit sie Dienstleistungen anbieten oder erbringen. Der konkrete Anwendungsfall sollte trotzdem individuell geprüft werden.
Für Produktentwicklung ist die rein juristische Mindestfrage ohnehin zu klein. Gute Tastaturbedienung, verständliche Formulare und robuste Kontraste helfen auch Menschen mit gebrochenem Arm, müden Augen, schlechter Verbindung, hellem Sonnenlicht oder ungewohnter Bedienung. Accessibility ist deshalb ebenso eine Qualitäts- und Produktentscheidung.
Keine pauschale BFSG-Ampel
Ob ein konkretes Angebot unter das BFSG fällt und welche Normen anzuwenden sind, hängt von Produkt, Dienstleistung, Unternehmensgröße und Zielgruppe ab. Ein Blogbeitrag ersetzt diese rechtliche Einordnung nicht.
07
Ein Zehn-Minuten-Test für die eigene Website
Dieser Kurztest ersetzt keinen Audit. Er findet aber erstaunlich oft Probleme, die im normalen Entwicklungsalltag unsichtbar bleiben.
Maus weglegen
Mit Tab durch die Seite gehen. Ist immer erkennbar, welches Element aktiv ist? Erreicht man alle Funktionen und kommt aus jedem Dialog wieder heraus?
Auf 200 Prozent zoomen
Bleiben Texte lesbar und Bedienelemente erreichbar? Überlagert eine feste Navigation Inhalte? Muss in zwei Richtungen gescrollt werden?
Bilder ausschalten oder prüfen
Vermitteln Alternativtexte den Zweck relevanter Bilder? Sind dekorative Bilder korrekt als dekorativ behandelt?
Formular absichtlich falsch absenden
Werden Fehler verständlich erklärt und den richtigen Feldern zugeordnet? Bleiben bereits eingegebene Daten erhalten?
Animationen reduzieren
Respektiert die Seite prefers-reduced-motion? Bleiben Orientierung und Funktion erhalten, wenn Bewegung entfällt?
Überschriften überfliegen
Erzählt ihre Reihenfolge die Struktur der Seite oder wurden Ebenen nur wegen ihrer Schriftgröße gewählt?
Kontrast und Farbe prüfen
Bleiben Zustände erkennbar, wenn Farbe allein nicht wahrgenommen wird? Sind Text, Rahmen und Fokusmarkierungen deutlich genug?
Wenn bereits einer dieser Schritte einen wichtigen Ablauf blockiert, ist das kein kosmetischer Mangel. Es ist ein Produktfehler mit konkreter Auswirkung auf Nutzer.
08
Was ich heute anders einordne als beim ersten Ausbau
Der März-Ausbau war wertvoll, weil er Accessibility sichtbar und technisch greifbar gemacht hat. Gleichzeitig zeigen einige damalige Entscheidungen, wie leicht man Barrierefreiheit zunächst als Zusatzfunktion denkt.
Ein Beispiel ist eine Option namens „Screenreader-Optimierung“. Die Idee war, bei Bedarf zusätzliche Semantik zu aktivieren. Heute würde ich diese Trennung nicht mehr als Zielbild wählen: Alles, was für korrekte Namen, Rollen, Zustände und Landmarken notwendig ist, gehört ohne Aktivierung in die Standardausgabe. Ein optionaler Modus darf nur ergänzen, niemals den eigentlichen Zugang herstellen.
Auch fest benannte Kontraststufen oder ein perfekter Automatenscore sollten nicht zu große Sicherheit erzeugen. Konformität gilt nicht pauschal für eine Farbe oder eine Startseite, sondern für die konkrete Kombination aus Inhalt, Komponente, Zustand und vollständigem Prozess.
Was sich bewährt hat
- Accessibility-Präferenzen zentral als Zustände und CSS-Variablen zu modellieren
- Systemeinstellungen wie reduzierte Bewegung früh zu berücksichtigen
- Skip-Link, sichtbaren Fokus und Dokumentsprache als globale Basis zu behandeln
- Einstellungen lokal zu speichern und einfach zurücksetzbar zu machen
- neue Komponenten nicht nur visuell, sondern auch per Tastatur zu prüfen
09
Häufige Fragen
Macht ein Accessibility-Menü eine Website WCAG-konform?
Nein. Es kann individuelle Präferenzen unterstützen, ersetzt aber weder zugängliche Struktur und Bedienung noch eine vollständige Evaluation.
Reicht ein Lighthouse-Accessibility-Score von 100?
Nein. Der Score zeigt, dass die geprüfte Seite bei den automatisierbaren Regeln gut abschneidet. Viele Fragen zu Verständlichkeit, Fokusführung, Alternativtexten und vollständigen Prozessen benötigen manuelle Prüfung.
Muss jede Website wegen des BFSG barrierefrei sein?
Nein, der Anwendungsbereich ist differenziert und enthält Ausnahmen. Besonders relevant sind bestimmte Produkte und verbraucherbezogene Dienstleistungen, etwa im elektronischen Geschäftsverkehr. Der konkrete Fall sollte fachlich oder rechtlich geprüft werden.
Welche Maßnahme bringt meist zuerst etwas?
Eine vollständige Tastaturrunde durch die wichtigsten Nutzerabläufe. Sie deckt häufig fehlende Fokuszustände, falsche Elemente, unbedienbare Dialoge und ungünstige Reihenfolgen auf.
Sollte es einen besonderen Screenreader-Modus geben?
Notwendige Semantik sollte immer vorhanden sein. Ein optionaler Modus kann höchstens zusätzliche Präferenzen anbieten, darf aber nicht Voraussetzung für Screenreader-Zugang sein.
Ist Barrierefreiheit nur für Menschen mit dauerhafter Behinderung relevant?
Nein. Auch temporäre oder situative Einschränkungen spielen eine Rolle, etwa Verletzungen, grelles Licht, kleine Displays, reduzierte Aufmerksamkeit oder die Bedienung ohne Maus.
10
Quellen und weiterführende Informationen
Für Standards und Rechtsfragen habe ich bewusst Primärquellen und die aktuelle WebAIM-Erhebung verwendet.