Barrierefreiheit vor dem ersten Klick

Wer Barrierefreiheit als Checkliste versteht, kämpft dauerhaft gegen Einzelfehler. Wer sie als Systemfrage begreift, reduziert den Aufwand jedes Mal, wenn neue Inhalte hinzukommen.

In Barrierefreiheitsprojekten begegnet uns regelmäßig dieselbe Fehleinschätzung: Zugänglichkeit sei primär ein redaktionelles Problem. Dass es genüge, Texte verständlich zu schreiben, Bilder mit Alternativtexten zu versehen und Überschriften hierarchisch zu vergeben. Das stimmt, bis zu einem Punkt. Was Redakteurinnen und Redakteure im CMS eingeben, landet auf einer Plattform, die entweder für Barrierefreiheit gebaut ist oder eben nicht. Diese Plattform entscheidet mit, ob aus guten Absichten ein zugängliches Ergebnis wird.

WCAG 2.1 Level AA fordert ein Kontrastverhältnis von mindestens 4,5:1 für normalen Text und 3:1 für große Texte sowie für UI-Elemente wie Buttons oder Formularrahmen. Wer das erst beim finalen Abnahme-Review prüft, tut es zu spät.

Ein Design-System mit CSS Custom Properties kann Kontrastvorgaben verbindlich machen. Wenn --color-text-primary und --color-background-page als Farbpaar definiert und geprüft sind, ist ein Text in nicht-konformem Hellgrau auf Weiß schlicht nicht konfigurierbar. Diese Kombination existiert nicht im System. Freitext-Farbwähler im CMS öffnen die Tür für Kontrastverstöße, die niemand aktiv herbeiführt und die doch zuverlässig entstehen.

Ebenfalls im Design-System zu verankern: Farbe darf nie das einzige Unterscheidungsmerkmal sein. Eine rote Fehlermeldung ohne Icon oder ein grüner Erfolgsstatus ohne Textlabel ist für Menschen mit Farbfehlsichtigkeit nicht erkennbar. Wer Zustände und Hinweise im Komponentensystem konsequent mit Text oder Symbol kombiniert, löst das Problem einmal, statt es bei jeder Implementierung neu entstehen zu lassen.

Das gilt zunächst für den Light-Mode. Schwieriger wird es, wenn Dark-Mode und erhöhter Kontrast hinzukommen. Beides sollte man von Anfang an einplanen. prefers-color-scheme: dark ist in den meisten Design-Systemen inzwischen Standard. Anspruchsvoller ist prefers-contrast: more, die Einstellung für das macOS-Bedienungshilfen-Feature „Kontrast erhöhen“, sowie forced-colors: active unter Windows-Kontrastthemen.

Wer drei Token-Sets im Design-System verankert (Light, Dark, erhöhter Kontrast) und für jedes die WCAG-konformen Farbpaare verifiziert, schafft ein System, das unter allen Bedingungen trägt. Ein einziger geprüfter Kontrast mit der Hoffnung, der Rest ergibt sich, ist eine Annahme, die Audits regelmäßig widerlegen.

In dieselbe Kategorie gehört prefers-reduced-motion. Animationen, Parallax-Effekte und Scroll-Transitions können für Menschen mit vestibulären oder neurologischen Erkrankungen physisch belastend sein. Wer diese Abfrage im Design-System verankert, macht Bewegung zur bewussten Entscheidung: standardmäßig reduziert oder abschaltbar, nicht als Sonderlösung nachgerüstet.

Auch Schriftwahl ist eine Systementscheidung. Humanistische serifenlose Schriften mit offenen Zeichenformen sind zugänglicher als geometrische Groteskschriften: Typische Verwechslungen wie 1, I und l oder O und 0 entstehen dort seltener. Ist die Hausschrift einmal im Design-System verankert, gilt das für alle Anwendungen automatisch.

HTML-Semantik folgt der Plattform. Wer das Template richtig aufbaut, muss der Redaktion diese Frage nie stellen. Wenn ein CMS-Block automatisch ein <article> mit <h2> erzeugt, ist die Strukturierung eine Konsequenz des Blocktyps, unabhängig davon, wer gerade am Inhalt arbeitet. Wenn hingegen alle Überschriften in einem Freitext-WYSIWYG-Feld per Hand formatiert werden können, entstehen Inkonsistenzen. Der Grund ist meistens der normale Arbeitsalltag, nicht fehlende Kompetenz.

Dasselbe gilt für Landmark-Regionen. <main>, <nav>, <header>, <footer> helfen Screenreader-Nutzenden, Seiteninhalte schnell zu navigieren. Templates, die diese Struktur erzwingen, machen sie verlässlich.

Dieselbe Grundlage ist auch für KI-Systeme relevant: Sie nutzen semantische Auszeichnung, um Inhalte einzuordnen und Bedeutung zu verstehen. Was das für digitale Sichtbarkeit bedeutet, beschreibt unser Artikel „Die stille Zielgruppe: Wenn KI beginnt, Websites zu lesen".

