NCA Social Media
Erstellt:
Aktualisiert:
Autor:
Roland Golla
Accessibility Testing Tools im Werkzeugkoffer

Was sind Accessibility Testing Tools?

Accessibility Testing Tools sind Werkzeuge, die Websites und Web Apps auf Barrieren prüfen, etwa fehlende Alternativtexte, schwache Kontraste oder falsche ARIA Attribute. Dazu zählen Linter im Editor, Browser Extensions, Test Engines wie axe-core in der CI Pipeline und Hilfen für die manuelle Prüfung.

Stell dir einen Werkzeugkoffer vor. Der Hammer schlägt Nägel ein, die Wasserwaage zeigt, ob das Regal gerade hängt, der Zollstock misst. Jedes Werkzeug kann eine Sache richtig gut. Ein Haus baut aber keines davon allein.

Genau so ist es bei Barrierefreiheit. Ein Linter findet Fehler beim Tippen, eine Extension zeigt Probleme auf der fertigen Seite, ein Test im CI schützt jedes Release. Ob eine Seite wirklich gut nutzbar ist, entscheidet am Ende ein Mensch mit Tastatur und Screenreader.

Inhalt
NCA Cypress Workshop mit Cypress Ambassador Roland Golla

E2E Tests, die euer Team selbst schreibt

Ein Tag inhouse mit Roland Golla, offizieller Cypress Ambassador und seit über 20 Jahren in Testing und Refactoring zu Hause. Auf unserem YouTube Kanal zeigt er in über 70 Live Coding Tutorials, wie Cypress in echten Projekten läuft. Dazu kommt unser Open Source Plugin NCA TESTIFY: Basistests für jede Website, mit einer Zeile im CI/CD Setup. Im Workshop lernt euer Team Setup, stabile Selektoren, Custom Commands und Tests in der Pipeline.

  1. 1
    Kostenloses Vorgespräch
    Projekt, Stack und Teststand klären
  2. 2
    Workshoptag bei euch
    Setup, Patterns und erste Tests im Team
  3. 3
    Praxistag optional
    Tests im eigenen Projekt und in CI
Roland Golla
Roland Golla
Fullstack Developer
Zum Cypress Workshop arrow_forward

Wir packen den Werkzeugkoffer mit euch

Bei NCA bauen wir Frontends mit Astro, React und Vue. Getestet wird mit Cypress und Cypress Cloud, die Pipelines laufen in GitHub Actions und GitLab CI. cypress-axe ist bei uns Teil dieser Tests. So wissen wir aus dem Alltag, welches Werkzeug welchen Fehler findet und wo die Automatisierung aufhört.

Wir helfen euch, die passenden Werkzeuge auszuwählen und in eure Teststrategie für Barrierefreiheit einzubauen. Wo Tools nicht reichen, prüfen wir in einem Accessibility Audit von Hand gegen die WCAG Kriterien. Gefundene Fehler beheben wir im barrierefreien Webdesign und Frontend, von sauberem semantischem HTML bis zur Bedienung per Tastatur.

Jedes Werkzeug hat seinen Handgriff

Wer ein Regal aufhängt, greift nicht fünfmal zum Hammer. Erst misst der Zollstock, dann bohrt die Maschine, am Ende prüft die Wasserwaage. Die Reihenfolge zählt, und jedes Werkzeug kommt genau dann dran, wenn es am meisten bringt.

Bei Tests für Barrierefreiheit ist es genauso:

  • Beim Tippen meldet der Linter ein Bild ohne Alternativtext, bevor es überhaupt im Browser landet.
  • Im Browser zeigt eine Extension, wo auf der fertigen Seite Kontraste oder Labels fehlen.
  • Im CI läuft eine Test Engine bei jedem Commit und hält Fehler auf, bevor sie live gehen.
  • Am Schluss prüft ein Mensch, ob die Seite mit Tastatur und Screenreader Sinn ergibt.

Viele Teams greifen zum bekanntesten Werkzeug und hoffen, dass es alles erledigt. Ein grüner Haken heißt aber nur, dass dieses eine Tool nichts gefunden hat. Erst alle Handgriffe zusammen ergeben ein stabiles Haus.

Diese Werkzeuge liegen 2026 im Koffer

