Barrierefreiheit im Buildprozess automatisiert prüfen

Die Barrierefreiheit von Webanwendungen wird immer wichtiger. Seit ein paar Jahren müssen bereits die Websites von öffentlichen Einrichtungen barrierefrei sein. Ab 2025 kommen viele Websites der Privatwirtschaft dazu. Man spricht von einer barrierefreien Website, wenn Menschen mit Einschränkungen, wie etwa einer Sehschwäche, diese vollumfänglich nutzen können.

Einschränkungen können einen großen Teil der Nutzer:innen betreffen. Beispielsweise betrifft eine Rot-Grün-Schwäche etwa jeden 12. Mann und jede 200. Frau. Ein weiteres Beispiel sind Sehhilfen wie Brillen oder Kontaktlinsen.

Rechtliche Rahmenbedingungen

Die Web Content Accessibility Guidelines (WCAG) bilden europaweit die rechtlichen Rahmenbedingungen für die Barrierefreiheit von Websites. Diese Richtlinien wurden vom W3C herausgegeben und sind in Deutschland als WCAG 2.1 durch die Barrierefreie-Informationstechnik-Verordnung, kurz BITV 2.0, in geltendes Recht umgesetzt.

Toolunterstützung während der Entwicklung

Entwickler:innen spielen bei der Umsetzung der Barrierefreiheit eine besondere Rolle, denn sie können bereits im Quellcode an einigen Stellschrauben drehen, um Barrierefreiheit zu ermöglichen.

In diesem Beitrag möchte ich ein paar einfache Maßnahmen vorstellen, die Entwickler:innen bei der Implementierung unterstützen. Es gilt aber zu beachten, dass die vorgestellten Tools manuelle Prüfungen ergänzen, jedoch nicht ersetzen können.

Im Rahmen der Continuous-Integration (CI-Build oder Buildprozess) werden in der modernen Softwareentwicklung Quality Gates verwendet. Hier werden z. B. automatisierte Tests ausgeführt oder die Qualität des Source Codes, etwa per SonarQube, automatisch überwacht. Schlägt einer dieser Schritte fehl, würde in den meisten Fällen der komplette Buildprozess abbrechen und die Änderung kann nicht gebaut und ausgeliefert werden.

Damit ist der Buildprozess der ideale Ort, um automatisierte Analysen zur Barrierefreiheit durchzuführen.

Das Schweizer Taschenmesser der automatisierten Barrierefreiheitsprüfung

Das Open Source Projekt axe-core ermöglicht die Analyse der Barrierefreiheit von HTML-basierten User Interfaces. Die Analysen basieren auf Regeln, welche die WCAG implementieren. Axe-core kann in einer Vielzahl von Kontexten ausgeführt werden. Die Analysen von axe-core werden nur zu definierten Zeitpunkten durchgeführt. Sie stellen deshalb immer nur eine Momentaufnahme dar! Sollen etwa verschiedene Zustände einer Komponente auf Barrierefreiheit geprüft werden, so muss der Aufruf von axe-core mehrfach erfolgen.

Nutzung in Entwicklertests 

Automatisierte Entwicklertests sollten auch für das Frontend geschrieben werden. Werden diese per jest ausgeführt, so kann mit jest-axe eine axe-core-Analyse integriert werden. Hierfür muss der Test selbst ergänzt werden. Da jest einen Browser mit Hilfe von jsdom emuliert, werden die Komponenten nicht wirklich gerendert. Deswegen können die Farbkontrast-Prüfungen von axe-core mit jest nicht geprüft werden.

Das folgende Codebeispiel zeigt die Nutzung von jest-axe zum Test einer Angular-Komponente mit der Angular Testing Library:

Tests auf Integrationsebene

Sollen nicht nur Komponenten, sondern ganze Frontends getestet werden, so nutzt man Integrationstests. Hierfür kann etwa Playwright verwendet werden. Playwright rendert die Tests in einem Browser wie Edge. Möchte man Playwright mit axe-core kombinieren, so kann das Package @axe-core/playwright genutzt werden.

Das folgende Beispiel zeigt den Aufruf der viadee-Website mit Playwright und die Durchführung der Barrierefreiheitstests:

Der folgende Screenshot zeigt die Ergebnisse: Es wird deutlich, dass bei den Kontrasten auf unserer Webseite noch Verbesserungspotenzial besteht.

LiNting-Regeln zur Unterstützung in der Entwicklungsumgebung und im Buildprozess

Mit ESLint lassen sich Probleme im Quellcode finden. Das Tool kann dabei im Hintergrund in der Entwicklungsumgebung mitlaufen oder im Buildprozess als Quality Gate Fehler aufdecken. Es lässt sich mit vielen Regelwerken erweitern.

Diverse Regelwerke bauen auf axe-core auf: Für die Nutzung mit React gibt es eslint-plugin-jsx-a11y, da das Plugin die react-typische JSX-Syntax versteht. Für Lit, lit-html und Web Components steht das Plugin eslint-plugin-lit-a11y zur Verfügung.

Für Vue.js gibt es ein eigenes ESLint-Regelwerk, welches nicht auf axe-core basiert: eslint-plugin-vuejs-accessibility.

Angular-eslint beinhaltet Barrierefreiheitsregeln für Angular-Projekte.

FaziT

Die in diesem Artikel vorgestellten Tools stellen nur eine kleine Auswahl dar. Entscheidend für meine Auswahl war, dass sie einfach eingebunden werden können und automatisiert Ergebnisse liefern, die sich in bestehende Quality Gates integrieren lassen. Bei aller Euphorie: Denken Sie immer daran, dass diese automatisierten Tools nur einen kleinen Teil der Barrierefreiheitsprüfung abdecken und manuelle Tests unerlässlich sind.

Sie brauchen Hilfe bei der barrierefreien Gestaltung Ihrer Webanwendung? Meine Kolleg:innen im Bereich User Experience beraten Sie gerne.