Seite 3: Continuous Integration und Accessibility

Inhaltsverzeichnis

Bei der Continuous Integration (CI) werden Codeänderungen regelmäßig in ein gemeinsames Repository integriert, um sicherzustellen, dass der Code stets in einem veröffentlichungsfähigen Zustand ist. Die Integration von Barrierefreiheitsprüfungen in die CI-Pipeline trägt dazu bei, Accessibility-Probleme frühzeitig zu erkennen und zu verhindern, dass sie die Produktion erreichen. Je nach verwendeten Tools und Diensten gibt es verschiedene Möglichkeiten, Barrierefreiheitsprüfungen in eine CI-Pipeline einzubinden.

• AccessLint und axe Linter für GitHub Actions überprüfen Codeänderungen in Pull Requests und hinterlassen einen Kommentar bei neu entdeckten Accessibility-Problemen, die auf den axe-core Assertions basieren. Wird das Auflösen von Kommentaren zu einem Pflichtkriterium für den Merge, ist die (teilweise) Automatisierung der Barrierefreiheit geboren! Einziger Nachteil: Es ist nur für persönliche Open-Source-Projekte kostenlos verfügbar.
• Im Allgemeinen lassen sich GitHub Actions, GitLab CI, Jenkins und weitere CI/CD-Dienste nutzen, um einen benutzerdefinierten Workflow zu erstellen, der Accessibility-Prüfungen mit Tools wie Lighthouse CI, axe-linter-action, accessibility-insights-scan oder Pa11y beinhaltet. Die in den vorangegangenen Abschnitten erwähnten Linter und automatisierten Testwerkzeuge können ebenfalls Teil dieses Workflows sein. Ein umfassendes Beispiel findet sich in Adrián Bolonios Artikel "Automating the accessibility tests of your source code with GitHub Actions".

Die Integration von Accessibility-Checks in die CI/CD-Pipeline ist entscheidend für das frühzeitige Erkennen von Problemen und das Aufrechterhalten einer inklusiven User Experience. Es ist jedoch wichtig, die potenziellen Auswirkungen auf die Performance zu berücksichtigen, etwa die Zeit vom Commit bis zur Veröffentlichung (Commit to Publish, C2P). Anfängliche Implementierungen automatisierter Accessibility-Tests können sich negativ auf die C2P auswirken, sodass sich die Ausführungszeiten einiger Tests mehr als verdoppeln. Um die Auswirkungen auf die Leistung zu minimieren, sollte man Assertions bewusst einsetzen und sie auf bestimmte Bildschirmsegmente beschränken, wobei der Schwerpunkt auf wichtigen und oft benutzten Transaktionspfaden liegt. Es ist wichtig zu bedenken, dass eine hundertprozentige Abdeckung von Accessibility-Tests nicht das Ziel ist; Tests sind nur ein Werkzeug im Werkzeugkasten der Barrierefreiheit.

Optimierte Konfigurationseinstellungen, das Weglassen leistungsschwacher Regeln mit geringer Auswirkung und verteilte Testjobs können die Leistung erheblich verbessern. Alternativ können dedizierte Jobs Assertions parallel ausführen, um die C2P-Zeit niedrig zu halten und eine reibungslose CI/CD-Pipeline sicherzustellen.

Die nächsten Schritte: vom Verständnis zur Praxis

Allen bisher beschriebenen Tools und Lösungen lag die eingangs erwähnte Annahme zugrunde, dass es Teams an internem Know-how in Bezug auf Accessibility-Anforderungen und Best Practices mangelt. Das lässt sich leicht mit Workshops, Kursen, E-Learnings und Ähnlichem beheben. Es gibt eine Vielzahl kostenloser Ressourcen, die das Projektbudget schonen. Zu den bekanntesten gehören:

• Die MDN Accessibility Learning Area
• Learn Accessibility von Google Developers
• Digital Accessibility Foundations von der W3C Web Accessibility Initiative

Browsererweiterungen und Linter bieten erste Anhaltspunkte für die Barrierefreiheit im Web, aber die richtige Interpretation der Ergebnisse ist entscheidend. Diese Tools zeichnen sich durch eine hervorragende Syntaxprüfung aus, verfolgen aber einen "Einheitsansatz", der für alles gilt. So sollten beispielsweise alt-Attribute nicht leer sein, aber nicht alle Bilder benötigen Textalternativen. Dekorative Bilder tragen nicht zum Inhalt bei und sollten daher nicht angekündigt werden. Das sture Befolgen von Audit-Aktionselementen kann die Benutzerfreundlichkeit von Screenreadern verschlechtern.

Das Verständnis von ARIA-Rollen, -Bezeichnungen und -Attributen ist für die Barrierefreiheit entscheidend. Im ARIA Authoring Practices Guide (APG) heißt es: "Kein ARIA ist besser als schlechtes ARIA." Ein falscher Gebrauch von ARIA kann die Nutzerfreundlichkeit stark beeinträchtigen, etwa wenn man unsachgemäß einem <div>-Tag eine Rolle hinzufügt, ohne die erwarteten Tastaturinteraktionen zu implementieren.

Mangelndes Verständnis von Accessibility-Anforderungen bedeutet auch, dass Entwicklerinnen und Entwickler möglicherweise wesentliche Funktionen nicht kennen, die das Benutzererlebnis verbessern können. Beispielsweise ist die Funktion "zum Hauptinhalt springen" ein wertvolles Accessibility-Feature. Damit können Benutzer, die auf die Tastaturnavigation angewiesen sind, sich wiederholende Navigationselemente umgehen und direkt auf den Hauptinhalt einer Seite zugreifen.

Darüber hinaus ist es sehr hilfreich zu wissen, wie die WCAG zu navigieren und zu interpretieren sind, da sie weithin als Goldstandard für die Barrierefreiheit im Web gelten. Neben den Anforderungen bieten die WCAG auch wertvolle Techniken und Best Practices, die die Compliance erleichtern. Die Richtlinie "2.4 Navigable" enthält beispielsweise ein Erfolgskriterium mit der zugehörigen Technik H25, "Bereitstellung eines Titels unter Verwendung des Elements title". Diese Technik liefert ein Code-Snippet und Testszenarien zur Vereinfachung der Implementierung.

Die Schulung eines Entwicklungsteams ist ein nachhaltigerer Ansatz als die Installation von Lintern und die Integration von Barrierefreiheit in eine CI/CD-Pipeline, aber sie ist nicht der letzte Schritt. Die Einführung eines inklusiven Designprozesses in all seinen Facetten erfordert ein Umdenken in Unternehmen und hat eine enorme transformative Kraft. Das würde jedoch den Rahmen dieses Artikels sprengen.