Die meisten bekannten Tools sind Open Source. Viele davon bauen auf derselben Engine auf. Ein kurzer Blick auf die wichtigsten:

  • axe-core von Deque ist eine Test Engine für Websites und HTML Oberflächen. Sie hat Regeln für WCAG 2.0, 2.1 und 2.2 auf den Stufen A, AA und AAA sowie Best Practices. Lizenz ist die Mozilla Public License 2.0. Laut Deque findet axe-core im Schnitt 57 Prozent der WCAG Probleme automatisch. Was sie nicht sicher beurteilen kann, meldet sie als „incomplete“ zur manuellen Prüfung. Als Browser Extension heißt das Ganze axe DevTools.
  • cypress-axe bringt axe-core in Cypress Tests. Die Befehle heißen cy.injectAxe() und cy.checkA11y(). Lizenz ist MIT.
  • Pa11y ist ein Kommandozeilen Tool, pa11y-ci der Runner für mehrere URLs in der Pipeline. Standard ist WCAG2AA, als Engine nutzt Pa11y HTML_CodeSniffer oder axe-core. Lizenz ist LGPL 3.0.
  • Lighthouse von Google prüft Performance, SEO und auch Barrierefreiheit. Der Accessibility Teil basiert auf axe-core. Lizenz ist Apache 2.0.
  • WAVE von WebAIM gibt es als Extension für Chrome, Firefox und Edge. Sie prüft die gerenderte Seite direkt im Browser und markiert Probleme sichtbar im Layout.
  • eslint-plugin-jsx-a11y prüft JSX schon im Editor, unter MIT Lizenz. Für Vue gibt es eslint-plugin-vuejs-accessibility, für Astro bringt eslint-plugin-astro eigene jsx-a11y Konfigurationen mit.
  • Accessibility Tree in Chrome, Edge und Firefox DevTools zeigt, was assistive Technik wirklich sieht: Rolle, Name und Zustand jedes Elements im DOM.

Für einzelne Spezialaufgaben gibt es eigene Seiten im Glossar, etwa zu ANDI, dem Silktide Accessibility Checker und dem Design Plugin Stark.

Welches Werkzeug wann zum Einsatz kommt

Je früher ein Fehler auffällt, desto kleiner ist der Aufwand. Die Tabelle ordnet die Werkzeuge vier Stufen zu, vom Editor bis zur Prüfung durch einen Menschen. Jede Stufe fängt andere Fehler.

Vier Stufen sortieren den Werkzeugkoffer

Stufe Werkzeuge Was die Stufe findet
1: Editor und Linter eslint-plugin-jsx-a11y, eslint-plugin-vuejs-accessibility, eslint-plugin-astro Fehler im Quellcode, etwa fehlende alt Attribute oder ungültige ARIA Rollen
2: Browser Extension axe DevTools, WAVE, Lighthouse in den DevTools Probleme auf der gerenderten Seite, etwa Kontraste und fehlende Labels
3: Test Engine im CI cypress-axe, pa11y-ci, jeweils in GitHub Actions oder GitLab CI Rückschritte bei jedem Commit, auch nach Klicks und in dynamischen Zuständen
4: Manuelle Prüfung Tastatur, Screenreader, Accessibility Tree in den DevTools Verständlichkeit, Fokusreihenfolge, sinnvolle Namen und alles, was Regeln nicht messen

So sieht ein Barrierefreiheitstest im Code aus

Verstöße lesbar ins Terminal schreiben. cypress-axe nimmt bei cy.checkA11y() einen Callback entgegen, der alle gefundenen Verstöße bekommt. Zwei kleine Tasks in der Cypress Konfiguration schreiben sie als Tabelle in die Ausgabe. So steht im Log der Pipeline sofort, welche Regel an wie vielen Stellen verletzt ist. In der Support Datei cypress/support/e2e.js reicht dafür ein import 'cypress-axe'.

Code: 
          
// cypress.config.js
const { defineConfig } = require('cypress')

module.exports = defineConfig({
  e2e: {
    setupNodeEvents(on) {
      on('task', {
        log(message) {
          console.log(message)
          return null
        },
        table(message) {
          console.table(message)
          return null
        }
      })
    }
  }
})
Code: 
          
// cypress/e2e/kontakt.a11y.cy.js
function logViolations(violations) {
  cy.task('log', `${violations.length} Verstöße gegen Barrierefreiheit gefunden`)
  cy.task(
    'table',
    violations.map(({ id, impact, description, nodes }) => ({
      id,
      impact,
      description,
      nodes: nodes.length
    }))
  )
}

describe('Kontaktformular', () => {
  beforeEach(() => {
    cy.visit('/kontakt')
    cy.injectAxe()
  })

  it('hat keine schweren Verstöße beim Laden', () => {
    cy.checkA11y('main', { includedImpacts: ['serious', 'critical'] }, logViolations)
  })

  it('bleibt nach leerem Absenden barrierefrei', () => {
    cy.get('button[type="submit"]').click()
    cy.checkA11y('form', null, logViolations)
  })
})

