Barrierefreiheit automatisiert testen
Wie teste ich meine Website auf Barrierefreiheit? Diese Frage lässt sich nicht so einfach beantworten. Als Entwickler:in möchte man so viel wie möglich automatisieren, um Sicherheit zu haben und Zeit zu sparen. Das funktioniert allerdings bei Barrierefreiheit nicht im erwarteten Umfang, denn Barrierefreiheit ist ein komplexes Thema. In diesem Artikel beschreibe ich eine Teststrategie für Barrierefreiheit, mit der wir unseren Aufwand reduzieren und gleichzeitig eine gute Gesamtabsicherung erhalten können.
Die Grundidee ist, mehrgleisig zu fahren und sich auf verschiedenen Ebenen abzusichern. Die verschiedenen Ebenen ergänzen sich gegenseitig und greifen wie Puzzlestücke ineinander. Die vier Ebenen und ihr Zusammenspiel sind in Abb. 1 übersichtlich dargestellt.
- automatisierte Tools
- selbstgeschriebene Tests
- manuelle Tests
- Nutzertests
In den folgenden Abschnitten gehe ich auf die einzelnen Ebenen genauer ein. Doch vorher klären wir noch eine wichtige Frage: Was müssen wir eigentlich testen?
Richtlinien für Barrierefreiheit
Für digitale Produkte sind die WCAG (Web Content Accessibility Guidelines) der De-Facto-Standard. Die Anforderungen sind in den WCAG in die vier Prinzipien wahrnehmbar, bedienbar, verständlich und robust eingeteilt. Alle diese Eigenschaften soll ein Produkt für alle Nutzer:innen haben. Jede Anforderung hat darüber hinaus eine Konformitätsstufe (A bis AAA), die vor allem in rechtlicher Hinsicht wichtig ist. Ein guter Startpunkt, um sich einen Überblick über die WCAG zu verschaffen, ist die Schnellreferenz [1].
Soll ein Produkt auch gesetzeskonform barrierefrei sein, müsst Ihr Euch – für die EU – an EN 301 549 orientieren [2]. Die Norm übernimmt einen Teil der Anforderungen der WCAG, genauer alle Anforderungen der Konformitätsstufen A und AA aus der WCAG Version 2.1. Darüber hinaus gibt es noch weitergehende Anforderungen, wie z. B. das Berücksichtigen von Benutzereinstellungen. Einen Überblick über die genauen Anforderungen bietet diese Seite des Informations Technik Zentrum Bund [3].
Die Menge an Richtlinien ist ziemlich überwältigend, besonders wenn man sich das erste Mal damit beschäftigt. Die Teststrategie soll Euch ermöglichen, es häppchenweise anzugehen. Betrachten wir sie also jetzt genauer. Wir starten mit automatisierten Tools.
Automatisierte Tools
Was können automatisierte Tools?
Es gibt mittlerweile sehr viele Anbieter, die versprechen, mit ihren Tools könne man die komplette Barrierefreiheit einer Website testen. In ihrem Angebot haben sie Dashboards, Browser-Plugins, Website-Add-Ons und alles ist natürlich KI-unterstützt.
Wichtig für Euch zu wissen: Alle diese Tools können nur einen Teil der Anforderungen an Barrierefreiheit überprüfen. Man geht davon aus, dass sie zwischen 30 und 40 Prozent der Probleme erkennen können. Neuere Untersuchungen, wie die von Equal Entry oder Adrian Roselli zeigen, dass das schon eine sehr positive Schätzung ist. Die Toolhersteller sehen das naturgemäß anders, aber Ihr solltet ihre Angaben mit einer gesunden Skepsis betrachten.
Der Grund für die niedrige Abdeckung ist einfach – Viele der Anforderungen hängen im hohen Maße vom Kontext ab: Wie sollen die Nutzer:innen mit der Seite interagieren? Was soll passieren, wenn sie auf bestimmte Knöpfe drücken? Bekommen die Premiumnutzer:innen vielleicht andere Inhalte als die mit einer Free-Lizenz? Dieses Wissen haben generische Tools natürlich nicht. Außerdem machen die Tools nur eine statische Analyse der einzelnen Seiten. Richtige Nutzerinteraktionen können so nicht getestet werden. Alle Anforderungen, die etwas mit Interaktion zu tun haben, fallen damit auch raus.
Das Testen mit automatisierten Tools ist trotzdem ein wichtiger Baustein unserer Teststrategie, denn die Tools haben den Vorteil, dass sie schnell und leicht einsetzbar sind. Sie erleichtern uns auch den Einstieg in den Anforderungskatalog der WCAG: Wenn Probleme gefunden werden, gibt es oft eine gute Erklärung mit Beispielen.
Welche Tools gibt es?
Neben den großen dedizierten Testsuiten sind Testtools für Barrierefreiheit als Plugins für viele Web- und Entwicklungstools erhältlich. Schon in der Designphase eines Softwareprodukts können dedizierte Plugins für Figma & Co. genutzt werden. Für Entwickler gibt es Linter und automatisierte Test-Tools. Außerdem gibt es eine Fülle von Browser-Plugins. Zu denen kommen wir später, zuerst schauen wir uns die Tools für Entwickler an.
Linter
Wenn die Website mit einem der gängigen Javascript-Frameworks gebaut wird, sind Linter der erste Schritt. Sie machen schon während des Programmierens auf Barrierefreiheitsprobleme aufmerksam.
Allerdings ist die Anzahl der erkennbaren Probleme übersichtlich, denn die Linter sind auf den reinen Code beschränkt und erkennen im Wesentlichen falsch verwendete oder fehlende HTML-Attribute. Zum Beispiel ganz klassisch, dass einem <img>-Element ein alt-Attribut fehlt, oder ein ARIA-Attribut falsch eingesetzt wird. Einen Eindruck über die verfügbaren Checks bekommt ihr auf der Dokuseite des Linters für Vue [4]. Für die anderen Frameworks sind die Regeln ähnlich.
Mittlerweile gibt es Linter für Barrierefreiheit für alle gängigen Frameworks, teils bereits integriert in die Framework-Tools. Diesen Baustein für die Qualitätssicherung einzusetzen ist also ein ganz einfacher erster Schritt.
Barrierefreiheits-Checker
Ein weiterer Baustein sind automatisierte Barrierefreiheits-Checker. Man übergibt ihnen eine URL, und sie analysieren die Seite auf Probleme. Die Checker können an allen möglichen Stellen im Entwicklungszyklus eingebunden werden – ob Unit-Tests, E2E-Tests oder in der Pipeline.
Nachfolgend sehen wir ein paar Beispiele. Alle Beispiele in diesem Artikel findet Ihr auch zum Ausprobieren in meinem Projekt dazu auf Codeberg [5].
In Listing 1 binden wir die Library axe-core in einen Playwright-Test ein. Axe ist ein Open-Source-Tool und deshalb sehr beliebt und für viele Test-Frameworks verfügbar.
Listing 1: Ein Playwright-Test mit der axe-core Library
import { test, expect } from "@playwright/test";
import AxeBuilder from "@axe-core/playwright";
test.describe("Axe tests", () => {
test("should not have a11y violations", async ({ page }) => {
await page.goto("/bugpit");
const accessibilityScanResults = await new AxeBuilder({ page }).analyze();
expect(accessibilityScanResults.violations).toEqual([]);
});
});Wie Ihr seht, ist die Einbindung recht einfach: Zuerst rufen wir unsere Seite auf, und übergeben sie dann an axe, das eine Analyse durchführt. Das Resultat ist ein umfangreiches JSON-Objekt. In diesem listet das Array violations die gefundenen Probleme. Ist das Array leer, gibt es kein Problem und der Test ist erfolgreich.
In Abb. 2 sehen wir einen Ausschnitt aus dem violations-Array. Dort wurde ein Verstoß gegen die Regel landmark on main gefunden.
Das Problem ist in der Dokumentation der Regeln für Axe leserlicher dokumentiert [6].
Der große Vorteil bei der Verwendung in E2E-Tests ist, dass die Checker flexibel da eingesetzt werden können, wo sie gebraucht werden. Haben wir zum Beispiel einen Test, der eine Formularstrecke durchläuft, können wir den Checker im Laufe des Tests mehrmals laufen lassen, um die verschiedenen Zustände der Strecke zu überprüfen.
Barrierefreiheits-Checker in der Pipeline
Barrierefreiheits-Checker können auch direkt in der CI-Pipeline eingesetzt werden. Ein Beispiel dafür ist Pa11y, ein weiteres Open-Source-Tool. Es ist kein Checker im eigentlichen Sinne, sondern ein Tool für die Ausführung von Barrierefreiheits-Checkern mit Optionen für die Erstellung von Reports und einem Dashboard. Standardmäßig wird als Checker HTMLCodeSniffer verwendet, aber es können auch andere Checker eingebaut werden. Alles, was Pa11y braucht, ist eine Konfigurationsdatei wie in Listing 2 dargestellt:
Listing 2: Konfigurationsdatei für Pa11y
{
"defaults": {
"timeout": 10000,
"reporters": ["pa11y-ci-reporter-html"]
},
"urls": [
"http://localhost:3000/bugpit"
]
}
Damit kann Pa11y mit folgendem Kommando in der Kommandozeile aufgerufen werden:
./node_modules/.bin/pa11y-ciIn Abb. 3 sehen wir einen Auszug aus einem HTML-Report, der von Pa11y erstellt wurde.
Das ist schon deutlich lesbarer als das JSON-Objekt. Zusätzlich sind hier die Erklärungen direkt verlinkt. Der Nachteil an dem Einsatz direkt in der Pipeline ist, dass Interaktion mit der Seite schwierig ist. Pa11y bietet zwar die Möglichkeit, vor dem Test mit der Seite zu interagieren, aber so komfortabel wie mit den E2E-Test-Frameworks ist das nicht. Es eignet sich also eher für statische Inhalte.
Vor- und Nachteile von automatisierten Tools
Mit automatisierten Tools können wir grundlegende Barrierefreiheitsprobleme schnell und effizient erkennen. Sie entbinden uns allerdings nicht davon, uns mit Barrierefreiheit auseinanderzusetzen. Die gefundenen Probleme erfordern oft eine tiefergehende Analyse.
Meldet das Tool zum Beispiel ein falsches ARIA-Attribut, müsst Ihr zur Behebung des Problems erstmal den Aufbau Eures Elements analysieren, Euch mit der korrekten Verwendung des Attributs vertraut machen und vielleicht sogar Eure Komponente umbauen. Die Tools unterstützen uns dabei mit ihrer Dokumentation und ermöglichen so eine leichtere Problemlösung.
Selbstgeschriebene Tests
Der zweite Baustein der Teststrategie sind selbstgeschriebene Tests, die automatisiert in unserer Pipeline laufen. In diesen Tests können wir die kontextbezogenen und interaktiven Barrierefreiheits-Anforderungen überprüfen, die die automatisierten Tools nicht checken können. So können wir einige Lücken in unserer Qualitätssicherung schließen.
Zwei Bereiche bieten sich besonders an – Keyboardinteraktion und Semantik. Beides sind wichtige Aspekte von Barrierefreiheit und recht einfach zu testen. Nachfolgend betrachten wir einige Beispiele. Ich benutze dafür das Framework Playwright. Im Beispiel-Repository findet ihr weitere Beispiele mit Cypress, Vitest und der Testing Library.
Keyboardinteraktion
Schauen wir uns als Erstes Keyboardinteraktion an. In Listing 3 sehen wir ein Beispiel, wie ein Keyboardtest in Playwright aussehen könnte:
Listing 3: Ein Playwright-Test für Keyboardinteraktion
test("should focus back link first", async ({ page }) => {
await page.goto("/keyboard");
await page.keyboard.press("Tab");
await expect(page.locator("*:focus-visible")).toHaveText("Back to main");
});Wir testen hier die Fokusreihenfolge. Nachdem wir die Seite aufgerufen haben, drücken wir Tab, um zum ersten Element zu springen. Der CSS-Locator *:focus-visible gibt uns jetzt das Element, das den Keyboardfokus hat und wir überprüfen, dass es das erwartete Element ist.
Natürlich ist dieser Test sehr simpel, aber das ist genau der Punkt: Es ist nicht weiter schwierig, Keyboardtests zu schreiben. Klassischerweise schreiben wir Tests, in denen wir mit der Maus klicken. Was ist, wenn Ihr neben jedem neuen Maustest noch einen zweiten Test schreibt, in dem dasselbe Feature mit dem Keyboard getestet wird? Wenn Ihr das sukzessive durchzieht, stellt Ihr so nach und nach sicher, dass alle eure Features mit dem Keyboard bedienbar sind – ein großer Schritt für mehr Barrierefreiheit!
Semantik
Jedes Element im User Interface hat eine bestimmte Bedeutung, die klassischerweise durch visuelle Hinweise dargestellt wird. Große, fette Schrift deutet auf eine Überschrift hin, Text in einem gestylten Kasten ist ein Button. Diese Bedeutungen nennt man semantische Rollen.
Für Barrierefreiheit ist es wichtig, dass semantische Rollen auch im Code hinterlegt werden. So können Nutzer:innen auch auf alternativen Wegen mit der Seite interagieren. Beispielsweise gibt es Browser-Plugins für bessere Lesbarkeit, die störende Elemente ausblenden und nur strukturierten Text anzeigen. Auch für Nutzer:innen assistiver Tools, wie zum Beispiel Screenreader, ist es wichtig, dass vor allem interaktive Elemente richtig ausgezeichnet sind. Ansonsten stehen sie vor dem Problem, dass sie Buttons nicht klicken oder Formulare nicht ausfüllen können.
Um zu überprüfen, ob die Semantik der Seite stimmt, schaut Ihr Euch am besten den Accessibility-Tree an. Dieser wird vom DOM-Tree abgeleitet und enthält nur die Elemente, die eine Bedeutung haben. Der Accessibility-Tree liefert assistiven Tools alle Informationen über die Seite.
In Abb. 4 sehen wir einen Accessibility Tree, wie er in Firefox dargestellt wird.
Auch in Chrome-basierten Browsern gibt es einen Accessibility-Tab in den Dev-Tools mit dem Accessibility-Tree. Alternativ kann der Tree im Elements-Tab gerendert werden, indem man auf das kleine Accessibility-Symbol oben rechts drückt. In dem Tree sehen wir die semantischen Rollen als Knoten. Jeder Knoten hat darüber hinaus einen Namen, den sogenannten accessible name. Idealerweise stimmt der Name mit dem sichtbaren Text überein. Gibt es keinen sichtbaren Text, könnt ihr den Namen durch Attribute wie aria-label oder aria-labelledby setzen.
Im Bild ausgewählt ist der Button mit dem Namen ”"More information". Wir sehen auf der rechten Seite in der Detailansicht, dass der Button zusätzlich zu Rolle und Name noch weitere Eigenschaften hat, wie zum Beispiel verfügbare Aktionen und Zustände. Diese Eigenschaften erlauben es assistiven Tools erst, ihren Nutzer:innen Aktionen zur Verfügung zu stellen. Zum Beispiel könnte ich mit diesen Infos zu einer Sprachsteuerung sagen: "Drücke Button More information!"
Semantik testen
Um die Semantik einer Seite mit Tests abzusichern, gibt es eine einfache Strategie: Anstatt Elemente anhand von ids, CSS-Selektoren oder data-testid auszuwählen, wählt man Elemente anhand ihrer Semantik aus. Playwright bietet dafür den Selektor getByRole an.
Um zum Beispiel den Button "More information" im Playwright-Test auszuwählen, könnt Ihr die folgende Zeile schreiben:
page.getByRole("button", { name: "More information" });Als erstes Argument nimmt getByRole die semantische Rolle, und als zweites Argument kann man weitere Eigenschaften mitgeben, im Beispiel ist es der Name. Welche Eigenschaft sinnvoll ist, variiert je nach Rolle. Bei Überschriften ist es zum Beispiel der Heading Level:
page.getByRole("heading", { level: 1 });Wenn Ihr konsequent in allen Tests Elemente anhand ihrer semantischen Eigenschaften auswählt, stellt Ihr damit die korrekte Semantik indirekt sicher und braucht keine zusätzlichen Tests dafür. Manchmal ist die Semantik aber doch etwas komplexer, dann bietet sich die eine oder andere zusätzliche Testzeile an. Relativ bequem kann man die Semantik auch mit ARIA-Snapshots testen. ARIA-Snapshots sind Snapshot-Tests, die auf dem Accessibility-Tree basieren. Listing 4 zeigt die Anwendung:
Listing 4: ARIA-Snapshot Test für einen Button
await expect(page.getByRole("button", { name: "More information" }))
.toMatchAriaSnapshot(`
- button "More information":
- img "More information"
`);Der Snapshot kann sich auf die ganze Seite beziehen oder nur auf ein einzelnes Element. Wie aus dem Listing erkennbar, ist der ARIA-Snapshot einfacher Text, in dem die Baumstruktur durch Einrückung und Minuszeichen abgebildet ist. ARIA-Snapshots bieten somit eine einfache Möglichkeit, um schnell die Semantik festzuhalten.
Manuelle Tests
Automatische Tests haben ihre Grenzen. Nicht jeder erdenkliche Fall kann abgedeckt werden. Probleme mit der Bedienbarkeit fallen oft auch erst in manuellen Tests auf. Für Barrierefreiheit gibt es außerdem weitere Unwägbarkeiten: Einschränkungen und assistive Tools können von den automatischen Tools nicht oder nur unzureichend simuliert werden.
Manuelle Tests sind also wichtig in jedem Entwicklungsschritt. Aber was muss alles getestet werden? Die Antwort ist: Es kommt drauf an. Ein vollständiger Test aller Kriterien kann sehr umfangreich sein. Einen kompletten Test müsst ihr aber nicht ständig bei jeder Änderung durchführen. Übergreifende Aspekte, wie Seitennavigation und Farbschema, werden sich wenig ändern. Am besten identifiziert ihr die wichtigsten Kriterien für euren Anwendungsfall und haltet sie in Form einer Checkliste fest, die ihr gut durcharbeiten könnt.
Auch bei manuellen Tests können Tools unterstützen. Dafür gibt es mittlerweile viele Browser-Plugins. In diesen sind auch teilweise automatische Checker integriert. Nachfolgend stelle ich einige davon vor. Falls nicht anders genannt, handelt es sich um Chrome-Plugins:
- Accessibility Insights: Dieses Plugin ist im Wesentlichen eine interaktive Checkliste für das Testen auf Barrierefreiheit. Es eignet sich sehr gut als Einstieg, um sich mit den Testschritten vertraut zu machen. Bei Bedarf können auch Reports erstellt werden. Das Plugin gibt es für Chrome und Edge.
- Wave: ein Klassiker. Es bietet neben einem Checker noch weitere Tools, die Informationen über die Seite liefern, zum Beispiel über die Struktur, Fokusreihenfolge oder Kontrast.
- Silktide: Wer sich mit der Optik von Wave nicht anfreunden kann, ist vielleicht mit Silktide zufriedener. Es kann im Wesentlichen das Gleiche und bietet zusätzliche Tools, zum Beispiel einen Impaired Vision Simulator.
- WCAG Contrast Checker: sehr nützlich für den schnellen Kontrastcheck mit einem aufgeräumten Interface und einem Pipettentool
Ich benutze alle diese Plugins, je nach Anwendungsfall, da sie unterschiedliche Features bieten. Zum manuellen Testen gehört aber auch, die Seite durch die Nutzerbrille zu betrachten, beispielsweise das Hineinzoomen oder die Seite in Grautönen rendern lassen. Auch das Testen mit dem Screenreader gehört dazu. Dabei sollte Euch bewusst sein, dass die Testergebnisse von Menschen, die Einschränkungen nur simulieren, nur begrenzt aussagefähig sind. Denn da werden oft Annahmen getroffen, die sich später als falsch herausstellen.
Um falsche Annahmen zu vermeiden, solltet Ihr Euch damit auseinandersetzen, wie Nutzer:innen mit verschiedenen Einschränkungen mit Websites interagieren. Ein guter Startpunkt dafür ist die Seite des W3C: Accessibility: It's about people [7]. Noch besser ist es, echte Nutzer:innen in Nutzertests zu beobachten. Damit kommen wir zum letzten Baustein unserer Teststrategie.
Nutzertests
Nutzertests sind eigentlich ein zentraler Aspekt der Produktentwicklung. Sie sollten möglichst früh und oft durchgeführt werden und nicht erst ganz am Ende der Entwicklung. In unserer Teststrategie geht es konkret um Nutzer:innen mit Behinderung. Sie eröffnen oft ganz neue Perspektiven auf die Nutzung eines Produkts.
Ein Beispiel aus einem Ticket-Shop: In diesem muss man zunächst eine Kategorie für das Ticket auswählen, indem man auf einen Button klickt. Daraufhin fahren weitere Felder aus. In Abb. 5 seht Ihr den Zustand, nachdem ich den Button "Einzel/Erwachsener" gedrückt habe. Nur mit den zusätzlichen Feldern kann ich das Ticket konfigurieren und in den Warenkorb legen. Für Screenreader-Nutzer:innen kommt keinerlei Rückmeldung über die neuen Felder. Wenn sie auf den Button klicken, scheint es, als ob der Button keine Aktion auslöst.
Solche Probleme fallen nicht unbedingt auf, wenn ein sehender Mensch mit dem Screenreader testet, denn der sieht ja die Reaktion auf den Buttonklick. Da ist es sehr wertvoll, Input von einer/einem echten Nutzer:in zu bekommen.
Natürlich kosten Nutzertests Geld und werden schon allein deshalb nicht oft durchgeführt. Wenn Ihr Barrierefreiheit ernst nehmt, solltet Ihr aber hier auch investieren. Es wird Euch nicht nur helfen, Nutzer:innen mit Behinderung besser zu verstehen, sondern Euer Produkt für alle zu verbessern.
Barrierefreiheit auf den diesjährigen IT-Tagen
Spannende Vorträge zum Thema Barrierefreiheit erwarten Euch auch auf den IT-Tagen, der Jahreskonferenz von Informatik Aktuell. Die IT-Konferenz findet jedes Jahr im Dezember in Frankfurt statt – dieses Jahr vom 08.-11.12.
Fazit
Barrierefreiheit ist ein komplexes Thema, das sich nicht so einfach mit Tests absichern lässt. Ich habe Euch eine Teststrategie vorgestellt, die automatisierte Tools, selbstgeschriebene Tests, manuelle Tests und Nutzertests kombiniert.
Die automatisierten Tools sind dabei ein logischer erster Schritt, weil sie schnell Ergebnisse liefern und Hilfestellung zu den Anforderungen für Barrierefreiheit bieten. Selbstgeschriebene Tests erfordern eine tiefere Auseinandersetzung mit Barrierefreiheit und werden sinnvollerweise sukzessive ausgebaut. Manuelle Tests sind nach wie vor unverzichtbar. Hier können Tools und Checklisten als Unterstützung dienen. Nutzertests komplettieren die Strategie und liefern wertvolle Einsichten in die Anforderungen von Nutzer:innen jenseits der Richtlinien.
Mit dieser Strategie könnt Ihr nach und nach sicherstellen, dass Ihr die Anforderungen an Barrierefreiheit erfüllt und damit Euer Produkt für alle zugänglich macht.
Auf den IT-Tagen im Dezember hält Anna Maier einen Vortrag zum Thema
"Barrierefreiheit automatisiert testen".
Die Konferenz findet vom 08. - 11.12.2025 in Frankfurt statt.
- How to Meet WCAG (Quick Reference)
- Informations Technik Zentrum Bund: Harmonisierte Europäische Norm (EN) 301 549 549
- Vue
- Codeberg: automated-accessibility-testing
- Regeln für Axe (Dokumentation)
- W3C: Accessibility: It's about people