Buttons aus <div>-Elementen, die per CSS nach Schaltflächen aussehen. Modale Dialoge ohne Fokus-Management. Navigationsmenüs, die sich öffnen, aber nicht per Tab schließen lassen. Alle drei haben ihre Ursache in der Implementierung interaktiver Komponenten. In der Redaktion gibt es dafür keinen Hebel.

Der schnellste Barrierefreiheitstest braucht keine Werkzeuge: Maus weglegen, Seite per Tastatur bedienen. Was dabei schiefläuft, zeigt typischerweise, dass Navigationen, Akkordeons, Filterlisten oder Slider ohne Keyboard-Support implementiert wurden. Das ist eine Architekturfrage. Wie sich solche Lücken zusätzlich automatisiert aufdecken lassen, beschreibt unser Snippet zu Playwright-Accessibility-Tests.

Kontaktformulare, Anmeldeseiten, Buchungsstrecken: Formulare zählen zu den wichtigsten Zugängen zu einem digitalen Angebot und gleichzeitig zu den häufigsten Barrierefreiheitslücken. Typische Probleme: Fehlermeldungen, die nur visuell erscheinen und für Screenreader unsichtbar bleiben. Pflichtfelder, die ausschließlich durch Farbe markiert sind. Eingabefelder ohne zugehörige Labels.

Ein Formular-Komponentensystem, das ARIA-Live-Regions für Fehlermeldungen, maschinenlesbare Labels, klar strukturierte Pflichtfeldhinweise und Fokus-Management bei Validierungsfehlern als Standard mitbringt, verhindert, dass technisch einwandfrei aussehende Formulare für Teile der Nutzenden schlicht nicht funktionieren. Welche Nutzungspfade das BFSG dabei besonders im Blick hat, haben wir in einem eigenen Beitrag aufgeschlüsselt.

Redaktionelle Sorgfalt bleibt unersetzlich. Als Pflichtfeld im CMS lassen sich Alternativtexte technisch erzwingen, aber nicht inhaltlich automatisieren. Dabei hilft eine Unterscheidung, die sich auch im CMS abbilden lässt: Dekorative Bilder, also rein visuelle Elemente ohne Informationsgehalt, sollten mit leerem alt="" ausgezeichnet sein, damit Screenreader sie übergehen. Informative Bilder brauchen einen Text, der ihre Bedeutung erklärt, nicht ihre Optik beschreibt. Ein Pflichtfeld, in das jemand „Bild" einträgt, erfüllt formal eine Anforderung und verfehlt jeden Sinn.

Gleiches gilt für Linklabels. „Hier klicken" ist ein Textlink. Für jemanden, der Links per Screenreader überfliegt, ist es eine Orientierungskatastrophe. Ob aus „Weitere Informationen" ein konkretes „Zur Geschäftsstelle in Berlin" wird: das ist Redaktionsarbeit.

Die sinnvolle Aufgabenteilung: Was das System zuverlässig regeln kann, soll das System regeln. Was inhaltliches Urteil erfordert, braucht Schulung und Bewusstsein. Wer Barrierefreiheit ausschließlich als Redaktionsaufgabe oder ausschließlich als Entwicklungsaufgabe behandelt, erzeugt zuverlässig Lücken auf der jeweils anderen Seite.

Ein Aspekt, der in Barrierefreiheitsdiskussionen selten vorkommt: aktive Audio-Ausgabe. Moderne CMS-Plattformen können Artikel auf Wunsch vorlesen. Die Sprachausgabe wird durch KI automatisch aus dem vorhandenen Textinhalt erzeugt und senkt Barrieren für Menschen mit Leseschwäche oder Sehbeeinträchtigungen. Nebenbei trifft sie eine weitere Nutzungsrealität: den langen Fachtext, den jemand während der Fahrt konsumieren will.

Screenreader und TTS-Funktion haben unterschiedliche Stärken. Ersterer navigiert nach Semantik und Dokumentstruktur, letztere liest den Textfluss linear durch. Der Vorteil einer plattformseitigen Vorlese-Funktion: kein redaktioneller Mehraufwand pro Artikel. Die Zugänglichkeitserweiterung entsteht einmal auf Systemebene.

Ein barrierefreies System erzeugt nicht automatisch barrierefreie Inhalte. Es reduziert aber systematisch die Fehlerquellen, die aus dem laufenden Betrieb entstehen. Wer eine Plattform aufbaut, die semantisch korrekte Markup-Strukturen, geprüfte Kontraste für alle Farbmodi, tastaturzugängliche Komponenten und Pflichtfelder für kritische Alternativtexte als Standard mitliefert, schafft eine Grundlage, auf der gute redaktionelle Arbeit ihre volle Wirkung entfalten kann.

Wer das erreichen will, trifft Infrastrukturentscheidungen.

Die Barrierefreiheitserklärung_, die viele Organisationen heute als Pflicht empfinden, ist übrigens im besten Fall das Gegenteil davon: ein ehrliches Dokument über das, was man entwickelt hat, was noch fehlt und warum.