Barrierefreies Webdesign: was sehbehinderte Nutzer wirklich brauchen

Wie Menschen mit Sehbehinderung das Web nutzen

• Mit Vergrößerung: Browser-Zoom bis 200 oder 400 Prozent, Bildschirmlupen, eigene Farbschemata. Sie sehen immer nur einen Ausschnitt der Seite.
• Mit Screenreader: Die Seite wird vorgelesen oder auf der Braillezeile ausgegeben. Navigiert wird über Überschriften, Landmarken, Links und Formularfelder – nicht linear von oben nach unten.
• Mit Kontrast- und Farbanpassungen: Hochkontrast-Modus, Dunkelmodus, eigene Schriftarten.

Eine gute Website funktioniert mit all diesen Techniken, ohne dass Informationen verloren gehen.

Semantisches HTML zuerst

• Eine sinnvolle Überschriftenhierarchie: genau eine h1, darunter h2 und h3 ohne Sprünge.
• Landmarken mit header, nav, main und footer, dazu ein Link „Zum Inhalt springen“.
• Echte button- und a-Elemente statt anklickbarer divs.
• Listen als Listen, Tabellen nur für tabellarische Daten – mit Kopfzellen (th).
• Die Sprache der Seite festlegen (lang="de"), damit die Sprachausgabe richtig ausspricht.

ARIA-Attribute sind ein Werkzeug für Fälle, die HTML nicht abdeckt. Falsch eingesetzt, verschlechtern sie die Zugänglichkeit. Grundregel: erst natives HTML, dann ARIA.

Kontraste und Farben

• Normaler Text braucht mindestens ein Kontrastverhältnis von 4,5:1, großer Text 3:1. Bedienelemente und Grafiken, die zum Verständnis nötig sind, ebenfalls mindestens 3:1.
• Informationen nie nur über Farbe vermitteln – Fehler in Formularen zusätzlich mit Text und Symbol kennzeichnen.
• Hellgraue Schrift auf weißem Grund und Text über unruhigen Bildern vermeiden.
• Einen Dunkelmodus anbieten oder die Systemeinstellung respektieren.

Zoom und Umbruch

• Die Seite muss bei 400 Prozent Zoom – entsprechend 320 CSS-Pixeln Breite – ohne waagerechtes Scrollen lesbar bleiben.
• Schriftgrößen in relativen Einheiten (rem) angeben und Zoomen auf Mobilgeräten nicht sperren.
• Nutzereinstellungen für Zeilen-, Wort- und Buchstabenabstand dürfen das Layout nicht zerbrechen.
• Eine gut lesbare Grundschrift von mindestens 16, besser 18 Pixeln und eine Zeilenlänge von höchstens etwa 70 Zeichen helfen allen.

Tastatur und Fokus

• Alle Funktionen müssen per Tastatur erreichbar sein, in logischer Reihenfolge.
• Der Fokus muss deutlich sichtbar sein – ein kräftiger Rahmen mit hohem Kontrast. WCAG 2.2 verlangt zudem, dass der fokussierte Bereich nicht vollständig von anderen Elementen wie festen Kopfzeilen verdeckt wird.
• Dialoge und Menüs: Fokus beim Öffnen hineinsetzen, mit Escape schließbar machen, Fokus danach zurückgeben.

Formulare

• Jedes Feld braucht ein sichtbares, programmatisch verknüpftes Label – Platzhaltertext allein genügt nicht.
• Fehlermeldungen konkret formulieren („Bitte geben Sie eine E-Mail-Adresse ein“) und so ausgeben, dass Screenreader sie ansagen.
• Autovervollständigung (autocomplete) für Name, E-Mail und Adresse erleichtert die Eingabe.
• Captchas, die nur visuell lösbar sind, schließen blinde Menschen aus.

Bilder, Videos und Dokumente

• Informative Bilder brauchen einen Alternativtext, der die Aussage des Bildes wiedergibt; dekorative Bilder ein leeres alt="".
• Diagramme zusätzlich als Text oder Tabelle anbieten.
• Videos mit Untertiteln und – wenn das Bild wichtige Informationen enthält – mit Audiodeskription.
• PDFs barrierefrei erstellen (mit Tags, Lesereihenfolge und Überschriften) oder die Inhalte zusätzlich als HTML anbieten.

Testen

1. Automatisch: Werkzeuge wie axe, WAVE oder die Lighthouse-Prüfung im Browser finden viele technische Fehler – aber nur einen Teil aller Probleme.
2. Tastatur: Die ganze Seite einmal nur mit Tab, Umschalt+Tab, Eingabe und Leertaste bedienen.
3. Zoom: Auf 200 und 400 Prozent vergrößern und prüfen, ob alles lesbar bleibt.
4. Screenreader: Mit NVDA (kostenlos) oder VoiceOver die wichtigsten Abläufe durchspielen, etwa Suche, Kontakt und Kauf.
5. Mit Betroffenen: Nichts ersetzt Tests mit Menschen, die täglich mit Screenreader oder Vergrößerung arbeiten.