Barrierefreie Webentwicklung: WCAG und BFSG von Anfang an

Kurz gefasst: Barrierefreie Webentwicklung bedeutet, dass Menschen eine Anwendung auch mit Screenreader, nur mit der Tastatur, mit Vergrößerung oder eingeschränktem Farbsehen vollständig bedienen können. Maßstab sind die Web Content Accessibility Guidelines (WCAG), in der Regel auf Stufe AA. Seit Juni 2025 verpflichtet das Barrierefreiheitsstärkungsgesetz (BFSG) viele Unternehmen, die online Produkte oder Dienstleistungen an Verbraucher anbieten, zur Barrierefreiheit. Wer sie von Anfang an einplant, zahlt deutlich weniger als bei einer nachträglichen Sanierung.

Was das Barrierefreiheitsstärkungsgesetz verlangt

Das BFSG setzt den European Accessibility Act in deutsches Recht um und gilt seit dem 28. Juni 2025. Betroffen sind unter anderem Onlineshops und andere Dienstleistungen im elektronischen Geschäftsverkehr mit Verbrauchern, Bankdienstleistungen, E-Books und Teile des Personenverkehrs. Ausgenommen sind Kleinstunternehmen, die Dienstleistungen erbringen, also Unternehmen mit weniger als zehn Beschäftigten und höchstens zwei Millionen Euro Jahresumsatz oder Bilanzsumme. Reine B2B-Angebote fallen in der Regel nicht unter das Gesetz.

Technisch verweist das Gesetz auf die harmonisierte Norm EN 301 549, die wiederum auf die WCAG aufbaut. Zusätzlich verlangt das BFSG eine Erklärung zur Barrierefreiheit, die beschreibt, wie die Anforderungen erfüllt werden. Ob Ihr Angebot betroffen ist, sollten Sie im Einzelfall rechtlich prüfen lassen. Dieser Beitrag ersetzt keine Rechtsberatung.

Unabhängig von der Pflicht lohnt sich Barrierefreiheit: Sie verbessert die Bedienbarkeit für alle, etwa auf dem Smartphone in der Sonne oder für ältere Nutzer, und semantisch sauberes HTML hilft auch Suchmaschinen.

Die Grundlagen barrierefreier Webentwicklung

Semantisches HTML

Der wichtigste Schritt kostet fast nichts: die richtigen HTML-Elemente verwenden. Ein Button ist ein <button> und kein <div> mit Klick-Handler. Überschriften folgen einer logischen Hierarchie, Navigation steckt in <nav>, der Hauptinhalt in <main>. Screenreader nutzen diese Struktur, um sich auf der Seite zu orientieren. ARIA-Attribute sind eine Ergänzung für Fälle, die HTML nicht abdeckt, und kein Ersatz. Falsch eingesetzt verschlechtern sie die Zugänglichkeit eher.

Tastaturbedienung und Fokus

Alles, was mit der Maus geht, muss auch mit der Tastatur gehen. Der Fokus muss jederzeit sichtbar sein, und die Reihenfolge beim Durchtabben sollte dem Lesefluss entsprechen. Besonders kritisch sind Dialoge, Dropdown-Menüs und eigene Komponenten wie Datumsauswahlen. Bei einem Modal gehört der Fokus beim Öffnen hinein und beim Schließen zurück zum auslösenden Element.

Kontraste, Farben und Text

WCAG AA verlangt für normalen Text ein Kontrastverhältnis von mindestens 4,5:1, für große Schrift 3:1. Informationen dürfen nicht allein über Farbe vermittelt werden, etwa ein rot markiertes Formularfeld ohne Fehlertext. Text sollte sich auf das Doppelte vergrößern lassen, ohne dass Inhalte abgeschnitten werden. Wie Farbwahl und Wirkung zusammenhängen, lesen Sie in unserem Beitrag zur Psychologie der Farben in digitalen Produkten.

Bilder, Medien und Formulare

Informative Bilder brauchen einen Alternativtext, der ihren Inhalt beschreibt, dekorative Bilder ein leeres alt-Attribut. Videos brauchen Untertitel. Jedes Formularfeld braucht ein sichtbares, korrekt verknüpftes Label, und Fehlermeldungen müssen klar sagen, was falsch ist und wie es sich beheben lässt.

Barrierefreiheit im Entwicklungsprozess verankern

Am günstigsten ist Barrierefreiheit, wenn sie in den Bausteinen steckt. Ein Design-System mit geprüften, zugänglichen Komponenten sorgt dafür, dass jeder neue Bildschirm die Grundlagen automatisch mitbringt. In React-Projekten helfen Bibliotheken wie Radix UI oder React Aria, die Tastatursteuerung und ARIA-Verhalten für komplexe Komponenten bereits korrekt umsetzen.

Auch beim Testen lässt sich viel automatisieren. Das ESLint-Plugin jsx-a11y findet Fehler schon im Editor, axe-core prüft Seiten in Unit- und End-to-End-Tests, und Lighthouse gibt einen schnellen Überblick. Wie diese Tests in eine Teststrategie passen, beschreibt unser Artikel zu Teststrategien für React-Anwendungen. Automatische Werkzeuge finden allerdings nur einen Teil der Probleme. Ergänzen Sie sie durch manuelle Tests mit Tastatur und mit Screenreadern wie NVDA unter Windows oder VoiceOver auf macOS und iOS.

Häufige Fragen (FAQ)

Fällt meine Website unter das Barrierefreiheitsstärkungsgesetz?

Wenn Sie über die Website Produkte oder Dienstleistungen an Verbraucher verkaufen, etwa in einem Onlineshop oder mit einer Online-Buchung, ist das wahrscheinlich. Ausgenommen sind Kleinstunternehmen bei Dienstleistungen. Lassen Sie den konkreten Fall rechtlich prüfen.

Welche WCAG-Stufe sollten wir anstreben?

Stufe AA ist der übliche Maßstab und die Grundlage der europäischen Norm. Stufe AAA ist für ganze Websites kaum vollständig erreichbar und wird nur für einzelne Inhalte empfohlen.

Reicht ein Barrierefreiheits-Overlay oder Plugin?

Nein. Overlays, die per Skript nachträglich Funktionen einblenden, beheben die Ursachen im Code nicht und werden von vielen Menschen mit Behinderung als störend empfunden. Barrierefreiheit muss im HTML, im Design und in den Komponenten umgesetzt werden.

Was kostet es, eine bestehende Website barrierefrei zu machen?

Das hängt stark vom Zustand des Codes ab. Ein Audit nach WCAG zeigt, welche Probleme bestehen und wie aufwendig die Behebung ist. Bei Neuentwicklungen ist der Mehraufwand gering, wenn Barrierefreiheit von Anfang an Teil der Anforderungen ist.

Fazit

Barrierefreiheit ist zuerst eine Frage sauberer Grundlagen: semantisches HTML, Tastaturbedienung, ausreichende Kontraste und zugängliche Komponenten. Wer diese Punkte von Beginn an in Design-System und Tests verankert, erfüllt die gesetzlichen Anforderungen ohne teure Nacharbeit. Wenn Sie eine barrierefreie Webanwendung planen oder eine bestehende prüfen lassen möchten, sprechen Sie mit uns über barrierefreie Webentwicklung.