Zum Vergleich pa11y-ci. Pa11y braucht keinen Testcode. Eine Datei .pa11yci im Projekt listet die URLs, unter defaults stehen Optionen für alle Seiten. Hier laufen beide Engines, axe-core und HTML_CodeSniffer, gegen eine lokale Astro Seite. Dafür sieht pa11y-ci keine Klicks oder Formularzustände, ohne dass ihr Aktionen konfiguriert.

Code: 
          
{
  "defaults": {
    "standard": "WCAG2AA",
    "runners": ["axe", "htmlcs"],
    "timeout": 30000,
    "hideElements": ".cookie-banner"
  },
  "urls": [
    "http://localhost:4321/",
    "http://localhost:4321/kontakt"
  ]
}

Wo der Werkzeugkoffer oft falsch benutzt wird

  1. Ein Tool für alles. Lighthouse zeigt einen hohen Wert, und das Team hält die Seite für barrierefrei. Der Wert sagt nur, dass die automatischen Regeln bestanden sind.
  2. Doppelt gemessen, nichts gewonnen. axe DevTools, Lighthouse und cypress-axe nutzen alle axe-core. Wer alle drei laufen lässt, bekommt oft dieselben Treffer und keine neuen Erkenntnisse.
  3. Nur die Startseite. pa11y-ci prüft genau die URLs in der Liste. Formulare, Modals und Fehlermeldungen tauchen erst nach Klicks auf.
  4. skipFailures für immer. Die Option ist bei cypress-axe als Übergang für alte Projekte gedacht. Bleibt sie dauerhaft an, schlägt kein Test je fehl.
  5. „incomplete“ ignoriert. axe-core meldet unsichere Fälle getrennt. Genau dort stecken oft echte Probleme, die ein Mensch prüfen muss.
  6. Kein Blick in den Accessibility Tree. Wer nur das Layout sieht, merkt nicht, dass ein Button für den Screenreader keinen Namen hat.

Axe-core is the keystone for hundreds of thousands of development teams and businesses

Dylan Barrell, CTO von Deque Systems, dem Herausgeber von axe-core – Deque Blog, Deque’s Axe-Core Achieves Half a Billion Downloads

Gute Werkzeuge brauchen eine klare Reihenfolge

Ein voller Koffer hilft wenig, wenn niemand weiß, wann welches Werkzeug dran ist. Darum lohnt es sich, die Stufen fest im Ablauf zu verankern: Linter im Editor, Tests im Pull Request, manuelle Prüfung vor großen Releases.

Viele Treffer der Tools betreffen dieselben Themen. Kontraste prüft ihr mit dem Farbkontrast Rechner, Grundlagen dazu stehen bei Color Accessibility. Fehler bei Rollen und Attributen erklären die Seiten zu ARIA und zu Name, Rolle und Zustand. Für Eingabefelder hilft der Beitrag zu barrierefreien Formularen.

Was ein Tool nicht messen kann, ordnen die vier Grundprinzipien POUR ein. Wie ihr Seiten für eine Prüfung sinnvoll auswählt, zeigt die repräsentative Stichprobe. Den rechtlichen Rahmen setzen das BFSG und der European Accessibility Act. Wer die Ergebnisse an Einkäufer weitergeben muss, findet beim Accessibility Conformance Report das passende Format.

CYPRESS.IO Ambassador und IT Consultant für QA Engenieering und Qualität in PHP Projekten.
Erreichen Sie unsere Spezialisten zu barrierefreien Webdesign

Wir sind hier, um Ihnen zu helfen. Gemeinsam meistern wir Ihre digitalen Herausforderungen und fördern die Inklusion im Internet. Lassen Sie uns Ihre Projekte mit barrierefreiem Webdesign erfolgreich machen.

Kostenlose Demo Jetzt anrufen

Häufige Fragen zu Accessibility Testing Tools

axe-core, Pa11y, Lighthouse, WAVE und Linter: die wichtigsten Antworten zur Auswahl der richtigen Werkzeuge.

Welche Accessibility Testing Tools sind 2026 am wichtigsten?

Die wichtigsten Werkzeuge 2026 sind axe-core als Test Engine, cypress-axe und pa11y-ci für die CI Pipeline, Lighthouse und WAVE im Browser sowie eslint-plugin-jsx-a11y im Editor. Dazu kommt der Accessibility Tree in den DevTools für die manuelle Prüfung. Keines davon reicht allein. Erst zusammen decken sie Editor, Browser, Pipeline und Mensch ab.

Reichen automatische Tests 2026 für Barrierefreiheit aus?

Nein. Automatische Tools finden nur einen Teil der Probleme. Deque gibt für axe-core an, dass im Schnitt 57 Prozent der WCAG Probleme automatisch gefunden werden. Ob Alternativtexte sinnvoll sind, ob die Fokusreihenfolge passt und ob Inhalte verständlich sind, muss 2026 weiterhin ein Mensch mit Tastatur und Screenreader prüfen.

