Barrierefreiheit einer Website nach WCAG testen, Schritt für Schritt

Eine Website nach WCAG zu testen heißt, sie anhand der Erfolgskriterien der Web Content Accessibility Guidelines zu prüfen, meist auf Stufe AA. Kein einzelnes Werkzeug schafft das allein. Ein verlässlicher Test verbindet einen automatischen Test mit manuellen Tests durch einen Menschen mit Tastatur, Browser-Zoom und Screenreader. Hier ist der Ablauf, den wir Shops, Dienstleistern und Agenturen empfehlen – in der Reihenfolge, die mit dem geringsten Aufwand die meisten Probleme findet.

Das ist eine allgemeine Information, keine Rechtsberatung. Unsere eigenen Tests sind eine automatische Prüfung, kein vollständiges Audit.

Schritt 0: Festlegen, was Sie testen (Stichprobe)

Selten testet man jede Seite. Die Website Accessibility Conformance Evaluation Methodology (WCAG-EM) des W3C beschreibt fünf Schritte: Umfang festlegen, die Website erkunden, eine repräsentative Stichprobe wählen, die Stichprobe bewerten und die Ergebnisse dokumentieren. Für die Stichprobe kombiniert sie eine strukturierte Auswahl mit einigen zufällig gewählten Seiten.

Für einen Online-Shop gehören zur strukturierten Auswahl meist:

• Startseite, eine Kategorieseite, eine Produktseite, Suchergebnisse;
• jeder Schritt der Kasse, vom Warenkorb bis zur Bestätigung, weil die WCAG vollständige Prozesse verlangen;
• Anmeldung, Registrierung, Passwort zurücksetzen und das Kundenkonto;
• Kontaktformular, Hilfe und die Seite mit den Informationen zur Barrierefreiheit;
• Seiten mit besonderen Inhalten: Video, Karten, Konfiguratoren, PDFs zum Herunterladen.

Notieren Sie WCAG-Version und Stufe (zum Beispiel WCAG 2.2 AA), die genutzten Browser und assistiven Technologien und das Datum. Das brauchen Sie für Ihre Barrierefreiheitserklärung.

Schritt 1: automatischer Test

Beginnen Sie mit einem automatischen Werkzeug. Es ist schnell, wiederholbar und gut bei Problemen im Code: fehlende Alternativtexte, zu geringer Textkontrast, Formularfelder ohne Beschriftung, Buttons und Links ohne Namen, fehlende Sprachangabe, ungültiges ARIA, zu kleine Klickflächen.

• Testen Sie eine Seite kostenlos mit unserem WCAG-Check oder jede Seite der Website mit einem Pandus-Tarif.
• Prüfen Sie Seiten hinter einem Login, den Warenkorb und die Kasse mit unserer Browser-Erweiterung.
• Andere Werkzeuge vergleicht die Seite Barrierefreiheit-Test-Tools.

Beheben Sie zuerst die automatischen Funde. Meist sind es Probleme der Vorlage: Eine Korrektur im Theme beseitigt denselben Fehler auf Hunderten Seiten. Machen Sie danach mit den manuellen Schritten weiter – Studien sind uneins, wie groß der Anteil der Probleme ist, den Automatik findet, aber einig darin, dass es nicht alle sind.

Schritt 2: Tastaturbedienung testen

Legen Sie die Maus weg und nutzen Sie nur die Tastatur:

Prüfen Sie, ob:

1. alles per Tastatur funktioniert – Menü, Filter, Produktoptionen, In den Warenkorb, Kasse, Cookie-Banner (2.1.1);
2. der Fokus nirgends hängen bleibt, etwa in einem Pop-up, Chat-Widget oder eingebetteten Player (2.1.2);
3. der Fokus immer sichtbar ist (2.4.7) und nicht verdeckt wird von Sticky Headern oder Bannern (2.4.11);
4. die Reihenfolge Sinn ergibt und der sichtbaren Reihenfolge folgt (2.4.3);
5. ein Sprunglink oder Landmarks das Überspringen des Menüs erlauben (2.4.1);
6. Dialoge beim Öffnen den Fokus aufnehmen und ihn beim Schließen zurückgeben.

Schritt 3: Zoom, Umbruch und Textabstand

1. Zoomen Sie den Browser auf 200 %: kein abgeschnittener Text, nichts überlappt, alles bleibt bedienbar (1.4.4).
2. Zoomen Sie auf 400 % oder machen Sie das Fenster 320 CSS-Pixel breit: Text bricht um, zum Lesen ist kein horizontales Scrollen nötig (1.4.10).
3. Wenden Sie größere Textabstände an: nichts wird abgeschnitten (1.4.12).
4. Drehen Sie ein Smartphone: Die Seite funktioniert im Hoch- und im Querformat.

Mehr zu Größen in WCAG und Schriftgröße.

Schritt 4: mit dem Screenreader testen

Ein Screenreader zeigt, ob die Seite auch ohne Hinsehen Sinn ergibt. Nutzen Sie mindestens eine Desktop- und eine mobile Kombination:

• NVDA (kostenlos, Windows) mit Firefox oder Chrome;
• VoiceOver (in macOS und iOS eingebaut) mit Safari;
• TalkBack (in Android eingebaut) mit Chrome.

Achten Sie auf:

• einen aussagekräftigen Seitentitel und eine Überschriftenstruktur, durch die Sie springen können (1.3.1);
• Bildbeschreibungen, die das Wesentliche sagen (1.1.1);
• Buttons und Links, die sagen, was sie tun – „In den Warenkorb“, nicht „Schaltfläche“ (4.1.2);
• Statusmeldungen wie „Zum Warenkorb hinzugefügt“ oder „3 Ergebnisse“, die angesagt werden, ohne den Fokus zu verschieben;
• Beschriftungen, Pflichtfelder und Fehler in Formularen, die zusammen mit dem Feld vorgelesen werden.

Lernen Sie zuerst die Grundbefehle: nächste Überschrift, nächster Link, nächstes Formularfeld, alles vorlesen. So navigieren Screenreader-Nutzer, nicht Zeile für Zeile.

Schritt 5: Formulare und Kasse

Gehen Sie jedes Formular durch und machen Sie absichtlich Fehler:

• jedes Feld hat eine sichtbare Beschriftung, nicht nur einen Platzhalter;
• Fehler werden im Text neben dem Feld beschrieben, mit einem Hinweis zur Korrektur (3.3.1);
• bereits eingegebene Daten werden nicht erneut abgefragt (3.3.7);
• die Anmeldung erlaubt Passwortmanager und Einfügen, und Rätsel haben eine Alternative (3.3.8);
• die autocomplete-Attribute für Name, E-Mail, Adresse und Telefon sind gesetzt;
• Zeitlimits lassen sich verlängern, und Bestellungen lassen sich vor dem Absenden prüfen.

Schritt 6: Medien, Farbe und Bewegung

• Videos haben Untertitel (1.2.2); reine Audioinhalte haben ein Transkript.
• Nichts spielt automatisch länger als drei Sekunden Ton ab, ohne dass man es stoppen kann.
• Karussells und Animationen lassen sich anhalten.
• Farbe ist nicht das einzige Signal für Fehler, Verfügbarkeit oder Links im Text.
• Text und Bedienelemente haben genug Kontrast; unklare Fälle prüfen Sie mit dem Kontrastrechner.

Schritt 7: dokumentieren und erneut testen

Halten Sie jedes Problem mit Seite, Element, WCAG-Kriterium, Screenshot und Schweregrad fest. Beheben Sie nach Wirkung: Was einen Kauf oder eine Anmeldung verhindert, kommt zuerst. Testen Sie nach jedem Release, Theme-Update oder neuen Plugin erneut – nach Änderungen kehren Barrieren oft zurück. Ein wöchentliches Monitoring fängt den automatisch prüfbaren Teil davon ab.

Wann sich ein Audit lohnt

Ihre eigenen Tests sind eine gute Routine, aber kein Audit. Ziehen Sie ein professionelles Barrierefreiheits-Audit in Betracht, wenn Sie eine Konformitätsaussage brauchen, vor einem Start oder einer öffentlichen Ausschreibung, nach einer Beschwerde oder einer Abmahnung oder wenn die Ergebnisse unklar sind. Eine Prüferin oder ein Prüfer testet alle Kriterien der Stufe von Hand, mit mehreren assistiven Technologien, und dokumentiert die Methode.

Häufige Fragen

Was ist ein WCAG-Test?

Die Prüfung einer Website anhand der Erfolgskriterien der Web Content Accessibility Guidelines. Er verbindet automatische Tests, die Probleme im Code schnell finden, mit manuellen Tests durch einen Menschen mit Tastatur, Zoom und Screenreader.

Lässt sich ein WCAG-Test vollständig automatisieren?

Nein. Automatische Werkzeuge finden nur einen Teil der Probleme. Ob ein Alternativtext sinnvoll ist, ob die Fokusreihenfolge logisch ist oder ob eine Fehlermeldung verständlich ist, beurteilt ein Mensch.

Wie teste ich die Tastaturbedienung?

Legen Sie die Maus weg. Bewegen Sie sich mit Tab und Umschalt+Tab, öffnen Sie Links mit Enter und Buttons mit Enter oder Leertaste, nutzen Sie in Menüs die Pfeiltasten und schließen Sie Dialoge mit Esc. Prüfen Sie, ob der Fokus immer sichtbar ist, einer logischen Reihenfolge folgt und nirgends hängen bleibt.

Mit welchem Screenreader sollte ich testen?

NVDA mit Firefox oder Chrome unter Windows, VoiceOver mit Safari unter macOS und iOS und TalkBack mit Chrome unter Android. Ein Test mit einem Desktop- und einem mobilen Screenreader findet die meisten Probleme.

Wie viele Seiten sollte ich testen?

Eine repräsentative Stichprobe, wie sie die WCAG-EM-Methode des W3C beschreibt: die Startseite, eine Seite jeder Vorlage, alle Schritte wichtiger Abläufe wie Kasse und Anmeldung und einige zufällig gewählte Seiten.

Wann brauche ich ein professionelles Audit?

Wenn Sie eine Konformitätsaussage brauchen, vor einem öffentlichen Start oder einer Ausschreibung, nach einer Beschwerde oder Abmahnung oder wenn Ihre eigenen Tests Fragen offenlassen. Ein Audit prüft alle Kriterien von Hand; eine automatische Prüfung tut das nicht.

Quellen

• W3C, WCAG-EM Overview: https://www.w3.org/WAI/test-evaluate/conformance/wcag-em/
• W3C, Easy Checks – A First Review of Web Accessibility: https://www.w3.org/WAI/test-evaluate/preliminary/
• W3C, WCAG 2.2: https://www.w3.org/TR/WCAG22/