Die Meldung sieht meistens gleich aus. Jemand von außen schreibt, dass sich das Kontaktformular nicht mit der Tastatur ausfüllen lässt, oder die Rechtsabteilung schickt eine E-Mail über die Pflicht zur Barrierefreiheit. Der erste Reflex des Unternehmens? Ein Plugin finden, das die Sache am Wochenende erledigt. Dabei ist WCAG für Unternehmen eine Ingenieursfrage und keine juristische – die Kriterien beschreiben konkrete Verhaltensweisen der Oberfläche, die entweder im Code stehen oder eben nicht.
In Audits von Firmenwebsites, die ohne Gedanken an Barrierefreiheit gebaut wurden, sehe ich immer wieder dasselbe Bild: ein hübsches Layout, visuell tadellos, und darunter Divs, die Schaltflächen vortäuschen, ein Formular ohne Beschriftungen und ein Modal, aus dem der Screenreader nicht herausfindet. Die Reparatur besteht nicht darin, eine gesonderte “Version für Menschen mit Behinderung” danebenzustellen. Sie betrifft Templates, gemeinsam genutzte Komponenten und die Art, wie die Redaktion Inhalte veröffentlicht.
Inhaltsverzeichnis
Womit anfangen: ein Audit, das sagt, was zu reparieren ist
Ein sinnvolles Audit trennt zwei Schichten. Automatische Tests fangen einen Teil der technischen Probleme ab: fehlende Attribute, zu geringen Kontrast, Felder ohne zugeordnete Beschriftung, Fehler in der Struktur des Dokuments. Eine billige und schnelle Schicht, die ich als Erstes starte. Sie schließt aber nur einen Ausschnitt der Liste.
Der Rest verlangt die Beurteilung durch einen Menschen. Kein Scanner sagt Ihnen, ob der Alternativtext das Diagramm tatsächlich beschreibt. Auch nicht, ob die Fokusreihenfolge der visuellen Logik der Seite entspricht. Auch nicht, ob die Beschriftung „Auswählen” für jemanden etwas bedeutet, der die Anordnung daneben nicht sieht. Und die Kriterien zur Verständlichkeit und zur Vermeidung wiederholter Eingaben haben überhaupt keine automatischen Regeln.
Ein typischer Fehler ist es, den Bericht aus einem Werkzeug als Aufgabenliste zu behandeln, sortiert nach der Zahl der Vorkommen. Besser geht es anders: ein Audit der wichtigsten Website-Templates, beschränkt auf Startseite, Übersichtsseite, Leistungsseite und Kontaktformular, also auf die Wege, die ein Nutzer tatsächlich geht. Statt alle Unterseiten durchzumahlen.
Overlays und Barrierefreiheits-Widgets: warum das nicht funktioniert
Ein Overlay ist ein Skript, das nach dem Laden der Seite ihr Aussehen im Browser verändert: es vergrößert die Schrift, kehrt Farben um, legt ein Panel mit Reglern dazu. Das Quell-HTML bleibt unberührt. Alles, was aus einer schlechten Dokumentstruktur folgt, ist also weiterhin kaputt: falsche Semantik, fehlende Beschriftungen in Formularen, Fokusfallen, Modale, die sich mit der Escape-Taste nicht schließen lassen.
Dazu kommt das Betriebsrisiko, von dem beim Kauf niemand spricht. Das Skript überschreibt Stile und fängt Ereignisse ab, deshalb verhalten sich weitere Frontend-Releases unvorhersehbar, und die Diagnose eines solchen Konflikts kostet mitunter mehr als die Korrektur selbst. Vergleichen Sie das mit der Alternative: dasselbe Geld, in Komponenten investiert, bleibt dauerhaft im Projekt und arbeitet auf jeder weiteren Unterseite. Ähnlich gehe ich bei der Modernisierung älterer Webanwendungen vor, wo das Flicken von Symptomen meist nach einigen Monaten zurückkommt.
Die technische Schicht: was wir konkret im Code ändern
Das Fundament ist die HTML-Semantik. Überschriften bilden eine Hierarchie, die das Dokument beschreibt, Listen sind Listen, eine Schaltfläche ist ein button-Element und ein Verweis ein a-Tag mit einer sinnvollen Adresse. Langweilig? Vielleicht. Aber diese eine Entscheidung räumt mehr Barrieren aus dem Weg als eine beliebige Zahl später angeklebter ARIA-Attribute.
Der zweite Bereich sind Formulare, also die Stelle, an der ein Unternehmen Kontakte verliert. Die Beschriftung muss programmatisch mit dem Feld verknüpft sein, die Fehlermeldung muss beim Feld erscheinen und vom Screenreader angesagt werden, und der Status eines Feldes darf nicht allein von der Rahmenfarbe abhängen. Der dritte Bereich ist die Tastatur: sichtbarer Fokus, vorhersehbare Tab-Reihenfolge, ein Skip-Link, korrektes Öffnen und Schließen von Modalen und Menüs.
Die Reihe von Korrekturen, mit denen ich in einem typischen WordPress-Projekt oder in einer Frontend-Anwendung beginne:
- Ordnung in der Überschriftenhierarchie in den Templates des Themes und in den Blöcken des Editors,
- Ersetzen klickbarer Divs und Spans durch native Schaltflächen und Links,
- Beschriftungen, Beschreibungen und Fehlermeldungen in jedem Formular, einschließlich Newsletter und Suche,
- Wiederherstellung des sichtbaren Fokus-Stils, den ein CSS-Reset entfernt hat,
- Tastaturbedienung in Menüs, Karussells, Reitern und Modalen,
- Kontrast von Text und Bedienelementen, einschließlich der Zustände Hover und Disabled,
- Prüfung des Layouts bei einer Vergrößerung auf 200 Prozent und beim Umbruch der Inhalte auf schmalem Bildschirm.
Inhalt und Redaktion: hier geht Barrierefreiheit nach dem Launch kaputt
Der Dienstleister übergibt ein sauberes Template, und nach einem halben Jahr hat die Seite wieder Hunderte Fehler. Der Grund ist banal: Alternativtexte schreibt die Redaktion, nicht der Programmierer. Ein dekoratives Foto sollte ein leeres alt-Attribut haben, damit der Screenreader es übergeht. Eine Infografik mit Daten braucht eine Beschreibung, die dieselbe Information vermittelt wie die Grafik. Zwei verschiedene Situationen, zwei verschiedene Entscheidungen.
Die zweite typische Regression sind Überschriften, die als Formatierungswerkzeug benutzt werden. Die Redakteurin wählt H3, weil die Größe passt, und die Struktur des Dokuments bedeutet für die Navigation über Überschriften nichts mehr. Dauerhafte Schulden sind oft auch Videomaterialien ohne Untertitel, gescannte PDFs und Grafiken mit eingebettetem Text, die über Jahre veröffentlicht werden.
Die Lösung liegt im Prozess, nicht in der Technik. Eine Validierung im CMS, die das Veröffentlichen eines Bildes ohne Entscheidung über die Beschreibung blockiert, eine kurze Checkliste beim Publizieren, eine Schulung des Redaktionsteams. Das wirkt dauerhafter als ein einmaliges Audit, das mit einem PDF-Bericht endet.
Betrieb: Barrierefreiheit als Teil des Prozesses
Regression ist die Regel, kein Unfall. Jede neue Landingpage für eine Kampagne, jedes Plugin und jede Integration kann frühere Korrekturen zurücknehmen, meist unbemerkt. Deshalb lohnen sich automatische Barrierefreiheitstests in der CI selbst bei bescheidenem Umfang. Sie fangen die häufigsten Fehler ab, bevor sie in die Produktion gelangen, und kosten einen Bruchteil einer manuellen Durchsicht.
Die zweite Sache ist eine Definition of Done, erweitert um Tastaturbedienung und Semantik, geprüft bei der Abnahme und nicht beim nächsten Audit. Und dazu eine eigene Kategorie: Elemente, die der Ersteller der Seite nicht vollständig kontrolliert. Chat-Widgets, Karten, Buchungssysteme, Zahlungs-Gateways. Meist das schwächste Glied im gesamten Konversionspfad, deshalb prüfe ich bei Integrationen von APIs und externen Diensten die Barrierefreiheit des Anbieters vor der Auswahl und nicht nach der Umsetzung.
Kosten und Reihenfolge der Arbeiten: was das Budget treibt
Die Kosten verteilen sich auf vier Teile: Audit, Korrekturen in gemeinsam genutzten Komponenten, Korrekturen im Inhalt sowie Tests samt Regressionskontrolle. Die Verhältnisse dazwischen hängen vor allem davon ab, wie das Frontend gebaut ist. Die Zahl der Unterseiten spielt hier eine kleinere Rolle, als alle annehmen.
Das Budget treibt das Fehlen eines Komponentensystems, bei dem dieselbe Schaltfläche in mehreren Varianten existiert. Weiter: viele Template-Abwandlungen, ad hoc für Kampagnen gebaut, ein altes Theme mit Schichten überschriebener Stile, ungewöhnliche interaktive Elemente, von Grund auf geschrieben. Es senkt die umgekehrte Situation, denn eine Korrektur in der Komponente wirkt sich auf alle Ansichten aus, und architektonische Entscheidungen in der Entwurfsphase kosten ein Vielfaches weniger als eine Korrektur nach dem Launch. Aus demselben Grund kommt die Erstellung barrierefreier Websites mit Barrierefreiheit in den Anforderungen günstiger, als sie später zu ergänzen.
Es kommt auch vor, dass sich Korrekturen nicht mehr lohnen. Wenn das Theme nicht mehr unterstützt wird und jede Änderung das Layout an einer anderen Stelle umwirft, ist es vernünftiger, einen Umbau des Frontends zu planen und bei der Gelegenheit die Themen Leistung und Sicherheit mit abzuschließen.
Fazit: was zuerst zu tun ist
Die praktische Kurzfassung sieht so aus: ein Audit der wichtigsten Templates statt der gesamten Website, Korrekturen in Komponenten statt auf einzelnen Unterseiten, ein geordneter Prozess für die Veröffentlichung von Inhalten und eine Regressionskontrolle, die in die tägliche Arbeit des Teams eingebunden ist.
Halten Sie Ihre Erwartungen dabei realistisch. Barrierefreiheit verringert die Zahl der Barrieren und das rechtliche Risiko, ist aber kein einmal für immer ausgestelltes Zertifikat, sondern ein Zustand, der gemeinsam mit der Website gepflegt wird. Wenn Sie ein Audit, Korrekturen am Frontend, Integrationen oder die Modernisierung eines bestehenden Systems planen, schreiben Sie uns und lassen Sie uns den Umfang konkret durchgehen. Wenn Ihnen daran liegt, dass am Ende WCAG-konforme Websites stehen und nicht nur ein Bericht, beginnen wir mit der Durchsicht der wichtigsten Templates.
