Ein Prozess für Barrierefreiheitstests, den Webteams wirklich durchhalten

Ein wiederholbarer Prozess zum Testen der Barrierefreiheit von Websites: was Sie automatisieren, was eine Person von Hand prüfen muss, wie Sie Seiten stichprobenartig auswählen, wer abzeichnet, wie Sie Probleme protokollieren und beheben, und eine Freigabeschranke, die verhindert, dass neue Probleme online gehen.

Die meisten Webteams haben mindestens einmal ein Barrierefreiheits-Audit durchgeführt. Ein Berater hat 40 Seiten getestet, einen 90-seitigen Bericht vorgelegt, und sechs Monate später war die Hälfte der Korrekturen umgesetzt, während doppelt so viele neue Probleme online gegangen waren. Das Audit war nicht das Problem. Was fehlte, war ein Prozess: eine Art zu testen, die bei jeder Änderung stattfindet und von Menschen durchgeführt wird, die bereits im Team sind. Dieser Leitfaden beschreibt einen solchen Prozess in der Reihenfolge, in der Sie ihn einführen würden.

Das Prinzip: drei Ebenen, von denen jede auffängt, was die anderen übersehen

Die Web Accessibility Initiative des W3C sagt es klar: Prüftools helfen, aber kein Tool allein kann feststellen, ob eine Website Barrierefreiheitsstandards erfüllt. Ein sinnvoller Prozess hat daher drei Ebenen.

Ebene	Findet	Übersieht	Wann sie läuft
Automatisierte Prüfungen	Fehlende Alt-Attribute, zu geringen Farbkontrast bei einfachem Text, fehlende Formularbeschriftungen, leere Links, doppelte IDs, fehlende Seitensprache	Ob Alternativtext aussagekräftig ist, ob die Fokusreihenfolge sinnvoll ist, ob ein eigenes Widget mit einem Screenreader funktioniert, ob Anweisungen auf Farbe oder Form beruhen	Bei jeder Seitenänderung, idealerweise automatisch
Manuelle Prüfungen durch das Team	Tastaturfallen, unsichtbaren Fokus, verwirrende Überschriften, unklare Linktexte, defekten Zoom und Reflow, schlechte Fehlermeldungen	Reale Hürden für Menschen, die täglich assistive Technologien nutzen	Vor jedem Release und bei neuen Vorlagen
Tests mit Menschen mit Behinderungen	Ob sich die Aufgabe wirklich erledigen lässt: eine Rechnung bezahlen, einen Raum buchen, eine Genehmigung beantragen	Vollständige Abdeckung des Standards	Ein- bis zweimal im Jahr für die wichtigsten Aufgaben

Teams, die sich auf eine Ebene verlassen, erzielen vorhersehbare Ergebnisse. Teams, die nur automatisiert testen, bestehen den Scanner und scheitern bei echten Nutzern. Teams, die nur manuell testen, kommen mit der Menge an Änderungen nicht hinterher. Teams, die nur Nutzertests machen, finden große Probleme und übersehen Hunderte kleine.

Wählen Sie Ihr Ziel und halten Sie es schriftlich fest

Entscheiden Sie, gegen welchen Standard Sie testen, und nehmen Sie ihn in Ihre Richtlinie auf. Viele Organisationen verwenden WCAG 2.1 Level AA, weil das der Standard in der Regel des US-Justizministeriums für staatliche und kommunale Stellen nach ADA Title II ist. WCAG 2.2 ist die aktuelle W3C-Empfehlung; sie ergänzt Kriterien (zum Beispiel dazu, dass der Fokus nicht verdeckt wird, und zur Zielgröße) und streicht 4.1.1 Parsing als überholt. Tests gegen 2.2 AA decken auch 2.1 AA ab, mit Ausnahme von Parsing; viele Teams testen daher gegen 2.2 und berichten gegen den Standard, den ihre rechtliche Pflicht nennt. Unter Section 508 vs. ADA Title II vs. WCAG lesen Sie, was für wen gilt.

Schritt 1: Auswählen, was getestet wird (Stichprobe)

Sie können nicht bei jedem Release jede Seite von Hand testen. Verwenden Sie eine Stichprobe, die die Website repräsentiert, eine Idee aus der Evaluierungsmethodik des W3C (WCAG-EM).

