Barrierefreie Website umsetzen: Was im Code wirklich zählt

Barrierefreiheit ist keine Funktion, die man einer Website hinzufügt. Sie ist eine Eigenschaft davon, wie die Website gebaut ist - und genau deshalb scheitert jeder Versuch, sie nachträglich per Knopfdruck zu erzeugen. Wer wissen will, was hinter den Kürzeln WCAG und EN 301 549 tatsächlich steckt, findet hier die Liste, an der sich Seiten in der Praxis entscheiden.

Barrierefreiheit ist eine Bauweise, kein Nachrüstsatz

Der teure Weg beginnt damit, eine fertige Seite zu bauen und danach zu fragen, wie sie barrierefrei wird. Der günstige Weg besteht darin, dieselben Entscheidungen von Anfang an anders zu treffen: semantisches HTML statt einer Wand aus Divs, Farben, die den Kontrast bereits im Design bestehen, Komponenten, die von Haus aus mit der Tastatur funktionieren. Der Mehraufwand ist dann marginal. Nachträglich ist er es nie.

Wer zuerst wissen will, ob überhaupt eine Pflicht besteht, findet die Abgrenzung in BFSG 2026: Wer wirklich eine barrierefreie Website braucht. Für alles Weitere gilt: Wir liefern die technische Umsetzung, die rechtliche Bewertung Ihres Einzelfalls bleibt Sache einer Anwältin oder eines Anwalts.

Tastatur und Fokus: der Test, den die meisten Seiten verlieren

Legen Sie die Maus weg und drücken Sie ausschließlich die Tabulatortaste. Diese eine Prüfung dauert drei Minuten und deckt mehr Mängel auf als jedes automatische Werkzeug.

• Der Fokus ist jederzeit sichtbar. Ein Fokusring, der im Design entfernt und nicht ersetzt wurde, ist der häufigste einzelne Fehler überhaupt
• Die Reihenfolge folgt der sichtbaren Anordnung, nicht der Reihenfolge im Quelltext nach einem Grid-Umbau
• Jede Funktion ist erreichbar: Menüs, Slider, Akkordeons, Videosteuerung, Cookie-Dialog
• Nichts hält den Fokus fest. Ein Overlay muss sich mit der Escape-Taste schließen lassen und den Fokus danach dorthin zurückgeben, wo er herkam
• Ein Sprunglink zum Hauptinhalt erscheint beim ersten Tabulatordruck, damit niemand durch dreißig Navigationspunkte muss

WCAG 2.2 hat hier nachgeschärft: Das fokussierte Element darf nicht von klebrigen Kopfzeilen oder Chat-Widgets verdeckt werden, und Bedienelemente brauchen eine Mindestgröße von 24 mal 24 CSS-Pixeln oder ausreichend Abstand. Beides trifft ausgerechnet die Designs, die 2026 modern aussehen.

Kontrast, Struktur und Alternativtexte

Kontrast ist der Punkt, an dem Design und Norm am häufigsten kollidieren. Fließtext braucht 4,5:1 gegenüber seinem Hintergrund, große Schrift ab etwa 24 Pixel oder 18,66 Pixel in Fett genügt mit 3:1, und auch Bedienelemente und aussagekräftige Grafiken müssen 3:1 erreichen. Hellgraue Schrift auf weißem Grund fällt fast immer durch. Dasselbe gilt für Text über Bildern ohne Abdunklung. Warum das im dunklen Design nicht automatisch besser wird, behandelt Dark Mode gegen Light Mode.

Ein zweiter Grundsatz: Farbe darf nie der einzige Informationsträger sein. Ein rot umrandetes Formularfeld ohne Text daneben sagt einem Teil Ihrer Besucher nichts.

Struktur heißt: genau eine h1 pro Seite, keine übersprungenen Ebenen, und Überschriften, die tatsächlich den folgenden Abschnitt benennen statt als Stilmittel zu dienen. Dazu die Landmarken header, nav, main und footer, damit Screenreader-Nutzer direkt zum Inhalt springen können. Alternativtexte beschreiben, was das Bild im Kontext beiträgt; rein dekorative Bilder bekommen einen leeren alt-Text, damit sie übersprungen werden. Die Formulierung „Bild von“ ist überflüssig, das weiß die Hilfstechnologie bereits.

