Seite 2: Automatisierte Accessibility-Testing-Tools

Inhaltsverzeichnis

Automatisierte Tests sind programmierte Evaluationen einzelner Komponenten und kompletter Anwendungs-Workflows, die zum Gewährleisten konsistenter und effizienter Tests ohne manuelle Eingriffe ablaufen. Sie lassen sich in bestehende Test-Frameworks und Versionsverwaltungssysteme integrieren, was den Arbeitsablauf optimiert und einen konsistenteren und besser nachvollziehbaren Ansatz für die Barrierefreiheit fördert.

Allgemeine Testbibliotheken lassen sich auch für Accessibility-Tests verwenden, etwa um sicherzustellen, dass eine Schaltfläche sowohl auf Klick- als auch auf Eingabetasten-Ereignisse reagiert und dass User per Tastatur dorthin navigieren können (WCAG 2.1 Keyboard Accessible). Anstatt das Rad neu zu erfinden und sich die notwendigen Testfälle auszudenken, können Entwicklerinnen und Entwickler stattdessen auf die Vorteile spezieller Accessibility-Bibliotheken setzen, die sich auf gängige Accessibility-Anforderungen beziehen. Die folgenden Beispiele zeigen verschiedene Bibliotheken, Test-Engines und -Tools, und wie sie den Testing-Prozess unterstützen.

Testing Library und zugehörige Erweiterung

Testing Library bietet drei Funktionen für Accessibility-Testing: getRoles(), logRoles() und isInaccessible(). Es setzt auf Tests, die der realen Nutzung von Webseiten sehr nahe kommen, und legt den Fokus auf Queries, die visuelle/Maus-Benutzer ebenso berücksichtigen wie jene, die assistive Technologien verwenden, beispielsweise getByRole(), getByLabelText() und getByPlaceholderText(). Zusätzlich lässt sich eine Erweiterung für das Keyboard-Testing verwenden, um das Verhalten von Usern zu simulieren, die ausschließlich per Tastatur arbeiten.

Accessibility Testing Engines and Integrationen

Accessibility-Regelsätze sind das Herzstück mehrerer Testwerkzeuge. Die Grundlage dafür bilden Standards wie WCAG und Accessible Rich Internet Applications (ARIA). Am bekanntesten ist axe-core von Deque Systems, eine weit verbreitete Accessibility Engine für das Testen von Web-User-Interfaces. axe-core lässt sich mit verschiedenen Test Runnern und Frameworks wie Jest (jest-axe), Ember (ember-a11y-testing), React (axe-core/react) und Vue (vue-axe) integrieren. Das Verwenden von axe-core ist auch in End-to-End-Tests mit Tools wie Cypress (cypress-axe), Selenium (axe-core-selenium) und Playwright (axe-core/playwright) möglich.

Die Tests profitieren von einer umfangreichen und anpassbaren Regelsammlung und sind für bestimmte WCAG-Versionen und die Konformitätsstufen A, AA oder AAA konfigurierbar (siehe Infokasten "WCAG"). Zu den weiteren Accessibility Testing Engines und Accessibility-Regelsätzen zählen die Accessibility Checker Engine von IBM, die WAVE Stand-alone API and Testing Engine von WebAIM, die Tenon/Access Engine von Level Access, ARC von TGPi und der Alfa Accessibility Checker der Softwarefirma Siteimprove.

Web Content Accessibility Guidelines (WCAG)

Die Web Content Accessibility Guidelines (WCAG) 2.1 sehen drei Abstufungen vor, um eine Bandbreite von Nutzergruppen und Situationen abzudecken. Diese Stufen umfassen Stufe A (basic), Stufe AA (intermediate) und Stufe AAA (advanced). Jede höhere Stufe bedeutet die Zugänglichkeit für breitere Nutzergruppen und erfüllt demnach auch die Anforderungen der niedrigeren Stufen. Entspricht eine Webseite beispielsweise der Stufe AA, erfüllt sie automatisch die Standards sowohl von Stufe A als auch von Stufe AA. Für Stufe A müssen 25 Kriterien erfüllt sein, für Stufe AA sind 13 zusätzliche Kriterien erforderlich. Stufe AAA ist mit 23 weiteren Kriterien die Königsdisziplin.

Screenreader-Treiber

Guidepup ist ein Screenreader-Treiber für VoiceOver (macOS) und NVDA (NonVisual Desktop Access, Windows). Er ist darauf ausgelegt, Entwicklern dabei zu helfen, mit Screenreadern so zu navigieren, wie es ein User tun würde und hilft, auf automatisierte Weise festzustellen, was Nutzer von Screenreadern wirklich hören. Weitere Tools in dieser Gruppe sind JAWS Inspect, die Screen Reader Testing Library für NVDA und Assistive-Webdriver (JAWS und NVDA). Das korrekte Schreiben von Testaussagen setzt allerdings ein gewisses Verständnis der Funktionsweise von Screenreadern voraus. Die größte Einschränkung der genannten Tests und Browsererweiterungen besteht darin, dass Entwickler die Audits manuell auslösen müssen. Mit anderen Worten: Der Code ist in Ordnung, solange ihn niemand testet. Linter können dieses Defizit beheben.