Jede Vorlage. Startseite, Landingpage, Artikel, Übersichtsliste, Suchergebnisse, Formular, Fehlerseite, Veranstaltung, News, Personalverzeichnis. Fehler in Vorlagen wiederholen sich auf jeder Seite, die sie nutzt; wer einen behebt, behebt Hunderte.
Jede Komponente. Menüs, Akkordeons, Tabs, Karussells, Modals, Datumsauswahl, Karten, Videoplayer, Cookie-Banner, Chat-Widgets.
Die wichtigsten Aufgaben. Die fünf bis zehn Dinge, wegen derer die meisten Menschen kommen. Bei einer Stadt könnten das sein: die Wasserrechnung bezahlen, ein Schlagloch melden, Sitzungstagesordnungen finden und eine Genehmigung beantragen.
Eine zufällige Handvoll. Fünf bis zehn zufällig gewählte Seiten, um Inhaltsprobleme zu finden, die sich nicht durch die Vorlagen erklären.

Halten Sie die Stichprobe in einer kurzen Tabelle fest und verwalten Sie sie in der Versionskontrolle. Ergänzen Sie sie, wenn eine neue Vorlage oder Komponente hinzukommt.

Schritt 2: Die manuelle Prüfung, die jeder Tester durchführt

Das ist der Kern des Prozesses. Mit etwas Übung dauert er 15 bis 30 Minuten pro Seite und erfordert keine spezielle Software außer einem Browser und dem kostenlosen Screenreader des Betriebssystems.

#	Prüfung	Wie	So sieht ein Fehler aus
1	Nur Tastatur	Legen Sie die Maus weg. Gehen Sie mit Tab durch die ganze Seite, verwenden Sie Enter, Leertaste, Pfeiltasten und Escape	Etwas ist nicht erreichbar oder bedienbar; der Fokus bleibt hängen; ein Menü lässt sich nicht schließen
2	Sichtbarer Fokus	Sehen Sie beim Tabben immer, wo Sie sind?	Der Fokus verschwindet oder liegt hinter einer fixierten Kopfzeile
3	Fokusreihenfolge	Bewegt sich der Fokus in einer sinnvollen Reihenfolge?	Springt von der Kopfzeile zur Fußzeile und zurück; ein Modal öffnet sich, aber der Fokus bleibt dahinter
4	Zoom und Reflow	Auf 200 % und 400 % zoomen; ein schmales Fenster einstellen	Abgeschnittener Text, horizontales Scrollen bei Fließtext, überlappende Elemente
5	Überschriften	Die Überschriftengliederung mit einer Browsererweiterung oder einem Screenreader anzeigen	Keine H1, übersprungene Ebenen zur Gestaltung, Überschriften, die nur fetter Text sind
6	Bilder	Den Alternativtext ohne Kontext lesen	„image1.jpg“, „Foto“ oder die Beschreibung eines dekorativen Schnörkels; informative Diagramme ohne Textäquivalent
7	Links und Schaltflächen	Alle Links auflisten; ergeben sie für sich allein Sinn?	Zehn Links mit „Hier klicken“ oder „Mehr erfahren“
8	Formulare	Leer absenden, dann mit falschen Werten absenden	Fehler nur in Rot, nicht angesagt oder nicht mit dem Feld verknüpft; Beschriftungen, die beim Tippen verschwinden
9	Screenreader-Durchgang	Den Screenreader einschalten und die Hauptaufgabe der Seite erledigen	Unbeschriftete Schaltflächen, doppelt angesagte Inhalte, nicht angesagte dynamische Änderungen
10	Bewegung und Medien	Videos abspielen, Animationen ansehen	Keine Untertitel, automatisch startende Bewegung ohne Pause, Blinken
11	Abhängigkeit von Farbe	Ergäbe die Seite in Graustufen noch Sinn?	Pflichtfelder oder Status nur durch Farbe gekennzeichnet
12	Dokumente	Jedes verlinkte PDF oder Office-Dokument in der Stichprobe öffnen	Gescannte Textbilder, keine Tags, keine Lesereihenfolge

Unsere Checkliste zur Website-Barrierefreiheit geht Kriterium für Kriterium vor, wenn Sie die ausführliche Version möchten. Die obige Tabelle ist die Version, die Menschen tatsächlich jede Woche durchführen.

Schritt 3: Probleme so protokollieren, dass sie behoben werden

Ein gutes Ticket ist eines, das ein Entwickler oder Redakteur ohne Rückfrage beheben kann. Verwenden Sie für jedes Problem dieselbe Vorlage.

Feld	Beispiel
Wo	Vorlage: Veranstaltungsseite. URL: /events/summer-concert
Was passiert	Das Menü „Zum Kalender hinzufügen“ öffnet sich mit Enter, lässt sich aber nicht mit Escape schließen; der Fokus bleibt darin
Wen es betrifft	Tastatur- und Screenreader-Nutzer
Kriterium	WCAG 2.1.2 Keine Tastaturfalle
Schweregrad	Blocker / Schwer / Gering (Definitionen unten)
Reproduktion	Mit Tab zu „Zum Kalender hinzufügen“, Enter drücken, Escape drücken
Lösungsvorschlag	Menü mit Escape schließen und den Fokus auf die auslösende Schaltfläche zurücksetzen
Zuständig	Frontend-Entwickler (Vorlage) oder Redakteur (Inhalt)

