c't 14/2022
S. 136
Wissen
Web-Accessibility
Bild: Rudolf A. Blaha

Web ohne Hürden

Websites barrierearm gestalten, 1. Teil

Beim Abbau von Barrieren im Web geht zwar vielleicht manche Design-Finesse über Bord, aber klare Optik und robuste Bedienbarkeit kommen allen Website-Besuchern zugute. Dieser erste Teil unseres Praxisleitfadens zeigt, wie Sie die Inhalte für Sehende, Sehschwache, Blinde und Gehörlose gleichermaßen optimieren.

Von Herbert Braun

Beim Thema Barrierefreiheit denken viele zunächst an Blinde oder Sehbehinderte, die eine vergleichsweise kleine Gruppe der Website-Besucher stellen. Tatsächlich hilft Barrierefreiheit Menschen mit einer Vielzahl von Einschränkungen. Blinde wollen sich Inhalte vorlesen lassen, stark Fehlsichtige hingegen müssen Inhalte vergrößern und benötigen lesbare Schrift und hohe Kontraste. Farbenblinde können farbliche Hervorhebungen oft nicht wahrnehmen. Videos sind zudem nicht nur für visuell Eingeschränkte, sondern auch für Gehörlose ein Problem.

Die Steuerung der Maus ist für manche körperlich Beeinträchtigten wiederum schwierig; sie brauchen große Schaltflächen und alternativ eine brauchbare Tastatursteuerung. Menschen mit kognitiven Schwierigkeiten verlangen Übersichtlichkeit, wenig Ablenkung durch zappelnde Animationen und manchmal auch Texte in einfacher Sprache.

Auch wer sich die Hand gebrochen hat, ein Baby auf dem Arm trägt oder an einem sonnigen Tag aufs Handy schaut, wird die Vorzüge einer barrierearmen Website zu schätzen lernen. Barrierefreiheit lässt sich auch so übersetzen: Die Website muss für alle Nutzer unter allen Umständen bestmöglich funktionieren.

Vorschriften

Falls Sie das alles nicht überzeugt: Gesetzliche Bestimmungen erfordern für einige Websites, dass sie barrierefrei sein müssen. Im Augenblick gilt die Verpflichtung nur für Bundesbehörden, wird aber bald auch einige Unternehmen treffen. Verankert ist diese Pflicht in der „Barrierefreie Informationstechnik-Verordnung“ (BITV). Diese gibt es schon fast 20 Jahre, aber die Neuauflage von 2019 passt auf moderne Websites wesentlich besser. Relativ neu ist das Testverfahren, das die Kompatibilität zur neuen BITV in 92 Einzeltests prüft.

Die BITV und ihre Geschwister in anderen EU-Ländern lehnen sich eng an die „Web Content Accessibility Guidelines“ (WCAG 2.0) an. Herausgegeben hat diese die Web-Standardisierungsorganisation W3C, genauer gesagt dessen Arbeitsgruppe „Web Accessibility Initiative“ (WAI).

Die Anforderungen der WCAG 2.0 auf vier Punkte zusammengedampft: Wahrnehmbar, bedienbar, verständlich und robust muss eine Website sein. Was das im Detail bedeutet und welche Kriterien für die Barrierefreiheits-Level A, AA und AAA (die höchste Stufe) erfüllt sein müssen, erklärt das Dokument auf verständliche Weise, wenn man sich ein Stündchen Zeit dafür nimmt. Unter ct.de/yjp2 haben wir die deutsche Übersetzung verlinkt – auch Sprache kann eine Barriere sein.

Genügt der Kontrast zwischen Text und Hintergrund einer Webseite den WCAG-Richtlinien? contrastchecker.com prüft es.
Genügt der Kontrast zwischen Text und Hintergrund einer Webseite den WCAG-Richtlinien? contrastchecker.com prüft es.

Level 1: Wahrnehmbar

Dass Benutzer Inhalte überhaupt wahrnehmen können, ist die Grundlage aller Bemühungen um Barrierefreiheit – und das bedeutet vor allem, Textalternativen für audiovisuelle Inhalte anzubieten. Sorgen Sie also dafür, dass jedes <img> sein alt-Attribut bekommt. Wenn es keinen sinnvollen Alternativtext gibt, weil das Bild rein dekorative Zwecke erfüllt, setzen Sie keinen Wert dafür ein:

<img src="..." alt="">

Zu entscheiden, ob ein Bild wichtige Information enthält oder nicht, ist mitunter knifflig – ebenso wie die Frage, was einen guten Alternativtext ausmacht. Ein häufiges Missverständnis: Textalternativen sind nicht nur für Screenreader-Nutzer da, sondern auch für Menschen mit eingeschränkten visuellen oder kognitiven Fähigkeiten. Das bedeutet, dass der Alternativtext gut lesbar für den Fall sein muss, dass der Benutzer die Bildanzeige im Browser deaktiviert. Testen können Sie das etwa mit der Browser-Erweiterung „Web Developer“ (siehe Kasten „Werkzeuge“).

Kommentare lesen (1 Beitrag)