Formulare: wo die meisten Abschlüsse scheitern

Formulare sind die Stelle, an der Barrierefreiheit und Conversion dieselbe Sache sind. Was hier hakt, kostet Sie nicht nur die Konformität, sondern die Anfrage.

Bewegung gehört in denselben Abschnitt, weil sie dieselbe Ursache hat: Effekte, die niemand abschalten kann. Respektieren Sie die Systemeinstellung für reduzierte Bewegung, verzichten Sie auf Animationen, die länger als fünf Sekunden ohne Steuerung laufen, und auf alles, was blinkt. Wie sich das mit mobiler Eingabe verträgt, vertieft Mobile Formulare; die Auswirkungen auf Ladeverhalten und Stabilität behandelt Page Experience.

Warum Overlay-Werkzeuge das Problem nicht lösen

Overlays sind Skripte, die per Codezeile eingebunden werden und versprechen, eine Seite nachträglich barrierefrei zu machen. Das ist attraktiv, weil es billig aussieht. Es funktioniert aus vier sachlichen Gründen nicht.

Erstens kann ein Skript keine Bedeutung erfinden, die im Markup fehlt. Ob ein Bild dekorativ ist oder eine Information trägt, welche Überschrift zu welchem Abschnitt gehört, was ein Symbol-Button auslöst: Das steht nirgends, also kann es nicht ausgelesen werden. Zweitens greifen Overlays in eine Umgebung ein, in der Nutzer bereits ihre eigene Hilfstechnologie mit eigenen Einstellungen betreiben, und stören sie dabei mitunter. Drittens ändern sie nichts an der zugrunde liegenden Seite, die in einer Prüfung weiterhin durchfällt. Viertens erzeugen sie ein Gefühl von Erledigung, das die eigentliche Arbeit verhindert.

Das ist keine Meinung aus dem Bauch. In der WebAIM-Befragung unter Fachleuten für Barrierefreiheit bewerteten 67 Prozent Overlays als kaum oder gar nicht wirksam; unter den Befragten mit Behinderung waren es 72 Prozent, und nur 2,4 Prozent hielten sie für sehr wirksam. Das Overlay Fact Sheet, eine Stellungnahme von über 570 Fachleuten weltweit, kommt zum selben Schluss. Wir empfehlen kein Overlay, auch nicht als Zwischenlösung, weil eine Zwischenlösung hier nur das Budget bindet, das die echte Korrektur braucht.

Konkrete Maßnahmen für die nächsten 90 Tage

• Tag 1-15: den Tastaturtest über die drei wichtigsten Seiten laufen lassen und jeden Punkt notieren, an dem Sie den Fokus verlieren oder hängen bleiben
• Tag 1-15: alle Textfarben gegen ihre tatsächlichen Hintergründe messen, inklusive Text auf Bildern und Buttons im Hover-Zustand
• Tag 16-45: Überschriftenhierarchie geraderücken, Landmarken ergänzen, Alternativtexte durchgehen und dekorative Bilder leer auszeichnen
• Tag 16-45: Formulare überarbeiten - sichtbare Labels, Fehlertexte am Feld, autocomplete-Attribute
• Tag 46-90: mit einem Screenreader durch die wichtigste Strecke gehen, idealerweise mit einer Person, die täglich damit arbeitet
• Tag 46-90: das Ergebnis dokumentieren und als Erklärung zur Barrierefreiheit veröffentlichen

Fazit

Barrierefreiheit im Code besteht aus wenigen, sehr konkreten Entscheidungen, die sich fast alle vor der ersten Zeile CSS treffen lassen. Wer sie früh trifft, zahlt kaum etwas dafür; wer sie nachholt, zahlt für jede einzelne. Ob Sie überhaupt müssen, klärt BFSG 2026. Was es kostet und was es außer Rechtssicherheit bringt, rechnet Barrierefreiheit: Kosten und Nutzen durch.