Seit dem Barrierefreiheitsstärkungsgesetz greift, hat sich der Ton in vielen Marketingabteilungen verändert. Eine barrierefreie Website war lange ein Punkt auf der Liste der guten Vorsätze, irgendwo zwischen Ladezeit-Optimierung und dem Relaunch, der immer nächstes Jahr kommt. Jetzt ist sie für einen großen Teil der Unternehmen eine gesetzliche Anforderung, und der Unterschied zwischen den beiden Zuständen ist größer, als es auf den ersten Blick wirkt.
Wen die Pflicht tatsächlich betrifft
Die häufigste Fehlannahme lautet, das Thema betreffe nur Behörden. Öffentliche Stellen sind seit Jahren gebunden, das stimmt, aber das BFSG erweitert den Kreis deutlich. Erfasst sind Dienstleistungen im elektronischen Geschäftsverkehr, also im Kern jeder Online-Shop, jedes Buchungssystem, jedes Kundenportal, mit dem Verbraucher Verträge schließen. Bankdienstleistungen, E-Books, Telekommunikation und Personenverkehr kommen hinzu.
Es gibt eine Ausnahme für Kleinstunternehmen mit weniger als zehn Beschäftigten und höchstens zwei Millionen Euro Jahresumsatz, allerdings gilt sie nur für Dienstleistungen, nicht für Produkte. Wer sich darauf verlassen möchte, sollte die eigenen Zahlen kennen und nicht schätzen. Und selbst dort, wo keine Pflicht besteht, bleibt das Argument bestehen: ein erheblicher Teil der Bevölkerung hat dauerhafte oder vorübergehende Einschränkungen, und ein Bestellprozess, den diese Menschen nicht abschließen können, kostet unmittelbar Umsatz.
Was digitale Barrierefreiheit konkret bedeutet
Der Maßstab in Deutschland ist die europäische Norm EN 301 549, die ihrerseits weitgehend auf den WCAG-Richtlinien des W3C aufsetzt. Vier Prinzipien tragen das gesamte Regelwerk: Inhalte müssen wahrnehmbar, bedienbar, verständlich und robust sein.
In der Praxis heißt das erstaunlich Handfestes. Jedes informative Bild braucht einen Alternativtext, der beschreibt, was zu sehen ist, und nicht bloß den Dateinamen wiederholt. Der Kontrast zwischen Text und Hintergrund muss ein Mindestverhältnis erreichen, was hellgraue Schrift auf weißem Grund praktisch ausschließt. Jede Funktion muss sich mit der Tastatur allein bedienen lassen, inklusive Menüs, Filtern und Modalfenstern. Formularfelder brauchen echte Labels, keine Platzhalter, die beim Tippen verschwinden. Und Videos brauchen Untertitel. Eine gute Einführung in die Hintergründe bietet der Überblick zum barrierefreien Internet.
Warum Overlay-Werkzeuge das Problem nicht lösen
Auf jeder zweiten Konferenz steht inzwischen ein Anbieter, der ein Skript verkauft: eine Zeile JavaScript einbinden, und die Seite sei konform. Das klingt verlockend und funktioniert nicht. Diese Werkzeuge können Kontraste anpassen oder Schrift vergrößern, sie können aber keine fehlende Semantik erfinden, keine sinnvollen Alternativtexte schreiben und keine kaputte Tastaturnavigation reparieren.
Schwerer wiegt, dass Nutzerinnen und Nutzer mit Screenreadern solche Overlays häufig als Störung erleben, weil sie mit der eigenen assistiven Technik kollidieren. Wer Barrierefreiheit ernst nimmt, arbeitet am Markup, nicht an einer Schicht darüber. Das ist mehr Aufwand, hält aber auch dem nächsten Redesign stand.
Der Zusammenhang mit Mehrsprachigkeit
Ein Aspekt geht in fast jeder Projektplanung unter: Barrierefreiheit und Übersetzung greifen ineinander. Ein Screenreader entscheidet anhand des lang-Attributs, mit welcher Aussprache er einen Abschnitt vorliest. Fehlt es oder steht es falsch, klingt ein deutscher Text in englischer Phonetik, und das Ergebnis ist für Betroffene unbrauchbar.
Dazu kommen die Details, die bei einer Übersetzung leicht verloren gehen. Alternativtexte, Formularfehlermeldungen, ARIA-Labels und Titel von Verlinkungen stehen selten im sichtbaren Text und landen deshalb oft gar nicht erst in der Exportdatei. Wer eine Website in mehreren Sprachen betreibt, sollte diese Felder ausdrücklich mit aufnehmen. Warum eine barrierefreie Website mehr verlangt als eine reine Übersetzung der sichtbaren Texte, ist an anderer Stelle ausführlich beschrieben, und dieselbe Logik gilt für professionelle Website-Übersetzungen für Online-Shops, bei denen jeder unübersetzte Hinweistext einen Kaufabbruch bedeuten kann.
Ein realistischer Weg zur Umsetzung
Ein vollständiger Umbau auf einmal scheitert meistens am Budget. Sinnvoller ist eine Reihenfolge nach Geschäftswert. Zuerst die Pfade, die Geld verdienen: Startseite, Produktseite, Warenkorb, Checkout, Kontaktformular. Diese fünf Ansichten decken den überwiegenden Teil der rechtlich relevanten Interaktion ab.
Dann eine ehrliche Bestandsaufnahme. Automatische Prüfwerkzeuge finden verlässlich etwa ein Drittel der Probleme, vor allem Kontraste, fehlende Labels und ungültiges Markup. Den Rest findet nur ein manueller Test: einmal die gesamte Bestellstrecke ausschließlich mit der Tastatur durchlaufen und einmal mit einem Screenreader. Das dauert einen Vormittag und ist aufschlussreicher als jeder Report.
Anschließend gehört das Thema in den Entwicklungsprozess statt in ein Einzelprojekt. Komponenten im Designsystem einmal barrierefrei bauen, Prüfregeln in die Pipeline aufnehmen, Redaktionsleitfäden für Alternativtexte schreiben. Sonst produziert das nächste Kampagnen-Template die alten Fehler wieder.
Was am Ende bleibt
Die Erfahrung aus abgeschlossenen Projekten ist ziemlich einheitlich. Der Aufwand liegt in der Nachrüstung, kaum in der Neuentwicklung. Wer von Anfang an sauber semantisches HTML schreibt, zahlt fast nichts drauf. Wer zehn Jahre lang div-Elemente als Schaltflächen verwendet hat, zahlt kräftig.
Und die Nebenwirkungen sind angenehm. Sauberes Markup verbessert die Auswertbarkeit für Suchmaschinen, klare Formulare senken Abbruchquoten, Untertitel erhöhen die Verweildauer bei Videos. Barrierefreiheit ist selten nur eine Pflichtübung. Sie ist meistens die Version der Website, die ohnehin die bessere gewesen wäre.
Dokumentation und Erklärung nicht vergessen
Ein Punkt wird regelmäßig übersehen, obwohl er ausdrücklich verlangt wird: die Barrierefreiheitserklärung. Anbieter müssen öffentlich darlegen, wie ihr Angebot die Anforderungen erfüllt, welche Teile noch nicht konform sind und über welchen Weg Nutzerinnen und Nutzer Probleme melden können. Diese Erklärung gehört gut auffindbar in den Footer, nicht versteckt in einem PDF.
Wer sie ernsthaft schreibt, profitiert doppelt. Erstens zwingt sie das Team zu einer konkreten Bestandsaufnahme statt zu einem vagen Gefühl. Zweitens ist sie im Zweifelsfall der Nachweis, dass ein Unternehmen sich mit dem Thema befasst hat und an bekannten Lücken arbeitet. Eine ehrliche Erklärung mit einem Zeitplan wirkt deutlich besser als eine pauschale Konformitätsbehauptung, die eine Prüfung nicht übersteht.
Sinnvoll ist außerdem ein fester Rhythmus. Ein jährlicher Kurztest der wichtigsten Strecken und ein Blick nach jedem größeren Release genügen meistens, um zu verhindern, dass mühsam erreichte Konformität still wieder verloren geht.