Definitionen der Schweregrade halten Diskussionen kurz:

Blocker: Jemand kann eine Aufgabe nicht erledigen. Vor dem Release beheben; ist es bereits live, diese Woche beheben.
Schwer: Die Aufgabe ist möglich, aber deutlich schwieriger. Im nächsten Release beheben.
Gering: Störend, aber nicht blockierend. Beheben, wenn die Seite das nächste Mal bearbeitet wird.

Trennen Sie Probleme nach Zuständigkeit. Fehler in Vorlagen und Komponenten gehen an Entwickler und werden einmal behoben. Inhaltsprobleme (Alternativtext, Überschriften, Linktexte, Dokumente) gehen an die Abteilung, der die Seite gehört. Werden beide in einer Warteschlange gemischt, bleiben Inhaltsprobleme ein Jahr lang liegen.

Schritt 4: Eine Schranke vor die Veröffentlichung setzen

Tests nach der Veröffentlichung messen nur den Schaden. Die günstigste Korrektur ist die, die erfolgt, bevor eine Seite online geht. Drei Schranken, von der leichtesten zur stärksten:

Selbstprüfung durch Redakteure. Eine fünfzeilige Checkliste in der Redakteursschulung: Überschriften in korrekter Reihenfolge, aussagekräftiger Alternativtext, beschreibende Links, keine neuen PDFs, wo eine Seite genügt, Untertitel bei Videos.
Automatisierte Prüfung beim Speichern. Unterstützt Ihre Plattform oder Pipeline das, lassen Sie einen Scanner über geänderte Seiten laufen und zeigen Sie dem Redakteur die Ergebnisse.
Prüfung vor dem Livegang. Eine geschulte prüfende Person sieht sich neue Seiten, neue Websites und größere Änderungen an, bevor sie veröffentlicht werden. Diese Schranke fängt die Probleme ab, die Tools nicht finden.

Bei Organisationen mit vielen Websites unterscheiden sich Plattformen bei der dritten Schranke. Bei We.Inc kann eine Organisation jede Website so einstellen, dass die Veröffentlichung eine einstufige Freigabe erfordert, bevor die Website online geht, und die Anfrage landet in einer Freigabewarteschlange. Das testet die Barrierefreiheit nicht für Sie; es gibt Ihrer prüfenden Person einen festen Zeitpunkt dafür.

Markenweite Standardeinstellungen mit dem Titel Was Ihre Kunden dürfen, mit Schaltern für jede Berechtigung und einer Teamliste — Standardberechtigungen für jede Website der Organisation, einmal festgelegt.

Eine Freigabewarteschlange mit einer Website und den Schaltflächen Freigeben und veröffentlichen sowie Änderungen anfordern — Eine prüfende Person kann freigeben oder Änderungen anfordern. Die gezeigte Anfrage wurde für den Screenshot angelegt; der Bildschirm ist das echte Produkt.

Der visuelle Editor mit ausgewählter Überschrift und geöffneten Einstellungen für Schrift, Größe und Farbe — Redakteure ändern Überschriften und Stile in einem visuellen Editor. Überschriftenebenen und Kontrast müssen in der Prüfung dennoch kontrolliert werden.

Ein Code-Panel mit Dateibaum und dem Quelltext einer Hero-Komponente sowie einer Download-Schaltfläche — Entwickler können den Quelltext der Website lesen und herunterladen, was hilft, wenn eine Korrektur auf Vorlagenebene nötig ist.

Schritt 5: Rhythmus und Berichtswesen

Wie oft	Was	Wer
Bei jeder Änderung	Automatisierter Scan; Selbstprüfung durch Redakteure	Redakteure, Pipeline
Bei jedem Release	Manuelle 12-Punkte-Prüfung geänderter Vorlagen und Komponenten	Tester im Webteam
Monatlich	Manuelle Prüfung der Stichprobe; offene Probleme nach Schweregrad zählen	Verantwortliche Person für Barrierefreiheit
Zweimal im Jahr	Aufgabenbasierte Tests mit Menschen mit Behinderungen zu den wichtigsten Aufgaben	Verantwortliche Person für Barrierefreiheit, bezahlte Teilnehmende
Jährlich	Unabhängiges Audit gegen den gewählten Standard; Stichprobe überprüfen; Erklärung zur Barrierefreiheit aktualisieren	Externe Prüfstelle

Berichten Sie der Leitung jeden Monat zwei Zahlen: offene Blocker und offene schwere Probleme. Keinen Score. Scores aus automatisierten Tools steigen und fallen aus Gründen, die nichts mit Nutzern zu tun haben, und laden zum Schönen der Zahlen ein.

