Seit dem 28. Juni 2025 gilt das Barrierefreiheitsstärkungsgesetz, kurz BFSG. Nach Angaben der Bundesfachstelle Barrierefreiheit betrifft es bestimmte Produkte und Dienstleistungen, die nach diesem Tag in Verkehr gebracht oder erbracht werden. Ob und wie das Gesetz für Ihre Website gilt, ist eine rechtliche Frage, die ich hier nicht beantworte. Informationen und Antworten auf häufige Fragen bietet die Bundesfachstelle auf ihrer Seite zum BFSG.
In diesem Beitrag geht es um die Technik. Ich zeige, was eine Website für Menschen mit Behinderungen nutzbar macht und wie man das baut und testet. Dazu beschreibe ich, was auf dieser Website umgesetzt ist.
Der Maßstab für die Technik
Die Web Content Accessibility Guidelines, kurz WCAG, sind der Standard des W3C für barrierefreie Webinhalte. Die aktuelle Fassung ist WCAG 2.2. Sie ordnet jedes Erfolgskriterium einer von drei Stufen zu, von A über AA bis AAA. Die folgenden Abschnitte behandeln Kriterien, die in der Praxis bei fast jeder Website eine Rolle spielen. Welche Normen für das BFSG maßgeblich sind, erläutert die Bundesfachstelle auf ihrer Seite zu Normen und Standards.
Kontrast
Text braucht nach Kriterium 1.4.3 ein Kontrastverhältnis von mindestens 4,5:1 zum Hintergrund. Für großen Text genügt 3:1, also ab 18 Punkt oder ab 14 Punkt in fetter Schrift. Kriterium 1.4.11 verlangt 3:1 auch für Bedienelemente und für Grafiken, die zum Verständnis nötig sind. Text in einem Logo ist von 1.4.3 ausgenommen.
Typische Schwachstellen sind hellgrauer Text, Platzhalter in Formularen und Text auf Fotos. Für diese Website haben wir Kontrast nach Stufe AA für das helle und das dunkle Design als Ziel festgelegt. Wer ein dunkles Design anbietet, sollte beide Fassungen einzeln kontrollieren.
Bedienung mit der Tastatur
Nach Kriterium 2.1.1 muss jede Funktion auch mit der Tastatur bedienbar sein. Kriterium 2.1.2 verlangt, dass der Fokus jedes Element mit der Tastatur auch wieder verlassen kann. Die Reihenfolge, in der der Fokus mit der Tabulatortaste durch die Seite springt, muss nach 2.4.3 den Sinn der Seite erhalten.
Typische Fehler sind Menüs, die sich nur beim Überfahren mit der Maus öffnen. Auch Schaltflächen, die als einfache Bereiche ohne Tastaturbedienung gebaut sind, sperren Menschen aus, die keine Maus benutzen.
Auf dieser Website schließt die Escape-Taste das Untermenü der Leistungen. Öffnet sich das mobile Menü, bekommt es selbst den Fokus. Nach dem Umschalten zwischen hellem und dunklem Design bleibt der Fokus auf einem sichtbaren Bedienelement.
Sichtbarer Fokus
Kriterium 2.4.7 verlangt, dass der Tastaturfokus sichtbar ist. WCAG 2.2 ergänzt mit 2.4.11, dass ein fokussiertes Element nicht vollständig von anderen Inhalten der Seite verdeckt sein darf. Das passiert leicht bei Kopfzeilen, die beim Scrollen oben stehen bleiben.
Auf dieser Website zeigt jedes Element im Tastaturfokus einen Rahmen in der Akzentfarbe. Springt der Fokus weiter, scrollt die Seite so weit, dass das Element unterhalb der fest stehenden Kopfzeile liegt.
Überschriften und Landmarks
Kriterium 1.3.1 verlangt, dass sichtbare Struktur auch im Code erkennbar ist. Eine Überschrift muss deshalb als Überschrift ausgezeichnet sein und darf nicht nur fett und groß aussehen. Nach 2.4.6 beschreiben Überschriften und Beschriftungen ihr Thema oder ihren Zweck. Screenreader springen von Überschrift zu Überschrift und zwischen Landmarks wie Kopfzeile, Navigation, Hauptinhalt und Fußzeile.
Kriterium 2.4.1 verlangt eine Möglichkeit, wiederkehrende Blöcke wie die Navigation zu überspringen. Nach 3.1.1 muss die Sprache jeder Seite im Code festgelegt sein.
Jede Seite dieser Website hat genau eine Hauptüberschrift, und ein Test schlägt fehl, wenn es mehr werden. Ein Link zum Überspringen der Navigation erscheint, sobald jemand die Tabulatortaste drückt. Die Navigationen in der Fußzeile tragen eigene Namen, damit ein Screenreader sie unterscheiden kann. Die Sprache steht auf jeder Seite im Code.
Formulare und Fehlermeldungen
Nach Kriterium 3.3.2 braucht jedes Eingabefeld eine Beschriftung oder Anleitung. Ein Platzhalter im Feld ersetzt keine Beschriftung, weil er beim Tippen verschwindet. Kriterium 3.3.1 verlangt, dass ein erkannter Fehler im Text beschrieben wird. Wo eine Korrektur bekannt ist, soll die Meldung sie nach 3.3.3 vorschlagen.
Im Kontaktformular dieser Website hat jedes Feld eine sichtbare Beschriftung, und Pflichtfelder sind gekennzeichnet. Jede Fehlermeldung ist mit ihrem Feld verknüpft, sodass ein Screenreader sie zusammen mit dem Feld vorliest. Fehlerhafte Felder sind als ungültig markiert, und das erste davon erhält den Fokus. Rückmeldungen nach dem Absenden erscheinen in einem Bereich, den Screenreader von selbst ansagen.
Textalternativen
Kriterium 1.1.1 verlangt für jeden Inhalt, der kein Text ist, eine Textalternative mit demselben Zweck. Ein Foto des Teams braucht eine Beschreibung, und ein Symbol als Link braucht einen Namen. Rein schmückende Grafiken bekommen einen leeren Alternativtext, damit Screenreader sie überspringen.
Auf dieser Website ist das Größer-Zeichen hinter Links vor Screenreadern verborgen, weil es nur schmückt. Auch das Punktraster im Hintergrund liest kein Screenreader vor.
Weniger Bewegung
Nach Kriterium 2.2.2 muss sich Bewegung, die von selbst startet und länger als fünf Sekunden läuft, anhalten oder ausblenden lassen. Kriterium 2.3.3 der Stufe AAA verlangt, dass sich Animationen nach einer Interaktion abschalten lassen. Das W3C nennt dafür die CSS-Abfrage prefers-reduced-motion als geeignete Technik. Sie fragt ab, ob im Betriebssystem reduzierte Bewegung eingestellt ist.
Auf dieser Website verkürzen sich bei dieser Einstellung alle Animationen und Übergänge auf einen Augenblick. Auch das Scrollen springt dann direkt zum Ziel, statt zu gleiten.
Testen
Automatische Werkzeuge finden nur einen Teil der Probleme. Das W3C schreibt zu seinen Easy Checks, dass eine Seite selbst diese einfachen Kontrollen bestehen und trotzdem erhebliche Barrieren haben kann. Ein Werkzeug erkennt etwa, dass ein Alternativtext fehlt. Ob ein vorhandener Alternativtext zum Bild passt, muss ein Mensch beurteilen, der das Bild im Zusammenhang sieht.
Für diese Website verlangen wir in Lighthouse auf jeder Seite die volle Punktzahl von 100 in der Kategorie Barrierefreiheit. Ein solcher Wert ersetzt aber nicht den Test von Hand, und dafür reichen wenige Schritte.
- Bedienen Sie jede Seite nur mit Tabulator, Eingabetaste und Escape.
- Achten Sie darauf, ob der Fokus immer sichtbar und nicht verdeckt ist.
- Vergrößern Sie die Seite im Browser auf 200 Prozent, denn nach Kriterium 1.4.4 dürfen dabei keine Inhalte verloren gehen.
- Schalten Sie im Betriebssystem reduzierte Bewegung ein und laden Sie die Seite neu.
- Hören Sie sich die Seite mit einem Screenreader an, etwa mit VoiceOver auf dem Mac oder NVDA unter Windows.
- Schicken Sie jedes Formular einmal mit Fehlern ab.
Ob das BFSG für Ihr Angebot gilt und welche Anforderungen daraus folgen, klären Sie mit der Bundesfachstelle Barrierefreiheit oder einem Anwalt. Wie diese Website entstanden ist, steht im Beitrag Ruxiom ist neu.
Wenn Sie es wünschen oder wenn es für Ihre Website gesetzlich vorgeschrieben ist, bauen wir sie barrierefrei, von der Bedienung mit der Tastatur bis zu beschrifteten Formularfeldern. Wie wir eine neue Website planen und umsetzen, zeigt die Seite zu Websites. Schreiben Sie uns, welche Seiten und Formulare Ihre Website haben soll, dann klären wir mit Ihnen die Anforderungen.