Praktische Barrierefreiheit in der Webentwicklung

Mit pragmatischen Tipps und Tricks lässt sich Barrierefreiheit in die tägliche Entwicklung integrieren – um so den Sprung vom Tooling zum Mindset zu schaffen.

In Pocket speichern vorlesen Druckansicht 15 Kommentare lesen
Lesezeit: 21 Min.
Von
  • Maria Korneeva
Inhaltsverzeichnis

(This article is also available in English.)

Im Juli 2021 trat in Deutschland das Barrierefreiheitsstärkungsgesetz (BFSG) in Kraft, das den European Accessibility Act (EAA) umsetzt. Das BFSG definiert Anforderungen an die Barrierefreiheit von Produkten und Dienstleistungen, die nach dem 28. Juni 2025 auf den europäischen Markt kommen oder den Verbrauchern angeboten werden. Dazu gehören unter anderem der gesamte E-Commerce-Bereich, Hard- und Software, aber auch der nationale Personenverkehr oder Bankdienstleistungen. Das Gesetz betrifft demnach auch Webentwicklerinnen und Webentwickler, die Anwendungen für den Privatsektor implementieren. Auf ihrem Weg zu barrierefreien Anwendungen können sie auf eine Vielzahl unterstützender Tools und Techniken zurückgreifen.

Der European Accessibility Act ist nicht nur ein wichtiger und notwendiger Schritt, um das Internet für alle zugänglicher zu machen, sondern kann auch eine ernsthafte Gefahr darstellen, wenn er nicht eingehalten wird. Wenn ein Produkt oder eine Dienstleistung die Anforderungen an die Barrierefreiheit nicht erfüllt, können die deutschen Marktüberwachungsbehörden einen Rückruf oder die Einstellung anordnen. Darüber hinaus drohen Bußgelder von bis zu 100.000 Euro. Ausnahmen gelten nur für kleine Unternehmen mit weniger als zehn Beschäftigten, einem Jahresumsatz von weniger als zwei Millionen Euro oder einer Jahresbilanzsumme von weniger als zwei Millionen Euro.

Der Stand der Web-Accessibility und der IT-Projekte kurz vor 2025 wird voraussichtlich wie folgt aussehen:

  • Viele IT-Projekte laufen bereits oder stehen kurz vor ihrem Beginn, ohne dass ein spezielles Budget für Barrierefreiheit zur Verfügung steht. Das bedeutet, dass die Inklusivität des Produkts mit geringen Kosten erreicht werden soll – in Bezug auf Geld und geistigen Aufwand.
  • Teams verfügen noch nicht über das nötige Accessibility-Know-how. Idealerweise sollte das Tooling daher auch Anfängern eine Anleitung bieten.

Accessibility sollte eine regelmäßige Praxis sein, keine Einmalaktion. "Man führt sie einmal ein, und dann ist man barrierefrei" ist ein Mythos. Das bedeutet, dass Entwicklerinnen und Entwickler sich regelmäßig darum kümmern sollten, sowohl bei der Arbeit an neuen Features als auch bei der Wartung bestehender Features. Es gibt zwar verschiedene Accessibility-Checklisten, aber Selbstaudits funktionieren kaum dauerhaft, wenn sie nicht automatisiert oder gut in den Entwicklungsprozess integriert sind.

Darüber hinaus ist es derzeit eine unrealistische Erwartung, eine Website zu hundert Prozent barrierefrei zu gestalten. Web-Accessibility ist ein Kontinuum, weshalb Entwicklerinnen und Entwickler sie nicht mit einer "Alles oder nichts"-Haltung behandeln sollten. Stattdessen sollte der Schwerpunkt darauf liegen, ob Websites mehr oder weniger zugänglich sind. Es lohnt sich jeder einzelne Schritt, um eine Website inklusiver zu machen – und darüber zu sprechen. Auf dieser Grundlage bieten sich einige pragmatische Tipps und Tricks an, wie Webentwickler Accessibility-Features in ihre tägliche Programmierroutine integrieren können. Diese leicht durchführbaren Maßnahmen lassen sich mit sofortiger Wirkung und fast ohne Kosten umsetzen. Die folgenden Tools machen eine Website nicht vollständig barrierefrei, aber wie das Sprichwort sagt: Der Weg ist das Ziel.

Zwei Aspekte machen aus manuellem Accessibility-Testing ein teures und umständliches Unterfangen: Erstens benötigen die Testerinnen und Tester Kenntnisse über alle Anforderungen, und zweitens müssen sie die gesamte Website Zeile für Zeile nach Accessibility-Verstößen durchsuchen. Um diesen Aufwand deutlich zu reduzieren, stehen hilfreiche Browsererweiterungen bereit.

Eine dieser Erweiterungen ist Lighthouse, das vor allem für seine Performance-Analyse bekannt ist. Lighthouse lässt sich jedoch auch nutzen, um die Web-Accessibility zu bewerten und zu verbessern. Es ist direkt in Google Chrome integriert und ermöglicht es Entwicklern, ihre Websites im Hinblick auf potenzielle Accessibility-Probleme zu beurteilen und Einblicke in verbesserungsbedürftige Bereiche zu erhalten.

