So wird eine Website barrierefrei — Die wichtigsten Maßnahmen

Im ersten Teil dieser Serie haben wir uns angesehen, warum digitale Barrierefreiheit wichtig ist — wirtschaftlich, rechtlich und gesellschaftlich. Jetzt geht es ans Eingemachte: Wie wird eine Website konkret barrierefrei? Welche Standards gelten? Welche Maßnahmen haben den größten Hebel? Und welche Tools helfen bei der Umsetzung?

WCAG: Der internationale Standard in drei Stufen

Die Web Content Accessibility Guidelines (WCAG) sind der international anerkannte Standard für barrierefreie Webinhalte. Sie werden vom W3C (World Wide Web Consortium) entwickelt und definieren Erfolgskriterien auf drei Konformitätsstufen:

Stufe A — Grundlegend

Mindestanforderungen. Ohne Stufe A ist eine Website für viele Menschen mit Behinderungen gar nicht nutzbar. Beispiele: Alternativtexte für Bilder, Tastaturzugänglichkeit, keine reinen Farbinformationen.

Stufe AA — Standard

Der empfohlene und gesetzlich geforderte Standard. Stufe AA deckt die häufigsten Barrieren ab: ausreichende Kontraste, skalierbare Texte, konsistente Navigation, Untertitel für Videos.

Stufe AAA — Erweitert

Höchste Konformitätsstufe. Umfasst erweiterte Anforderungen wie Gebärdensprache, vereinfachte Sprache, erweiterte Kontraste. Für die meisten Websites nicht vollständig erreichbar.

Technische und gestalterische Maßnahmen

Barrierefreiheit lässt sich in drei Handlungsfelder unterteilen: Texte und Inhalte, visuelles Design sowie technische Umsetzung. Die größten Hebel liegen oft in den Details.

Texte und Inhalte

Alternativtexte für Bilder: Jedes <img>-Element braucht ein alt-Attribut. Der Text sollte den Inhalt und Zweck des Bildes beschreiben — nicht das Bild selbst. Dekorative Bilder erhalten ein leeres alt="".
Untertitel und Transkripte: Videos brauchen synchronisierte Untertitel. Audioinhalte brauchen Transkripte. Das gilt nicht nur für Screenreader-Nutzer, sondern auch für die steigende Zahl von Menschen, die Videos ohne Ton konsumieren.
Klare Sprache: Kurze Sätze, aktive Formulierungen, Fachbegriffe nur wenn nötig und dann erklärt. Das hilft Menschen mit kognitiven Einschränkungen — und allen anderen.
Aussagekräftige Link-Texte: „Hier klicken” sagt nichts aus. „Zum Barrierefreiheitsbericht 2024” gibt Kontext. Screenreader-Nutzer navigieren häufig über eine Liste aller Links — jeder Link muss für sich verständlich sein.

Visuelles Design

Kontrastverhältnis: Normaler Text benötigt ein Kontrastverhältnis von mindestens 4,5:1 zum Hintergrund (WCAG AA). Großer Text (ab 18pt oder 14pt fett) benötigt mindestens 3:1. Tools wie der WebAIM Contrast Checker helfen bei der Überprüfung.
Schriftgrößen und Skalierbarkeit: Texte müssen sich auf mindestens 200 % vergrößern lassen, ohne dass Inhalte abgeschnitten werden oder sich überlappen. Relative Einheiten (rem, em) statt fester Pixelwerte sind der Schlüssel.
Nicht nur Farbe als Informationsträger: Fehlermeldungen dürfen nicht ausschließlich durch rote Farbe signalisiert werden. Ergänzende Icons, Texte oder Muster machen die Information auch für farbenblinde Menschen zugänglich.
Fokus-Indikatoren: Interaktive Elemente brauchen einen sichtbaren Fokus-Ring bei Tastaturnavigation. Der Standard-Browser-Fokus ist oft zu unauffällig — ein eigener, deutlich sichtbarer :focus-visible-Style ist empfehlenswert.

Technische Umsetzung

Semantisches HTML: <nav>, <main>, <article>, <aside>, <header>, <footer> — semantische Elemente geben der Seite Struktur, die Screenreader interpretieren können. Ein <div> mit onclick ist kein Button — ein <button> ist ein Button.
Korrekte Überschriftenhierarchie: <h1> bis <h6> in logischer Reihenfolge. Keine Ebenen überspringen. Screenreader-Nutzer navigieren häufig über die Überschriftenstruktur — eine saubere Hierarchie ist wie ein Inhaltsverzeichnis.
ARIA-Attribute: Wo semantisches HTML nicht ausreicht, helfen ARIA-Attribute (aria-label, aria-describedby, aria-live). Aber Vorsicht: Falsch eingesetztes ARIA ist schlimmer als gar kein ARIA. Die erste Regel von ARIA lautet: Benutze kein ARIA, wenn du es mit nativem HTML lösen kannst.
Formulare: Jedes Eingabefeld braucht ein zugeordnetes <label>. Fehlermeldungen müssen programmatisch verknüpft sein (aria-describedby). Pflichtfelder müssen als solche gekennzeichnet sein (aria-required="true" oder required).
Tastaturnavigation: Alle interaktiven Elemente müssen per Tastatur erreichbar und bedienbar sein. Die Tab-Reihenfolge muss der visuellen Reihenfolge entsprechen. Modale Dialoge müssen den Fokus einfangen (Focus Trap).

