Anforderungen der Barrierefreiheit sind Qualitätsmerkmale

Barrierefreiheit ist heute für viele Lebensbereiche standardisiert – rechtlich verankert und für zahlreiche Organisationen verpflichtend. Das gilt für den öffentlichen Raum, den Bau von Gebäuden, technische Geräte wie Aufzüge und genauso für digitale Produkte und Dienstleistungen.

Für Webseiten ergeben sich die rechtlichen Anforderungen aus der Europäischen Webseitenrichtlinie sowie dem European Accessibility Act (EAA). Sie schreiben die Konformität zu den im Amtsblatt der EU veröffentlichten Standards vor, insbesondere zur EN 301549. Kapitel 9 der EN 301549 verweist auf die Web Content Accessibility Guidelines (WCAG) 2.1, Konformitätsstufe AA. Wird diese Konformität erreicht, bedeutet dies, dass die meisten Menschen nicht von der Nutzung einer Webseite ausgeschlossen werden.

Hinweis: Die aktuelle Version der WCAG ist 2.2. Die aktualisierten Anforderungen werden in der EN 301549 eingearbeitet. Eine Aktualisierung der verbindlichen Vorgaben wird für Herbst 2027 erwartet. Die WCAG 2.2 ergänzt die WCAG 2.1 um neun neue Kriterien.

Die EN 301549 beschreibt in Anlage C, wie eine Konformitätsprüfung durchzuführen ist. Die WCAG-Erfolgskriterien sind als prüfbare Tests formuliert und müssen in klare qualitätssichernde Maßnahmen übersetzt werden.

Damit Barrierefreiheit tatsächlich im Produkt ankommt, muss die Überprüfung kontinuierlich während der Entwicklung erfolgen – nicht erst nach dem Go-Live. Dieses Prinzip wird in der Softwareentwicklung als Shift-Left bezeichnet. Bereits vor Beginn der Implementierung werden Tests definiert, automatisiert und regelmäßig ausgeführt. Viele solche Tests werden in einem weiteren Standard des W3C, im Accessibility Conformance Testing (ACT), beschrieben.

Kontinuierliches Testen bietet wesentliche Vorteile:

• Fehler werden kurzfristig entdeckt und können während der Entwicklung korrigiert werden.
• Es lässt sich eindeutig nachvollziehen, welcher Teil einer Komponente nicht funktioniert.
• Abhängige Module können sich auf robusten Code verlassen.
• Konzeptionelle Fehler werden früh identifiziert und sind leichter zu beheben.
• Tests entfallen nicht am Projektende aufgrund von Zeitdruck.
• Schnellkorrekturen werden vermieden.
• Release-Termine werden verlässlicher eingehalten.

Einige Aspekte des barrierefreien Webdesigns lassen sich auf dieser Weise technisch überprüfen. Für die tatsächliche Interaktion der Nutzenden müssen weitere Tests berücksichtigt werden.