Barrierefreiheit Ihrer Website verbessern: ein Leitfaden für die Praxis

Eine barrierefreie Website können Menschen unabhängig von einer Behinderung nutzen – und unabhängig davon, wie sie im Web unterwegs sind: mit einem Screenreader, ausschließlich per Tastatur, mit vergrößertem Text, mit eingeschränktem Farbsehen oder mit zitternden Händen. Dieselben Verbesserungen helfen auch Menschen mit gebrochenem Arm, mit einem kleinen Smartphone-Display in der prallen Sonne oder mit einer langsamen Verbindung.

Der gängige Maßstab sind die Web Content Accessibility Guidelines (WCAG), derzeit in Version 2.2. Viele Gesetze zur Barrierefreiheit und viele Beschaffungsrichtlinien verweisen auf die WCAG, meist auf Stufe AA. Dieser Leitfaden konzentriert sich auf die Korrekturen, die die häufigsten Barrieren beseitigen, und zeigt anschließend, wie Sie sie testen.

Erst automatisch prüfen, dann von Hand testen

Ein automatischer Scan ist der schnellste Weg, die offensichtlichen Probleme zu finden. Der kostenlose Accessibility-Checker von Rudra lädt Ihre Seite in einem echten Browser und führt axe-core aus, die weit verbreitete Open-Source-Test-Engine. Er listet jede nicht bestandene Regel auf, dazu die Zahl der betroffenen Elemente und die Schwere der Auswirkung: fehlende Alt-Texte, Formularfelder ohne Beschriftung, zu geringer Kontrast, eine fehlende Seitensprache, leere Buttons und Links und mehr.

Die wichtigsten Korrekturen

1. Bilder mit aussagekräftigen Textalternativen versehen

Jedes <img> braucht ein alt-Attribut. Beschreiben Sie bei informativen Bildern, was das Bild im Zusammenhang aussagt, nicht nur, was es zeigt: alt="Line chart: sign-ups doubled after the March redesign" ist hilfreicher als alt="chart". Rein dekorative Bilder erhalten ein leeres alt="", damit Screenreader sie überspringen. Ist ein Bild ein Link oder Button, beschreiben Sie die Aktion („Suchen“, „Bericht herunterladen“). Bei komplexen Diagrammen gehören die wichtigsten Daten zusätzlich in den umgebenden Text oder in eine Tabelle.

2. Jedes Formularfeld beschriften

Jedes Eingabefeld braucht eine sichtbare Beschriftung, die im Code mit ihm verknüpft ist: <label for="email">Email address</label>, gefolgt von <input id="email" type="email" autocomplete="email">. Ein Platzhaltertext ist keine Beschriftung – er verschwindet, sobald jemand tippt, und ist oft kontrastarm. Zeigen Sie Fehler als Text neben dem Feld an (nicht nur als roten Rahmen), erklären Sie, wie sie sich beheben lassen, und verknüpfen Sie sie per aria-describedby mit dem Feld.

3. Für ausreichenden Farbkontrast sorgen

• Normaler Text: ein Kontrastverhältnis von mindestens 4,5:1 zum Hintergrund (WCAG 1.4.3, Stufe AA).
• Großer Text (mindestens 24 px oder, wenn fett, etwa 18,7 px): mindestens 3:1.
• Bedienelemente und bedeutungstragende Grafiken wie Rahmen von Eingabefeldern, Fokusindikatoren und Icons mit eigener Aussage: mindestens 3:1 zu den angrenzenden Farben (WCAG 1.4.11).
• Verlassen Sie sich nicht allein auf Farbe (WCAG 1.4.1). Ein Link im Fließtext sollte sich durch mehr als seine Farbe abheben, in der Regel durch eine Unterstreichung, und ein Fehler sollte nicht nur in Rot gekennzeichnet sein.

Die Entwicklertools des Browsers zeigen das Kontrastverhältnis an, wenn Sie ein Textelement untersuchen. So können Sie Farben direkt bei der Arbeit prüfen und anpassen. Achten Sie besonders auf hellgrauen Text, Text auf Fotos und Platzhaltertexte.

4. Alles per Tastatur bedienbar machen

Alles, was mit der Maus geht, sollte auch mit Tab, Umschalt+Tab, Eingabetaste, Leertaste, den Pfeiltasten und Escape möglich sein. Verwenden Sie echte <button>- und <a href>-Elemente statt anklickbarer <div>-Elemente, die sich ohne zusätzlichen Aufwand weder fokussieren noch per Tastatur auslösen lassen. Entfernen Sie niemals den Fokusrahmen, ohne einen deutlich sichtbaren Ersatz zu bieten. Mit :focus-visible gestalten Sie ihn gezielt für Tastaturnutzer. Achten Sie darauf, dass ein fixierter Header oder ein Cookie-Banner das fokussierte Element nicht verdeckt (ein neues Kriterium der WCAG 2.2, 2.4.11) und dass Dialoge den Fokus halten, solange sie geöffnet sind, und ihn beim Schließen zurückgeben. Ergänzen Sie außerdem ganz oben auf der Seite einen Link „Zum Hauptinhalt springen“.

5. Seiten mit Überschriften und Landmarks gliedern

Wer einen Screenreader nutzt, navigiert häufig, indem er von Überschrift zu Überschrift springt. Verwenden Sie eine <h1>, die die Seite beschreibt, danach <h2> und <h3> in logischer Reihenfolge, und wählen Sie die Überschriftenebene nach der Struktur, nicht nach der Schriftgröße. Fassen Sie Bereiche in <header>, <nav>, <main> und <footer> ein, damit man direkt zum Inhalt springen kann.

6. Seitensprache und einen eindeutigen Titel festlegen