Nach Abschluss der Prüfung präsentiert Lighthouse einen umfassenden Bericht, der eine Bewertung der Barrierefreiheit, eine Liste der erfolgreich bestandenen Audits und spezifische Empfehlungen zum Beheben der festgestellten Probleme enthält (siehe Kasten "Lighthouse Accessibility Score"). Die Vorschläge basieren auf den Web Content Accessibility Guidelines (WCAG) (siehe Kasten "WCAG") und sind entsprechend den Auswirkungen auf die User gewichtet. Zu den kritischen Regeln zählen:

  • [user-scalable="no"] darf nicht im Element <meta name="viewport"> vorhanden sein und das Attribut [maximum-scale] muss größer 5 sein. Wenn die Website gegen diese Regel verstößt, bedeutet das, dass sie entweder das Zoomen deaktiviert oder einschränkt, wie stark sich der Inhalt der Website vergrößern lässt. Das ist problematisch für Menschen mit Sehschwäche, die auf Bildschirmlupen angewiesen sind.
  • <video>-Elemente enthalten ein <track>-Element mit dem Attribut [kind="captions"] zum Anzeigen von Untertiteln. Diese Prüfung ist für gehörlose Nutzerinnen und Nutzer wichtig, die sonst nur begrenzten oder keinen Zugang zu den Informationen in einem Video hätten. Personen, die eine Fremdsprache lernen, profitieren ebenfalls von Untertiteln.
Lighthouse Accessibility Score

Lighthouse liefert einen Lighthouse Accessibility Score zwischen 0 und 100, basierend auf der Anzahl der bestandenen beziehungsweise nicht bestandenen Audits, wobei 100 den bestmöglichen Wert darstellt. Jede Barriere kann eine potenzielle Auswirkung auf die Nutzer haben, beispielsweise „kritisch“, „schwerwiegend“, „mäßig“ oder „geringfügig“, je nachdem, wie stark sie das Verwenden der Website beeinträchtigen könnte. Das Tool beurteilt die Auswirkungen auf die User, und Entwickler können diese Beurteilungen nutzen, um die Barrierefreiheit der Webseite zu verbessern, was wiederum den Lighthouse Accessibility Score positiv beeinflussen kann.

Die Vorteile von Lighthouse sind, dass es in Google Chrome enthalten ist und messbare Einblicke liefert. Allerdings stützt es sich auf die Testregeln der axe-core-Bibliothek, einer etablierten Engine für das Accessibility-Testing von Web-User-Interfaces, und führt nur einen begrenzten Teil dieser Regeln aus. Für ein vollständiges Audit empfiehlt sich daher die Installation der Erweiterung axe DevTools, die auch für die Browser Mozilla Firefox und Microsoft Edge verfügbar ist. Zum Beispiel erreicht die Website "State of JavaScript" in Lighthouse ein solides Ergebnis von 89 Punkten (Abbildung 1). Wenn man sie jedoch mit der Erweiterung axe DevTools testet, erscheinen 13 zusätzliche Empfehlungen im Vergleich zu Lighthouse (Abbildung 2).

Lighthouse zeigt die Ergebnisse der Accessibility-Prüfung mit einer Punktzahl von 89 für die Website "State of JavaScript" und hebt dabei folgende Probleme hervor: fehlendes lang-Attribut, nicht erkennbare Link-Namen und nichtsequenzielle Verwendung von Überschriftenelementen (Abb. 1).

Die Browsererweiterung axe-core zeigt 21 Accessibility-Schwierigkeiten für die Website "State of JavaScript" an (Abb. 2).

Zu den zahlreichen weiteren Browsererweiterungen gehören WAVE, Siteimprove Accessibility Checker, Accessibility Insights und Tenon. Diese Tools bieten den Vorteil, dass sie verwertbare Erkenntnisse liefern, ohne umfangreiche Kenntnisse über Barrierefreiheit vorauszusetzen. Eine etablierte Option ist axe-core, aber ein Entwicklungsteam muss selbst entscheiden, welches Tool seinen Bedürfnissen am ehesten entspricht. Verlässt man sich jedoch ausschließlich auf Browsererweiterungen für Accessibility-Tests, kann das Einschränkungen für den Entwicklungs-Workflow mit sich bringen.

Wenn Browsererweiterungen nur während der Testphase und nicht während der gesamten Feature-Implementierung zum Einsatz kommen, können Accessibility-Probleme bis zu späteren Phasen des Entwicklungsprozesses unentdeckt bleiben. Browsererweiterungen testen in der Regel Seite für Seite, was sich bei der Arbeit an umfangreichen oder komplexen Websites als zeitaufwändig und umständlich erweisen kann. Außerdem bieten die Erweiterungen unter Umständen nur eingeschränkte Konfigurationsmöglichkeiten oder testen nur nach einem vorgegebenen Regelwerk, wodurch sie projektspezifische Anforderungen übersehen können. Automatisierte Unit- und End-to-End-Tests können einigen dieser Einschränkungen entgegenwirken.