Besetzung: wer was macht

Verantwortliche Person für Barrierefreiheit. Verantwortet Prozess, Stichprobe und Problemwarteschlange. Muss in einer kleinen Organisation nicht in Vollzeit arbeiten, aber namentlich benannt sein.
Tester. Jede Entwicklerin, jeder Designer oder jede QA-Person, die in der 12-Punkte-Prüfung geschult ist. Schulen Sie mindestens zwei, damit Urlaube keine Releases aufhalten.
Redakteure. In der Selbstprüfung geschult. Die meisten Inhaltsprobleme entstehen durch wohlmeinende Redakteure, denen nie gezeigt wurde, wie Überschriften und Alternativtext funktionieren.
Teilnehmende mit Behinderungen. Bezahlt, gewonnen über lokale Behindertenorganisationen oder ein Forschungspanel, und gebeten, Aufgaben zu erledigen, nicht „die Website zu begutachten“.
Beschaffung. Jedes neue Anbieterprodukt durchläuft dieselbe manuelle Prüfung vor dem Kauf, nicht danach. Unsere Beschaffungs-Checkliste enthält Fragen, die Sie stellen sollten.

Fehler, die den Prozess zunichtemachen

Ein Overlay kaufen, statt den Code zu korrigieren. Skripte, die versprechen, eine Website automatisch barrierefrei zu machen, korrigieren das zugrunde liegende Markup nicht, und manche schaffen neue Probleme für Screenreader-Nutzer.
Das jährliche Audit als Prozess behandeln. Es ist eine Kontrolle des Prozesses.
Nur auf dem Desktop testen. Führen Sie die Tastatur- und Screenreader-Prüfungen auch auf dem Smartphone durch; viele Besucher öffentlicher Websites nutzen nur mobile Geräte.
„Konform“ von einem Anbieter ohne Nachweis akzeptieren. Fragen Sie, wie getestet wurde, gegen welche Version, und lassen Sie sich die Ergebnisse zeigen. Keine Plattform, auch unsere nicht, kann versprechen, dass die Inhalte, die Ihr Team hinzufügt, barrierefrei sind.

Wenn Sie viele Websites betreiben und vor jede einen Prüfschritt setzen möchten, vereinbaren Sie eine Demo, und wir zeigen Ihnen die Freigabe- und Berechtigungseinstellungen an einer echten Marke.

Quellen

Zuletzt geprüft am 2026-10-25.

W3C WAI, Evaluating Web Accessibility Overview (Tools allein können Konformität nicht feststellen; WCAG-EM).
W3C, Web Content Accessibility Guidelines (WCAG) 2.2 (4.1.1 Parsing überholt und entfernt).
ADA.gov, Fact Sheet: Title II web and mobile app rule (WCAG 2.1 AA; geänderte Stichtage).

Dieser Leitfaden dient der allgemeinen Information und ist keine Rechtsberatung.

Häufige Fragen

Können automatisierte Tools die Barrierefreiheit allein testen?

Nein. Laut W3C kann kein Tool allein feststellen, ob eine Website Barrierefreiheitsstandards erfüllt. Automatisierte Prüfungen finden einen Teil der Probleme schnell; manuelle Prüfungen und Tests mit Menschen mit Behinderungen finden den Rest.

Wie viele Seiten sollten wir von Hand testen?

Testen Sie eine repräsentative Stichprobe statt jeder Seite: jede Vorlage, jede Komponente, die fünf bis zehn wichtigsten Aufgaben sowie einige zufällige Seiten. Ergänzen Sie die Stichprobe, wenn neue Vorlagen hinzukommen.

Sollten wir gegen WCAG 2.1 oder 2.2 testen?

Testen Sie gegen die Version, die Ihre Pflicht nennt; ADA Title II verwendet WCAG 2.1 AA. Viele Teams testen gegen WCAG 2.2 AA, das auch 2.1 AA abdeckt, mit Ausnahme des entfernten Kriteriums Parsing.

Wie sollten Barrierefreiheitsprobleme priorisiert werden?

Verwenden Sie drei Schweregrade: Blocker verhindern eine Aufgabe und werden vor dem Release behoben, schwere Probleme erschweren eine Aufgabe deutlich und werden im nächsten Release behoben, geringe Probleme werden behoben, wenn die Seite das nächste Mal bearbeitet wird.

Macht We.Inc Websites automatisch barrierefrei?

Nein. We.Inc kann eine einstufige Freigabe verlangen, bevor eine Website online geht, was Ihrer prüfenden Person einen festen Zeitpunkt zum Testen gibt; Ihr Team muss aber weiterhin jede Website testen.