<html lang="en"> (bzw. Ihre Sprache) teilt Screenreadern mit, wie der Text auszusprechen ist. Ein eindeutiger, aussagekräftiger <title> ist das Erste, was beim Öffnen einer Seite vorgelesen wird, und an ihm erkennt man die Seite unter den Browser-Tabs.

7. Links und Buttons so benennen, dass sie für sich allein verständlich sind

Screenreader können alle Links einer Seite als Liste ausgeben. Zehnmal „Hier klicken“ und „Weiterlesen“ sagen dort nichts aus. Schreiben Sie stattdessen etwa „Preisübersicht lesen“. Buttons, die nur aus einem Icon bestehen, etwa einer Lupe oder einem „ד zum Schließen, brauchen einen zugänglichen Namen: <button aria-label="Close">.

8. Zielflächen groß genug gestalten

Mit den WCAG 2.2 kam eine Anforderung der Stufe AA hinzu (2.5.8): Zielflächen für Zeigereingaben müssen mindestens 24 × 24 CSS-Pixel groß sein oder so weit auseinanderliegen, dass sich ein 24-Pixel-Kreis um jede Fläche nicht mit einer anderen überschneidet. Größere Flächen von rund 44 × 44 Pixeln (die Empfehlung der Stufe AAA) sind auf Touchscreens noch besser.

9. Zoom und Umbruch unterstützen

Deaktivieren Sie den Zoom niemals mit user-scalable=no oder maximum-scale=1. Bei einer Breite von 320 CSS-Pixeln – das entspricht 400 % Zoom auf einem üblichen Desktop-Bildschirm – sollte der Inhalt einspaltig umbrechen, ohne dass horizontal gescrollt werden muss (WCAG 1.4.10). Ein responsives Layout bringt Sie schon weit. Mehr dazu unter Website für Mobilgeräte optimieren.

10. Sorgfältig mit Medien und Bewegung umgehen

Stellen Sie Untertitel für Videos und Transkripte für Audioinhalte bereit. Spielen Sie Ton nicht automatisch ab. Geben Sie Karussells und Animationen eine Pause-Schaltfläche und beachten Sie die Media Query prefers-reduced-motion: Reduzieren oder entfernen Sie verzichtbare Animationen für alle, die darum gebeten haben.

11. Natives HTML ARIA vorziehen

ARIA-Attribute ändern, was assistive Technologien ansagen, aber nicht, wie sich ein Element verhält. Ein <div role="button"> braucht weiterhin eine Tastatursteuerung, die Sie selbst schreiben müssen. Ein <button> bringt sie von Haus aus mit. Verwenden Sie, wo immer möglich, native Elemente und setzen Sie ARIA nur ein, wenn HTML kein Gegenstück bietet – nach den Mustern im ARIA Authoring Practices Guide des W3C.

Ein manueller Test in 15 Minuten

1. Ziehen Sie die Maus ab. Gehen Sie die Seite von oben mit der Tab-Taste durch. Sehen Sie bei jedem Schritt, wo der Fokus liegt? Erreichen und bedienen Sie jeden Link, jeden Button, jedes Menü und jedes Formularfeld? Lassen sich Pop-ups mit Escape schließen?
2. Zoomen Sie auf 200 %, dann auf 400 %. Bricht der Text um, oder müssen Sie seitwärts scrollen? Überlappt etwas, oder verschwindet etwas?
3. Probieren Sie ein paar Minuten lang einen Screenreader aus: NVDA (kostenlos, Windows), VoiceOver (in macOS und iOS integriert) oder TalkBack (Android). Lassen Sie sich die Überschriften und Links auflisten und füllen Sie ein Formular aus. Wird alles klar angesagt?
4. Prüfen Sie die Bilder. Lesen Sie die Alt-Texte (der Screenreader oder der Barrierefreiheitsinspektor Ihres Browsers zeigt sie an). Beschreiben sie, worauf es ankommt?
5. Betrachten Sie die Seite in Graustufen (die meisten Betriebssysteme bieten eine Farbfilter-Einstellung). Wird irgendeine Information nur über Farbe vermittelt?

Barrierefreiheit im Prozess verankern

• Beheben Sie Probleme zuerst in gemeinsam genutzten Komponenten und Templates. Eine korrigierte Header- oder Formularkomponente korrigiert jede Seite, die sie verwendet.
• Nehmen Sie automatische Prüfungen in Ihre Entwicklungspipeline auf, zum Beispiel axe-core in Ihren End-to-End-Tests, damit Rückschritte vor dem Release auffallen.
• Nehmen Sie Tastatur- und Kontrastprüfungen in Ihre Definition of Done für neue Funktionen auf.
• Veröffentlichen Sie eine Erklärung zur Barrierefreiheit mit einer Möglichkeit, Barrieren zu melden, und reagieren Sie auf das, was man Ihnen mitteilt.

Häufige Fehler

• Sich auf ein Overlay-Widget zu verlassen, das die Barrierefreiheit herstellen soll. Ein Skript, das über die Seite gelegt wird, kann das zugrunde liegende Markup nicht reparieren, und viele Nutzer mit Behinderung berichten, dass ihnen Overlays im Weg sind.
• Alt-Texte mit Keywords vollzustopfen oder mit „Bild von“ zu beginnen (Screenreader sagen ohnehin an, dass es sich um ein Bild handelt).
• Platzhaltertexte anstelle von Beschriftungen zu verwenden.
• Fokusrahmen aus ästhetischen Gründen zu entfernen.
• Überall aria-label zu ergänzen und damit mitunter einwandfreien sichtbaren Text zu überschreiben.
• Einen fehlerfreien automatischen Bericht als Beweis dafür zu werten, dass eine Website barrierefrei ist.