Unter welcher Lizenz steht axe-core 2026?

axe-core steht unter der Mozilla Public License 2.0 und ist Open Source. Ihr könnt die Engine 2026 frei in eigenen Projekten und Pipelines einsetzen. Deque bietet darauf aufbauend weitere Produkte an, etwa die Browser Extension axe DevTools. Werkzeuge wie cypress-axe und Lighthouse nutzen axe-core direkt als Grundlage für ihre Prüfungen.

Was ist 2026 der Unterschied zwischen cypress-axe und pa11y-ci?

cypress-axe läuft innerhalb von Cypress Tests. Ihr könnt erst klicken, Formulare ausfüllen oder Modals öffnen und dann mit cy.checkA11y genau diesen Zustand prüfen. pa11y-ci braucht keinen Testcode und prüft eine Liste von URLs aus einer Konfigurationsdatei. Für Interaktionen müsst ihr dort Aktionen definieren. 2026 eignen sich beide gut für die CI Pipeline.

Welcher Linter passt 2026 für React, Vue und Astro?

Für React und andere JSX Projekte gibt es eslint-plugin-jsx-a11y. Für Vue Komponenten bietet eslint-plugin-vuejs-accessibility eigene Regeln. eslint-plugin-astro bringt 2026 Konfigurationen mit, die jsx-a11y Regeln auf Astro Komponenten anwenden. Alle drei melden Fehler wie fehlende alt Attribute schon beim Tippen, bevor der Code im Browser landet.

Nutzt Lighthouse axe-core?

Ja. Der Accessibility Teil von Lighthouse basiert auf axe-core. Das Ergebnis fasst Lighthouse in einem Wert zusammen. Ein hoher Wert bedeutet nur, dass die geprüften Regeln bestanden sind. Über die Barrierefreiheit der ganzen Seite sagt er wenig, weil viele Kriterien gar nicht automatisch messbar sind und ein Mensch sie beurteilen muss.

Was macht die WAVE Extension?

WAVE ist eine Browser Extension von WebAIM für Chrome, Firefox und Edge. Sie prüft die gerenderte Seite, also auch Styles und per JavaScript erzeugte Inhalte. Laut WebAIM läuft die Extension komplett im Browser und sendet keine Daten an den WAVE Server. Das ist praktisch für Seiten hinter einem Login oder in der lokalen Entwicklung.

Was zeigt der Accessibility Tree in den DevTools?

Der Accessibility Tree zeigt, wie der Browser eure Seite an assistive Technik weitergibt. Für jedes Element seht ihr Rolle, zugänglichen Namen und Zustand. So erkennt ihr schnell, ob ein Icon Button einen Namen hat oder ob ein Element versteckt ist. Chrome, Edge und Firefox bieten diese Ansicht in ihren Entwicklerwerkzeugen.

Welche Engines nutzt Pa11y?

Pa11y bringt zwei Runner mit, HTML_CodeSniffer als Standard und axe-core als Option. Ihr könnt beide in einem Durchlauf kombinieren. Standardmäßig prüft Pa11y gegen WCAG2AA, möglich sind auch WCAG2A und, nur mit HTML_CodeSniffer, WCAG2AAA. Pa11y und pa11y-ci stehen unter der Lizenz LGPL 3.0 und sind Open Source.

Was bedeutet skipFailures bei cypress-axe?

Mit skipFailures schlägt ein Test bei Verstößen nicht fehl, die Verstöße werden nur geloggt. Laut Dokumentation ist das als Übergang gedacht, etwa um cypress-axe in ein älteres Projekt einzuführen. Besser ist die Kombination mit includedImpacts. Zuerst prüft ihr nur kritische Verstöße und verschärft die Regeln dann Schritt für Schritt.

Wie oft sollten Barrierefreiheitstests laufen?

Linter laufen bei jedem Speichern im Editor. Tests mit cypress-axe oder pa11y-ci sollten bei jedem Pull Request in der Pipeline laufen, etwa in GitHub Actions oder GitLab CI. Manuelle Prüfungen mit Tastatur und Screenreader lohnen sich vor größeren Releases und nach Änderungen an zentralen Komponenten wie Navigation oder Formularen.

Brauche ich mehrere Tools mit derselben Engine?

Meist nicht. axe DevTools, Lighthouse und cypress-axe nutzen alle axe-core und finden deshalb oft dieselben Fehler. Sinnvoller ist eine zweite Engine wie HTML_CodeSniffer über Pa11y oder ein Linter im Editor. So ergänzen sich die Werkzeuge, statt dasselbe doppelt zu messen. Den größten Gewinn bringt am Ende die manuelle Prüfung.