WCAG-Sanierung: Unternehmensbeispiel aus der Praxis
Eine Website kann modern aussehen, schnell laden und dennoch für einen Teil ihrer Nutzerinnen und Nutzer kaum bedienbar sein. Das folgende Unternehmensbeispiel für eine WCAG-Sanierung zeigt, wie sich Barrieren in einem gewachsenen Webauftritt strukturiert abbauen lassen - ohne die Plattform pauschal neu aufzubauen oder den laufenden Betrieb unnötig zu gefährden.
Ausgangslage ist ein mittelständisches B2B-Unternehmen mit einer umfangreichen TYPO3-Website. Über Jahre sind neue Landingpages, Produktbereiche, Formulare, Downloads und Kampagnen hinzugekommen. Das Design ist uneinheitlich gewachsen, einige Templates stammen aus älteren Entwicklungsphasen. Für das Marketing ist die Website ein zentraler Vertriebskanal, für Bewerberinnen und Bewerber ein wichtiger Kontaktpunkt.
Die Geschäftsleitung wollte die Zugänglichkeit verbessern, rechtliche Risiken bewerten und Barrierefreiheit dauerhaft in die Weiterentwicklung integrieren. Der entscheidende Punkt: Es sollte keine einmalige Korrekturrunde werden, sondern eine belastbare technische und redaktionelle Grundlage.
WCAG-Sanierung im Unternehmensbeispiel: Der reale Befund
Zu Beginn stand kein pauschales Urteil wie „die Website ist nicht barrierefrei“, sondern ein Audit mit klarer Fragestellung: Welche Seiten, Funktionen und Inhalte sind für zentrale Nutzungsszenarien relevant, welche WCAG-Kriterien sind betroffen und wo liegen die Ursachen?
Automatisierte Tests waren dabei ein sinnvoller Start, aber keine ausreichende Prüfung. Sie finden zum Beispiel fehlende Alternativtexte, formale Fehler in Überschriftenstrukturen oder Kontrastauffälligkeiten. Ob eine Navigation mit der Tastatur verständlich erreichbar ist, ein Formular nachvollziehbare Fehlermeldungen liefert oder ein Dialog den Fokus korrekt führt, lässt sich nur manuell bewerten. Deshalb wurden repräsentative Seitentypen geprüft: Startseite, Übersichtsseite, Produktdetail, Karrierebereich, Kontaktformular, Suche und Downloadbereich.
Der Befund war typisch für gewachsene CMS-Projekte. Es gab nicht einen einzelnen großen Defekt, sondern viele wiederkehrende Muster. Buttons hatten in einzelnen Teasern zu geringe Kontraste. Der sichtbare Tastaturfokus war durch CSS-Definitionen entfernt worden. Redakteure nutzten Überschriften teilweise zur optischen Hervorhebung und übersprangen dabei Ebenen. Formulare meldeten Fehler nur farblich, und einige eingebundene Inhalte von Drittanbietern waren mit der Tastatur nicht vollständig bedienbar.
Auch PDF-Dokumente spielten eine Rolle. Sie waren für viele fachliche Informationen weiterhin notwendig, besaßen aber teils keine getaggte Struktur, keine sinnvolle Lesereihenfolge und keine aussagekräftigen Dokumenttitel. Eine WCAG-Sanierung betrifft daher nicht nur Frontend-Code. Sie betrifft Templates, Komponenten, Inhalte, Dokumente und die Arbeitsabläufe hinter dem CMS.
Priorisieren statt alles gleichzeitig reparieren
Nicht jede Auffälligkeit hat die gleiche Wirkung. Im Beispiel wurden die Maßnahmen nach Nutzungsrelevanz, Schwere der Barriere, Reichweite und Umsetzungsaufwand priorisiert. Ein nicht erreichbarer Absende-Button im Kontaktformular war dringender als eine kleinere strukturelle Unsauberkeit auf einer selten besuchten Archivseite.
In der ersten Umsetzungsphase standen deshalb die Kernpfade im Mittelpunkt: Navigation, Suche, Kontaktaufnahme, Produktanfrage und Bewerbung. Das Team stellte eine durchgängige Tastaturbedienung her, ergänzte sichtbare Fokuszustände und überarbeitete die semantische Struktur der Templates. Fehlermeldungen in Formularen wurden so angepasst, dass sie programmatisch mit den betroffenen Feldern verknüpft und auch ohne Farbe verständlich waren.
Parallel wurden Kontraste nicht nur punktuell nachgebessert. Die Farbwerte des Designsystems wurden überprüft und für Text, Buttons, Statusmeldungen und interaktive Zustände verbindlich definiert. Das spart später Aufwand: Wenn eine Komponente korrekt angelegt ist, profitieren alle Seiten, die sie verwenden.
Dieser Ansatz ist besonders bei TYPO3 sinnvoll. Wiederverwendbare Content-Elemente und Fluid-Templates lassen sich zentral verbessern. Ein individuell gepflegter Sonderfall auf einer einzelnen Landingpage bleibt dagegen ein Risiko. Wo sich ähnliche Komponenten mehrfach unterschieden, wurden sie konsolidiert. Das reduzierte nicht nur Barrieren, sondern auch Pflegeaufwand und Fehleranfälligkeit.
Was technisch geändert wurde
Die Navigation erhielt eine saubere Landmark-Struktur, aussagekräftige Beschriftungen und ein nachvollziehbares Verhalten für Untermenüs. Interaktive Elemente wurden dort, wo es möglich war, als native HTML-Elemente umgesetzt. Das ist meist verlässlicher als selbst nachgebildete Bedienelemente mit zusätzlichen ARIA-Attributen.
Bei Bildern wurde differenziert: Informationshaltige Bilder bekamen passende Alternativtexte, dekorative Elemente wurden für Screenreader ausgeblendet. Diese Unterscheidung klingt einfach, erfordert aber fachlichen Kontext. Ein Produktfoto kann auf einer Übersichtsseite dekorativ sein und auf einer Detailseite relevante Information vermitteln.
Modale Fenster, Cookie-Einstellungen und Filteroberflächen wurden ebenfalls überarbeitet. Hier entstehen häufig Probleme mit Fokusführung, Escape-Taste und der Rückkehr zum auslösenden Element. Solche Details entscheiden darüber, ob eine Oberfläche mit Tastatur oder Screenreader praktisch nutzbar ist.
Für eingebundene Drittanbieter-Lösungen wurde keine technische Beschönigung vorgenommen. Wenn ein externes Bewerbungsformular oder Karten-Widget nicht ausreichend zugänglich war, wurde geprüft, ob sich die Einbindung konfigurieren, ersetzen oder durch eine gleichwertige Alternative ergänzen lässt. Nicht jede Barriere kann im eigenen Quellcode behoben werden. Sie muss aber sichtbar bewertet und in der Entscheidung dokumentiert werden.
Redaktion und Entwicklung arbeiten an derselben Qualität
Nach der technischen Sanierung wäre das Projekt ohne redaktionelle Leitplanken schnell wieder uneinheitlich geworden. Deshalb wurden die wichtigsten Regeln direkt im CMS und im Arbeitsprozess verankert. Redakteurinnen und Redakteure erhielten klare Hinweise für Überschriften, Linktexte, Alternativtexte, Tabellen und Downloads. Wo möglich, wurden problematische Eingaben technisch eingeschränkt oder sinnvoll vorbelegt.
Ein Beispiel sind Linktexte. „Mehr erfahren“ ist nicht grundsätzlich falsch, aber in einer Screenreader-Linkliste oft wenig aussagekräftig. Die Redaktion nutzt nun kontextbezogene Formulierungen wie „Details zum Produktservice“ oder „Karriereprofil im Vertrieb“. Das verbessert zugleich die Orientierung für alle Besucher.
Bei PDFs fiel die Entscheidung differenziert aus. Häufig genutzte Informationsblätter wurden barrierefrei überarbeitet oder als HTML-Seite bereitgestellt. Selten benötigte historische Dokumente wurden nicht blind nachbearbeitet, sondern mit einer zugänglichen Kontaktmöglichkeit und einem klaren Plan für Ersatzinhalte versehen. Welche Lösung angemessen ist, hängt von Zweck, Nutzung und rechtlicher Einordnung ab.
Prüfung nach der Umsetzung: Nicht nur ein Häkchen setzen
Nach jeder größeren Korrektur wurden die betroffenen Prozesse erneut getestet. Dazu gehörten Tastaturtests, Screenreader-Prüfungen und Tests bei unterschiedlichen Zoomstufen sowie auf mobilen Geräten. Besonders wertvoll war die Prüfung kompletter Aufgaben: Kann jemand ein Produkt finden, eine Anfrage absenden und die Fehlermeldung verstehen, ohne eine Maus zu verwenden? Kann eine Bewerberin ein Stellenangebot aufrufen und den Bewerbungsweg nachvollziehen?
Automatisierte Prüfungen blieben Teil der Qualitätssicherung, aber als Ergänzung. Sie eignen sich gut für wiederkehrende Kontrollen in der Entwicklung, etwa bei neuen Templates oder Komponenten. Sie ersetzen jedoch nicht die fachliche Bewertung von Reihenfolge, Verständlichkeit und Bedienlogik.
Im Projekt entstand außerdem eine nachvollziehbare Dokumentation: geprüfte Bereiche, festgestellte Abweichungen, Prioritäten, umgesetzte Maßnahmen und bekannte Einschränkungen. Das schafft Transparenz für Fachabteilungen, Management und externe Prüfungen. Vor allem verhindert es, dass Entscheidungen Monate später nicht mehr erklärbar sind.
Barrierefreiheit als Teil der Weiterentwicklung
Die größte Veränderung lag nicht in einzelnen CSS-Anpassungen, sondern im Prozess. Neue Anforderungen werden seitdem gegen definierte Akzeptanzkriterien geprüft. Bei Designentscheidungen gehören Kontrast, Fokuszustände und verständliche Interaktionen früh auf die Agenda. Bei neuen Content-Elementen wird vor der Freigabe geklärt, wie sie semantisch funktionieren und welche Redaktionseingaben nötig sind.
Für Unternehmen, die unter die Anforderungen des Barrierefreiheitsstärkungsgesetzes fallen, ist diese Arbeitsweise besonders relevant. Doch auch wenn eine konkrete gesetzliche Pflicht im Einzelfall nicht greift, lohnt sich der Ansatz. Barrierearme Websites sind häufig klarer strukturiert, besser bedienbar, wartungsfreundlicher und in vielen Punkten suchmaschinenfreundlich. Die Anforderungen müssen allerdings passend zum Angebot, zur Zielgruppe und zum technischen Bestand bewertet werden.
Eine WCAG-Sanierung ist damit kein kosmetisches Projekt vor einem Stichtag. Sie ist eine Entscheidung für Webentwicklung mit Substanz: Probleme werden an ihrer Ursache gelöst, wiederverwendbare Komponenten werden besser, und die Website bleibt auch bei neuen Inhalten und Funktionen kontrollierbar. Wer mit einem klar abgegrenzten Audit beginnt und daraus einen realistischen Maßnahmenplan macht, schafft die Grundlage für spürbare Verbesserungen - für Nutzer, Redaktion und die langfristige Qualität der Plattform.