Praktische Tools

Die gute Nachricht: Barrierefreiheit lässt sich großteils automatisiert testen. Die schlechte Nachricht: Automatisierte Tools finden nur etwa 30-40 % aller Barrieren. Manuelles Testen bleibt unverzichtbar.

Google Lighthouse: In den Chrome DevTools integriert. Liefert einen Accessibility-Score und konkrete Verbesserungsvorschläge. Gut als erster Überblick, aber nicht tiefgehend genug für eine vollständige Prüfung.

WAVE (Web Accessibility Evaluation Tool): Browser-Extension von WebAIM. Visualisiert Barrieren direkt auf der Seite: fehlende Alt-Texte, Kontrastprobleme, strukturelle Fehler. Besonders hilfreich für Designer und Content-Verantwortliche.

axe DevTools: Browser-Extension von Deque Systems. Technisch tiefgehender als Lighthouse. Findet mehr Issues, erklärt die WCAG-Kriterien zu jedem Fund und zeigt den betroffenen DOM-Knoten. Die kostenlose Version deckt die meisten Anforderungen ab.

NVDA (Windows) und VoiceOver (macOS/iOS): Screenreader zum manuellen Testen. Es gibt keine bessere Methode, die tatsächliche Nutzererfahrung zu verstehen, als die eigene Website einmal komplett mit einem Screenreader zu bedienen. Die meisten Entwickler sind überrascht, wie anders sich ihre Seite „anfühlt”.

Roadmap: In vier Schritten zur barrierefreien Website

Schritt 1: Bestandsaufnahme

Beginnen Sie mit einer automatisierten Analyse Ihrer wichtigsten Seiten — Startseite, Produktseiten, Kontaktformular, Checkout. Nutzen Sie Lighthouse und WAVE für einen ersten Überblick. Dokumentieren Sie die gefundenen Barrieren und priorisieren Sie nach Schwere und Häufigkeit.

Schritt 2: Quick Wins umsetzen

Viele Barrieren lassen sich mit minimalem Aufwand beseitigen: fehlende Alt-Texte ergänzen, Kontraste anpassen, Link-Texte verbessern, Labels an Formularfelder binden. Diese Quick Wins verbessern den Accessibility-Score spürbar und bauen Momentum auf.

Schritt 3: Strukturelle Maßnahmen

Semantisches HTML einführen, Überschriftenhierarchie bereinigen, Tastaturnavigation sicherstellen, ARIA-Attribute korrekt einsetzen. Dieser Schritt erfordert Zusammenarbeit zwischen Entwicklung und Design und sollte in die regulären Sprint-Zyklen integriert werden.

Schritt 4: Manuelles Testing und kontinuierliche Verbesserung

Screenreader-Tests durchführen, idealerweise mit Betroffenen. Accessibility-Checks in die CI/CD-Pipeline integrieren (z.B. mit axe-core). Neue Features von Anfang an barrierefrei planen statt nachträglich anzupassen.

Praxisbeispiel: Online-Shop

Ein mittelständischer Online-Shop mit 50.000 monatlichen Besuchern führte eine systematische Barrierefreiheitsoptimierung durch. Die Maßnahmen: Kontrastanpassungen, semantisches HTML, Formulare mit Labels, Alternativtexte und Tastaturnavigation im Checkout.

Die Ergebnisse nach sechs Monaten:

Absprungrate: −18 % auf der Startseite
Conversion-Rate: +24 % im Checkout-Prozess
Lighthouse Accessibility Score: von 62 auf 94

Der entscheidende Faktor war nicht ein einzelner Fix, sondern die systematische Herangehensweise: Bestandsaufnahme, Priorisierung, iterative Umsetzung, kontinuierliches Messen.

Fazit

Barrierefreiheit ist kein einmaliges Projekt, sondern ein fortlaufender Prozess. Die WCAG-Richtlinien bieten einen klaren Rahmen, die verfügbaren Tools machen den Einstieg einfach, und die Roadmap gibt eine Struktur für die Umsetzung.

Der wichtigste Schritt ist der erste: die eigene Website mit den Augen eines Screenreader-Nutzers betrachten. Die Erkenntnisse, die daraus entstehen, sind oft der stärkste Antrieb für Veränderung.

Im dritten und letzten Teil dieser Serie betrachten wir Barrierefreiheit aus der strategischen Perspektive: Warum sie kein Kostenfaktor ist, sondern eine Investition — mit messbarem Return.