Mit Accessibility Lintern zu einem inklusiveren Web – Zeile für Zeile

Ein Linter ist ein statisches Tool zur Codeanalyse, das Entwicklerinnen und Entwicklern hilft, potenzielle Probleme in ihrem Code zu erkennen, indem es ihn anhand einer Reihe vordefinierter Regeln oder Best Practices überprüft. Linter lassen sich in den Entwicklungs-Workflow integrieren, wo sie automatisch beim Speichern von Änderungen oder als Teil einer Continuous-Integration-(CI)-Pipeline ausgeführt werden.

Es gibt mehrere Accessibility Linter, von denen jeder seinen eigenen Regeln und Best Practices folgt. Einige Beispiele sind:

• Mehrere Plug-ins für ESLint auf der Grundlage des axe-core-Regelsatzes: für JSX (eslint-plugin-jsx-a11y), Vue (eslint-plugin-vuejs-accessibility), Lit (eslint-plugin-lit-a11y) und CoffeeScript (eslint-plugin-coffee)
• ASLint-Validierungsdienstprogramm auf der Grundlage des Tenon/Access-Engine-Regelsatzes
• ESLint mit angular-eslint/eslint-plugin: ein Accessibility-Checker für Angular-Anwendungen mit eigenem Regelwerk
• ESLint mit ember-template-lint: ein Accessibility-Checker für Ember- oder Handlebars-Vorlagen
• ESLint mit dem HTML-Linter: ein allgemeines Regelwerk für HTML-Linting, einschließlich Best Practices, SEO, Barrierefreiheit und Styles
• Stylelint mit dem Plug-in stylelint-a11y: Stylelint ist ein beliebter CSS-Linter, der sich durch Plug-ins erweitern lässt. Das stylelint-a11y-Plug-in konzentriert sich auf Barrierefreiheitsprobleme in CSS-Code.
• storybook-addon-a11y: Dieses Add-on ist streng genommen kein Linter, sondern integriert Accessibility-Checks unmittelbar in die Komponentenbibliothek und bietet visuelles Feedback innerhalb der Storybook-Oberfläche.

Ein Blick auf die Regelsätze der Linter wirft ein Licht auf die bewährten Verfahren für barrierefreie Websites. Mehrere Linter, die auf unterschiedlichen Regelsätzen basieren, haben sich zum Beispiel für die Implementierung einer no-positive-tabindex-Regel entschieden. Diese Regel verlangt, dass alle Elemente, die die Eigenschaft tabindex verwenden, diese auf 0 oder negative Werte setzen. Das ist deshalb wichtig, weil Elemente mit einem positiven tabindex die ersten Elemente sind, die Benutzer auf einer Webseite ansteuern. In diesem Fall würden sich die Tastaturnavigation und die Screenreader-Ansagen von der visuellen (und logischen) Reihenfolge der Elemente unterscheiden, was Benutzer verwirren könnte.

Eine weitere, in mehreren Lintern implementierte Regel betrifft die Verwendung von Autofokus. Die automatische Fokussierung eines Formularsteuerelements kann sehbeeinträchtigte Menschen, die Screenreader verwenden, und Menschen mit kognitiven Beeinträchtigungen verwirren. Wenn der Autofokus zugewiesen ist, "teleportieren" Screenreader ihre Benutzer auf das Formularsteuerelement, ohne sie zuvor zu warnen.

Zudem kontrollieren viele Regeln die Implementierung von Accessible Rich Internet Applications (ARIA), wie aria-roles, aria-props und aria-unsupported-elements. Diese Regeln kontrollieren die Verwendung von ARIA-Attributen, indem sie sicherstellen, dass die richtigen Werte und Wertetypen vorhanden sind.

Linter können Entwicklerinnen und Entwickler zwar vor Accessibility-Problemen warnen, aber sie können nicht verhindern, dass sie diese Warnungen ignorieren und den Code dennoch in Produktion geben. Der nächste Schritt, um eine barrierefreie Implementierung zu gewährleisten, wäre, das Linting in den Pre-Commit-Hook zu integrieren und damit Commits mit erkannten Problemen zu blockieren. Task-Runner und npm-Skripte können die gleiche Funktion erfüllen. Es gibt mehrere Plug-ins für Gulp und Grunt, die auf den Tenon- und axe-core-Regelsätzen basieren.

Während ein Entwicklungsteam selbst entscheiden könnte, ob es Browsererweiterungen und Linter verwenden möchte, erfordert der nächste Schritt eine erste kleine Änderung in der Priorisierung von Accessibility-Problemen. Können sie ein Grund für einen Aufschub des Release sein? Wenn ja, mit welchen Tools lässt sich das durchsetzen?