Accessibility Testing ist das laufende Prüfen einer Website oder App darauf, ob alle Menschen sie nutzen können, auch mit Screenreader, Tastatur oder starker Vergrößerung. Im Team besteht es aus automatischen Tests im Code, manuellen Checks und Tests mit Menschen mit Behinderung.
Stell dir ein Haus vor. Der Rauchmelder an der Decke ist immer an. Er schlägt sofort Alarm, wenn es qualmt. Aber er sieht nicht, ob der Notausgang zugestellt ist. Dafür kommt regelmäßig jemand vorbei und geht durch jeden Raum. Accessibility Testing braucht beides: Tests, die bei jedem Commit laufen, und Menschen, die gezielt hinschauen.
Auf dieser Seite geht es um die Strategie im Team: wer wann was testet. Welche Werkzeuge es gibt, steht bei den Accessibility Testing Tools. Die formale Prüfung mit Bericht beschreibt die Seite zum Accessibility Audit.
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.
Wir bauen Frontends mit Astro, React und Vue und testen sie mit Cypress und Cypress Cloud. Unsere Pipelines laufen in GitHub Actions und GitLab CI. Deshalb sehen wir Barrierefreiheit nicht als Prüfung am Projektende. Sie ist bei uns ein Test wie jeder andere: Er läuft bei jedem Pull Request und blockiert den Merge, wenn etwas kaputt geht.
Wir helfen Teams, eine Teststrategie aufzusetzen, die zum eigenen Projekt passt. Grundlage sind die Kriterien der WCAG und die Pflichten aus dem Barrierefreiheitsstärkungsgesetz. Welche Prüfwerkzeuge in welche Phase gehören, ordnen wir mit euch anhand der Accessibility Testing Tools ein. Wenn ihr einen formalen Nachweis braucht, folgt ein Accessibility Audit. Gefundene Lücken beheben wir direkt im barrierefreien Frontend.
Ein Rauchmelder kostet wenig Aufmerksamkeit. Du hängst ihn auf, und er wacht rund um die Uhr. Genau so arbeiten automatische Accessibility Tests. Sie laufen bei jedem Commit und melden sofort, wenn ein Bild keinen Alternativtext hat oder ein Button keinen Namen.
Doch ein Rauchmelder weiß nichts über Fluchtwege. Ob die Tür im Notfall aufgeht, prüft nur ein Mensch bei der Begehung. Im Web ist das genauso. Ob die Reihenfolge beim Tabben Sinn ergibt, ob ein Alternativtext das Bild wirklich beschreibt, ob ein Dialog mit Screenreader verständlich ist: Das sieht nur, wer selbst testet.
Shift left heißt: Ihr hängt den Rauchmelder auf, bevor ihr einzieht. Wer erst kurz vor dem Launch prüft, findet hunderte Fehler auf einmal. Wer ab dem ersten Pull Request testet, findet jeden Fehler einzeln, solange er noch klein ist. Und die Begehung findet dann die Dinge, die wirklich einen Menschen brauchen.
Eine gute Teststrategie mischt vier Arten. Jede hat ihre Stärke:
Wie viel schafft die Automatik? Deque, der Hersteller von axe, hat 2021 Daten aus über 2.000 Audits ausgewertet. Ergebnis: Automatische Tests fanden rund 57 Prozent der Fehler, gezählt nach Anzahl der Fehler. Das ist viel. Aber es heißt auch: Fast die Hälfte der Fehler bleibt ohne Menschen unentdeckt. Ein grüner Test ist deshalb kein Beweis für Barrierefreiheit.
Nicht jeder Test gehört in jeden Schritt. Die Tabelle zeigt, wie sich die vier Arten über den Alltag eines Teams verteilen: vom Tippen im Editor bis zur Runde mit echten Nutzerinnen und Nutzern.
Schritt 1: axe in Cypress laden. Ihr installiert cypress-axe und axe-core als Dev Abhängigkeiten und bindet das Paket einmal in der Support Datei ein. Danach stehen die Befehle cy.injectAxe und cy.checkA11y in jedem Test bereit.
// cypress/support/e2e.js
import 'cypress-axe'
Schritt 2: axe Prüfung plus Tastatur Smoke Test. Der erste Test meldet schwere Verstöße, die axe im Code findet. Der zweite ist ein kleiner manueller Check, den ihr automatisiert: Fokus auf den ersten Link setzen, mit cy.press echt Tab drücken und prüfen, ob das nächste Element einen sichtbaren Rahmen zeigt. cy.press gibt es seit Cypress 14.3.0. Wenn euer Design den Fokus per Schatten statt Outline zeigt, passt ihr die Prüfung an.
// cypress/e2e/a11y.cy.js
describe('Startseite: Barrierefreiheit', () => {
beforeEach(() => {
cy.visit('/')
cy.injectAxe()
})
it('hat keine schweren axe Verstöße', () => {
cy.checkA11y(null, { includedImpacts: ['critical', 'serious'] })
})
it('zeigt den Fokus nach Tab sichtbar an', () => {
cy.get('header a').first().focus()
cy.press(Cypress.Keyboard.Keys.TAB)
cy.focused()
.should('have.css', 'outline-style')
.and('not.eq', 'none')
})
})
Schritt 3: bei jedem Pull Request laufen lassen. Die offizielle cypress-io/github-action baut das Projekt, startet den Server und führt die Tests aus. Mit record schickt ihr die Ergebnisse an Cypress Cloud. Der Port im Beispiel ist der Standard der Astro Vorschau, die baseUrl in der Cypress Konfiguration muss dazu passen.
# .github/workflows/a11y.yml
name: Accessibility Tests
on: pull_request
jobs:
cypress:
runs-on: ubuntu-24.04
steps:
- uses: actions/checkout@v7
- uses: cypress-io/github-action@v7
with:
build: npm run build
start: npm run preview
wait-on: 'http://localhost:4321'
record: true
env:
CYPRESS_RECORD_KEY: ${{ secrets.CYPRESS_RECORD_KEY }}
Automated accessibility checkers lack the context of a page and user.
Accessibility Audit 2026: Wie eine Prüfung nach WCAG 2.2 abläuft, was in den Bericht gehört, welche Prüftiefe passt und wie Cypress das Ergebnis absichert. Im NCA Glossar.
Mehr erfahrenEine Teststrategie für Barrierefreiheit ist kein Dokument im Wiki. Sie zeigt sich im Alltag: Ein Pull Request ohne grüne axe Tests wird nicht gemergt. Jedes neue Feature geht einmal per Tastatur durch. Und wer ein Formular baut, hört es sich mit dem Screenreader an, bevor es live geht.
Die Prüfungen orientieren sich an den vier Grundprinzipien POUR. Automatisch gut abdeckbar sind Themen wie fehlende Alternativtexte und zu schwache Farbkontraste. Von Hand prüft ihr die Lesereihenfolge, die Darstellung mit Vergrößerung und die Fehlermeldungen in barrierefreien Formularen.
Bei großen Websites testet niemand jede Seite von Hand. Eine repräsentative Stichprobe legt fest, welche Seiten und Vorlagen manuell geprüft werden. Die passenden Werkzeuge für jede Stufe vergleicht die Seite zu den Accessibility Testing Tools.
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.
Automatik, Handarbeit, Shift left und Tests mit echten Nutzern: die wichtigsten Antworten zur Teststrategie.
Accessibility Testing ist das laufende Prüfen, ob alle Menschen eine Website oder App nutzen können, auch mit Screenreader, Tastatur oder Vergrößerung. 2026 besteht es in den meisten Teams aus automatischen Tests im Code und in der CI, manuellen Checks bei jedem Feature und regelmäßigen Tests mit Menschen mit Behinderung.
Nein. Automatische Tests finden Fehler im Code, etwa fehlende Labels oder schwache Kontraste. Eine Auswertung von Deque aus über 2.000 Audits kam auf rund 57 Prozent der Fehler, gezählt nach Anzahl. Ob Fokus, Reihenfolge und Texte verständlich sind, prüfen auch 2026 nur Menschen. Deshalb gehören manuelle Tests immer dazu.
Shift left heißt, Barrierefreiheit früh im Prozess zu testen statt erst vor dem Launch. Linter melden Fehler schon beim Tippen, axe Tests laufen bei jedem Pull Request. So findet ihr jeden Fehler einzeln, solange er klein ist. 2026 ist das in vielen Teams der Standard für Qualität im Frontend.
Das BFSG schreibt keine bestimmte Testmethode vor. Es verlangt, dass Produkte und Dienstleistungen barrierefrei sind, gemessen an den Anforderungen, die in der Praxis auf den WCAG beruhen. Wer das 2026 belegen will, kombiniert automatische Tests, manuelle Prüfungen und bei Bedarf ein formales Audit mit dokumentierten Ergebnissen.
Fangt klein an. Bindet axe in eure bestehenden Cypress Tests ein und lasst sie in der CI laufen. Danach geht jedes neue Feature einmal per Tastatur durch. Im nächsten Schritt lernt das Team die Grundlagen eines Screenreaders. Tests mit echten Nutzerinnen und Nutzern plant ihr 2026 für die wichtigsten Abläufe.
Accessibility Testing ist ein Prozess, der laufend im Entwicklungsalltag stattfindet. Ein Audit ist eine formale Prüfung zu einem Zeitpunkt, meist gegen die WCAG, mit einem schriftlichen Bericht. Testing verhindert neue Fehler, das Audit zeigt den aktuellen Stand und dient als Nachweis, etwa für Kunden oder Ausschreibungen.
Legt die Maus weg und bedient die Seite nur mit Tab, Shift und Tab, Enter, Leertaste und Pfeiltasten. Achtet darauf, ob der Fokus immer sichtbar ist, ob die Reihenfolge Sinn ergibt und ob ihr aus jedem Dialog wieder herauskommt. Jedes Element, das mit der Maus geht, muss auch so erreichbar sein.
Am besten den, den eure Nutzer verwenden. Unter Windows sind NVDA und JAWS verbreitet, auf Apple Geräten VoiceOver, unter Android TalkBack. NVDA ist kostenlos und ein guter Einstieg. Testet mit dem Browser, der zum Screenreader passt, und geht echte Aufgaben durch, etwa ein Formular absenden.
Weil sie euer Produkt so nutzen, wie es im Alltag passiert. Wer jeden Tag mit Screenreader, Vergrößerung oder Sprachsteuerung arbeitet, findet Hürden, die Checklisten und Tools übersehen. Solche Tests zeigen, ob eine Seite nicht nur regelkonform, sondern auch wirklich gut bedienbar ist. Plant die Teilnahme fair bezahlt ein.
Bei jedem neuen Feature und bei jeder größeren Änderung an Layout oder Komponenten. Automatische Tests laufen ohnehin bei jedem Pull Request. Zusätzlich lohnt eine regelmäßige, gründlichere Runde für die wichtigsten Wege, etwa Login, Suche und Checkout. Wie oft genau, hängt von eurem Release Takt ab.
Ja. Mit dem Paket cypress-axe ladet ihr die axe Engine in eure Tests und prüft Seiten mit cy.checkA11y. Seit Cypress 14.3.0 gibt es außerdem cy.press, mit dem ihr echte Tastendrücke wie Tab auslöst. So lassen sich auch einfache Tastatur Checks automatisieren und bei jedem Pull Request ausführen.
Behandelt ihn wie jeden anderen roten Test: Fehler verstehen, beheben, erneut laufen lassen. Die Meldung von axe nennt die Regel, das betroffene Element und einen Link zur Erklärung. Schaltet Regeln nur ab, wenn ihr sicher seid, dass sie nicht zutreffen, und dokumentiert den Grund im Code.
