Eine repräsentative Stichprobe ist eine gezielte Auswahl von Seiten, Vorlagen und Abläufen einer Website, die stellvertretend für das ganze Angebot auf Barrierefreiheit geprüft wird. Statt tausende Seiten einzeln zu testen, prüft man eine gut gewählte Auswahl und kann damit eine belastbare Aussage über alle treffen.
Das Prinzip kennt jeder aus der Küche: Wer eine Suppe abschmeckt, isst nicht den ganzen Topf. Ein Löffel reicht, wenn vorher gut umgerührt wurde. Bei Websites heißt umrühren: alle Seitentypen, alle wichtigen Prozesse und ein paar zufällig gezogene Seiten kommen in die Auswahl.
Wie das methodisch sauber geht, beschreibt die WCAG Evaluation Methodology, kurz WCAG-EM. Sie liegt seit Juli 2026 in Version 2.0 als Note des W3C vor.
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.
Die Qualität einer Prüfung steht und fällt mit der Auswahl. Testet man nur die Startseite, sieht alles gut aus, bis jemand im Checkout scheitert. Bei NCA kennen wir die Stellen, an denen Shops, Portale und Web Apps typischerweise brechen, und nehmen genau diese Vorlagen und Strecken in die Stichprobe auf.
Gemeinsam mit eurem Team erfassen wir alle Seitentypen, Komponenten und Prozesse, ziehen ergänzend zufällige Seiten und prüfen die Auswahl manuell und automatisiert. Das Ergebnis ist die Grundlage für jedes Accessibility Audit, für die Erklärung zur Konformität und für einen Accessibility Conformance Report. Weil sich Websites ständig ändern, machen wir aus der einmaligen Stichprobe eine dauerhafte: Die wichtigsten Seiten laufen als automatisiertes Accessibility Testing in eurer Pipeline. Rechtlich ordnen wir das Ergebnis gegen das BFSG ein, technisch setzen wir die Korrekturen im barrierefreien Webdesign um.
WCAG-EM 2.0 teilt jede Prüfung in fünf Schritte. Die Stichprobe ist der dritte, aber sie hängt an den beiden davor:
Wer Schritt zwei überspringt, wählt nach Gefühl aus und übersieht genau die Seiten, die sonst niemand anschaut.
Eine gute Stichprobe besteht aus zwei Teilen, die sich gegenseitig absichern.
Die strukturierte Auswahl deckt bewusst alles ab, was die Erkundung gezeigt hat:
Die zufällige Auswahl kommt obendrauf. WCAG-EM 2.0 legt ihre Größe auf 10 Prozent der strukturierten Auswahl fest. Wer 80 Seiten strukturiert ausgewählt hat, zieht also 8 weitere zufällig. Diese Seiten zeigen, ob die strukturierte Auswahl wirklich repräsentativ war. Finden sich dort ganz neue Fehlerarten, war die Erkundung zu oberflächlich.
Nicht jede Prüfung braucht von Anfang an den vollen Umfang. Die Tabelle zeigt, wie aussagekräftig eine Stichprobe je nach Aufbau ist und wofür sie taugt.
Die strukturierte Auswahl als Datei. Wer die Stichprobe im Repository pflegt, kann sie bei jedem Release erneut prüfen. Jede Vorlage und jeder Prozess bekommt einen Eintrag.
[
{ "name": "Startseite", "path": "/" },
{ "name": "Kategorie", "path": "/schuhe" },
{ "name": "Produkt", "path": "/schuhe/laufschuh-aero" },
{ "name": "Suche ohne Treffer", "path": "/suche?q=xyz" },
{ "name": "Kontakt", "path": "/kontakt" },
{ "name": "Erklärung zur Barrierefreiheit", "path": "/barrierefreiheit" }
]
Die zufällige Ergänzung aus der Sitemap. Ein kleines Skript zieht 10 Prozent zusätzliche Seiten, bei jedem Lauf andere.
// random-sample.js: zieht 10 Prozent zufällige URLs aus der Sitemap
const structured = require('./sample.json')
async function randomSample(sitemapUrl) {
const xml = await (await fetch(sitemapUrl)).text()
const urls = [...xml.matchAll(/<loc>(.*?)<\/loc>/g)].map((m) => new URL(m[1]).pathname)
const count = Math.max(1, Math.round(structured.length * 0.1))
return urls.sort(() => Math.random() - 0.5).slice(0, count)
}
module.exports = { randomSample }
Jede Seite der Stichprobe mit axe prüfen. Cypress geht die Liste durch und meldet Verstöße pro Seite. Das ersetzt nicht die manuelle Prüfung, hält aber die automatisch erkennbaren Fehler dauerhaft draußen.
import sample from '../../sample.json'
describe('Barrierefreiheit Stichprobe', () => {
sample.forEach(({ name, path }) => {
it(`${name} hat keine axe Verstöße auf Stufe A und AA`, () => {
cy.visit(path)
cy.injectAxe()
cy.checkA11y(null, { runOnly: ['wcag2a', 'wcag2aa', 'wcag21aa', 'wcag22aa'] })
})
})
})
Sample size calculation isn't a set relative amount based on the population size.
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 erfahrenDie meiste Zeit einer guten Stichprobe steckt nicht im Prüfen, sondern im Erkunden. Wer eine Stunde lang mit offenen Augen durch die Website klickt, Formulare abschickt, sich einloggt und Fehler provoziert, findet die Seiten, die in die Auswahl gehören. Erst danach lohnt sich der Löffel.
Die Stichprobe verbindet viele Themen. Was geprüft wird, legen die WCAG 2.2 und die POUR Prinzipien fest. Häufige Fundstellen sind Formulare, CAPTCHAs und Downloads, für die es eigene Regeln zu PDF und Barrierefreiheit gibt.
Welche Fristen für Shops gelten, steht bei den Übergangsfristen, wer die Einhaltung prüft, bei der Marktüberwachungsstelle MLBF. Passende Werkzeuge stellen die Accessibility Testing Tools vor.
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.
WCAG-EM, Stichprobengröße, Zufallsauswahl und Wiederholung: was Teams vor einer Prüfung wissen sollten.
Eine repräsentative Stichprobe ist eine gezielte Auswahl von Seiten, Vorlagen und Prozessen, die stellvertretend für eine ganze Website geprüft wird. Sie besteht aus einer strukturierten Auswahl, die alle Seitentypen und wichtigen Abläufe abdeckt, und einer zufälligen Ergänzung. 2026 beschreibt WCAG-EM 2.0 des W3C das Vorgehen.
WCAG-EM steht für WCAG Evaluation Methodology. Die Methode beschreibt, wie Websites und digitale Produkte auf Konformität mit den WCAG geprüft werden. Die erste Fassung erschien 2014, Version 2.0 veröffentlichte das W3C im Juli 2026 als Group Note. Sie gliedert jede Prüfung in fünf Schritte vom Umfang bis zum Bericht.
Eine feste Seitenzahl gibt es nicht. Die strukturierte Auswahl richtet sich nach Größe, Alter, Komplexität und Einheitlichkeit des Angebots und muss alle Seitentypen, Komponenten und wichtigen Prozesse abdecken. Dazu kommt nach WCAG-EM 2.0 eine zufällige Auswahl von 10 Prozent der strukturierten Stichprobe. 2026 gilt das als anerkannter Standard.
Ja, eine methodisch saubere Stichprobe ist die übliche Grundlage für Erklärungen zur Barrierefreiheit und Konformitätsberichte. Wichtig ist, dass die Aussage ehrlich formuliert wird: Sie beruht auf der geprüften Auswahl. Wer 2026 nur die Startseite prüft und daraus eine Aussage für die ganze Website ableitet, steht auf dünnem Eis.
Websites ändern sich mit jedem Release. Eine vollständige manuelle Prüfung lohnt sich nach größeren Umbauten, neuen Vorlagen oder neuen Prozessen. Dazwischen hält eine automatisierte Prüfung der Kernseiten die Qualität. 2026 läuft das bei vielen Teams als Cypress Test mit axe direkt in der Pipeline bei jedem Pull Request.
Die zufällige Auswahl prüft, ob die strukturierte Auswahl wirklich repräsentativ war. Finden sich auf den Zufallsseiten neue Arten von Fehlern, wurden bei der Erkundung Seitentypen oder Komponenten übersehen. Dann muss die strukturierte Auswahl erweitert werden. Ohne diese Kontrolle bleibt die Stichprobe ein Bauchgefühl.
Ja. Ein Prozess wie Registrierung, Bestellung oder Terminbuchung wird von Anfang bis Ende geprüft, mit allen Schritten und Fehlerzuständen. Ein Prozess ist nur so barrierefrei wie sein schwächster Schritt. Scheitert jemand an der Zahlungsseite, nützen ihm barrierefreie Produktseiten wenig.
Ja, wenn sie Teil der geprüften Seiten sind. Cookie Banner, Chat Widgets, Karten, Videos oder eingebundene Buchungstools gehören für Nutzer zur Seite. Sie werden mitgeprüft und im Bericht als Drittanbieter Inhalte gekennzeichnet. So wird sichtbar, wo Verbesserungen beim Anbieter angefragt werden müssen.
Nein. Automatische Werkzeuge wie axe finden einen Teil der Fehler zuverlässig, etwa fehlende Alternativtexte oder zu geringe Kontraste. Ob ein Alternativtext sinnvoll ist, ob die Fokusreihenfolge passt oder ob ein Prozess per Screenreader verständlich bleibt, zeigt nur eine manuelle Prüfung. Beides zusammen ergibt ein belastbares Ergebnis.
Der Bericht nennt den Prüfumfang, das Ziel, etwa WCAG 2.2 AA, die geprüften Seiten und Prozesse sowie die verwendeten Werkzeuge. Dazu kommen die Befunde je Kriterium mit betroffenen Seiten und eine klare Aussage zur Konformität. Gut ist außerdem eine Priorisierung, welche Fehler zuerst behoben werden sollten.
Bei Apps und Single Page Anwendungen gibt es oft keine klassischen Seiten. Die Stichprobe besteht dann aus Ansichten, Zuständen und Abläufen, etwa leere Liste, gefüllte Liste, Bearbeitungsdialog und Fehlermeldung. WCAG-EM 2.0 spricht deshalb allgemeiner von digitalen Produkten und Samples statt nur von Webseiten.
Am besten ein gemischtes Team. Prüfer bringen die Methode und den Blick für typische Fehlerquellen mit, das Produktteam kennt die wichtigen Prozesse und selten besuchten Bereiche. Gemeinsam entsteht eine Auswahl, die weder nur die Schokoladenseiten zeigt noch an der Realität der Nutzer vorbeigeht.
