Websites und Shops
WCAG 2.2: Prüfen, ob eine Website nutzbar ist
Barrierefreiheit beginnt bei einer normalen Aufgabe: Informationen finden, eine Option wählen oder eine Frage stellen. WCAG hilft, Hindernisse und Abnahmekriterien zu beschreiben. Ein Scanner-Ergebnis zeigt jedoch nicht, ob der gesamte Ablauf für unterschiedliche Menschen funktioniert.
Aufgabe und Prüfniveau festlegen
WCAG 2.2 ist ein W3C-Standard mit Kriterien auf den Stufen A, AA und AAA. Legen Sie Version und Zielstufe im Briefing fest. Die Aussage „WCAG-konform“ ersetzt keinen Abnahmebericht mit Umfang, Methode und dokumentierten Ergebnissen.
Wählen Sie typische Ansichten und vollständige Aufgaben: Navigation, Suche, Produkt, Warenkorb und Kontakt. Berücksichtigen Sie Fehler, Bestätigungen, externe Komponenten und Mobilgeräte. Screenshots allein zeigen nicht, ob Besucher von einem Zustand zum nächsten gelangen können.
Die vier Prinzipien an einer echten Aufgabe prüfen
WCAG ordnet Anforderungen den Prinzipien wahrnehmbar, bedienbar, verständlich und robust zu. Übersetzen Sie diese Begriffe in Fragen zu einem konkreten Kundenprozess. Kann die Person Informationen aufnehmen, eine Variante wählen und fortfahren? Versteht sie Bedingungen und Fehlermeldungen? Erhalten Browser und assistive Technik passende Namen, Rollen und Zustände? Ein attraktiver Bildschirm im Designprogramm beantwortet nicht jede Frage. Für die Bewertung brauchen Sie funktionierende Abläufe mit echten Inhalten, einschließlich der Situationen, in denen eine Eingabe nicht akzeptiert wird oder eine Verbindung ausfällt.
Beispiel: Ein Anmeldeformular ist gut lesbar, blendet nach der Terminwahl jedoch ein unverständlich beschriftetes Feld ein. Eine Person mit Screenreader erkennt die Veränderung möglicherweise nicht. Eine andere sieht eine Fehlermeldung ausschließlich in einer Farbe, die sie nicht unterscheiden kann. Beide Barrieren betreffen dieselbe Aufgabe, benötigen aber unterschiedliche Korrekturen. Beschreiben Sie zuerst Aufgabe und erwartetes Ergebnis, danach die technischen Kriterien. Angaben zum Code helfen der Entwicklung. Die Auswirkung erklärt dem Auftraggeber den Handlungsbedarf und ermöglicht eine sinnvolle Abnahme der späteren Verbesserung.
Beim Wechsel von WCAG 2.1 auf 2.2 gezielt prüfen
Version 2.2 ergänzt neun Erfolgskriterien gegenüber 2.1 und entfernt 4.1.1 Parsing. Die Anforderungen gehören zu A, AA oder AAA. Wer nur die Neuerungen prüft, hat noch kein vollständiges Audit durchgeführt. Bereits vorhandene Kontrast- oder Tastaturprobleme bleiben relevant. Halten Sie Version, Zielniveau, Sprachen, Prozesse und Testumgebungen im Auftrag fest. Die pauschale Formulierung, eine Website solle WCAG entsprechen, beschreibt weder die konkrete Arbeit noch die spätere Bewertung ausreichend. Auftraggeber und Prüfer benötigen dieselbe Vorstellung vom vereinbarten Umfang.
Besondere Aufmerksamkeit verdienen feststehende Leisten, kleine benachbarte Bedienelemente, Ziehbewegungen und Anmeldung. Kriterium 2.5.8 nennt auf AA eine Mindestgröße von 24 × 24 CSS-Pixeln mit festgelegten Ausnahmen, unter anderem zum Abstand. Daraus folgt nicht, jeden Button exakt an dieser Grenze zu gestalten. Beispiel: Ein kleines Löschsymbol neben der Mengenerhöhung benötigt zusätzlich eine praktische Prüfung auf dem Telefon. Berücksichtigen Sie das Risiko, versehentlich die entgegengesetzte Funktion auszulösen. Sichtbare Symbolgröße und tatsächlich anklickbare Fläche sind dabei unterschiedliche Eigenschaften, die bei der Kontrolle getrennt betrachtet werden sollten.
| Kriterium | Thema | Stufe |
|---|---|---|
| 2.4.11 | Fokus unverdeckt - Mindestanforderung | AA |
| 2.4.12 | Fokus unverdeckt - erweitert | AAA |
| 2.4.13 | Fokusdarstellung | AAA |
| 2.5.7 | Ziehbewegungen | AA |
| 2.5.8 | Zielgröße - Mindestanforderung | AA |
| 3.2.6 | Konsistente Hilfe | A |
| 3.3.7 | Wiederholte Eingabe | A |
| 3.3.8 | Zugängliche Authentifizierung - Mindestanforderung | AA |
| 3.3.9 | Zugängliche Authentifizierung - erweitert | AAA |
Menü, Dialog und Formular ohne Maus durchgehen
Laden Sie die Seite neu und legen Sie die Maus weg. Wechseln Sie mit Tab vorwärts und mit Shift+Tab zurück. Beobachten Sie sichtbaren Fokus, Reihenfolge und eine Möglichkeit, wiederkehrende Navigation zu überspringen. Öffnen Sie das Menü, erweitern Sie Optionen und erreichen Sie den Kontakt. Prüfen Sie, ob Bedienelemente eines geschlossenen Bereichs versehentlich weiterhin erreichbar bleiben. Verwenden Sie auch ein niedriges Browserfenster. Eine feste Fußleiste kann genau den aktiven Button verdecken. Kriterium 2.4.11 behandelt die vollständige Überdeckung fokussierter Komponenten durch vom Anbieter erzeugte Inhalte.
Dokumentieren Sie bei einem Dialog Ausgangspunkt, Schließen und Rückkehr des Fokus. Ein Kreuz, das wie ein Button aussieht, genügt nicht als Nachweis. Erreichen Sie alle Felder, erzeugen Sie einen Fehler und korrigieren Sie ihn ohne Maus. Falls Ziehen erforderlich ist, prüfen Sie eine Alternative ohne Ziehbewegung. W3C beschreibt dies in 2.5.7 mit Ausnahmen für wesentliche Handlungen und unveränderte Browserfunktionen. Tastaturbedienbarkeit erfüllt nicht automatisch alle Anforderungen an Zeigerbedienung. Erfassen Sie deshalb beide Wege, statt eine erfolgreiche Eingabemethode als Beweis für sämtliche anderen zu behandeln.
Kontrast, Vergrößerung und Reihenfolge untersuchen
Kriterium 1.4.3 verlangt für gewöhnlichen Text mindestens 4,5:1 Kontrast und für großen Text 3:1, jeweils mit beschriebenen Ausnahmen. Messen Sie das tatsächliche Paar aus Vordergrund und Hintergrund, auch auf Bildern, im dunklen Modus und bei Fehlern. Eine auf Weiß geeignete Farbe kann an anderer Stelle ungeeignet sein. Ordnen Sie Messwerte ihrer realen Verwendung zu. Logos und dekorativer Text werden unter anderen Bedingungen beurteilt als ein Absatz über eine Leistung. Eine einheitliche Entscheidung für jedes Element wäre daher nicht zuverlässig.
Prüfen Sie den Aufbau auch bei einer Breite entsprechend 320 CSS-Pixeln. Für Inhalte, die zwei Dimensionen benötigen, etwa bestimmte Tabellen, bestehen beim Reflow Ausnahmen. Praktisch geht es darum, einen Absatz ohne ständiges seitliches Verschieben lesen zu können. Eine Tabelle darf gegebenenfalls lokal scrollbar sein, sollte jedoch nicht unnötig die ganze Website verbreitern. Untersuchen Sie Überschriften, Beschriftungen und Lesereihenfolge. Ändern Spalten auf dem Telefon ihre Anordnung, muss die Erklärung weiterhin stimmen. Vergrößerter Text darf einen Button nicht zu einem abgeschnittenen, nur aus der Umgebung erratbaren Wortfragment machen.
Bilder und Meldungen im Zusammenhang bewerten
Eine Textalternative muss zur Funktion des Bildes passen. Der W3C-Entscheidungsbaum unterscheidet Dekoration, Information und Bilder als Bedienelemente. Ein Rechnungsausschnitt in einer Anleitung kann das bezeichnete Feld erklären müssen. Eine Papierstruktur hinter einer Überschrift liefert dagegen keine zusätzliche Information. Ein gefülltes Alt-Attribut allein beweist keine brauchbare Beschreibung. „Bild drei“ hilft wenig, während die Wiederholung eines ganzen benachbarten Absatzes das Zuhören erschwert. Fragen Sie die Redaktion, welche Information aus dem Bild zum Fortsetzen der Aufgabe benötigt wird.
Prüfen Sie bei Formularen Beschriftungen, Hinweise vor der Eingabe und die Beschreibung des konkreten Fehlers. Das W3C-Tutorial zu Benachrichtigungen behandelt verständliche Meldungen mit Bezug zu Feldern. Eine ungültige E-Mail-Adresse sollte beispielsweise mit einer Korrekturanweisung erklärt werden und nicht nur einen roten Rand erhalten. Prüfen Sie auch Erfolgsmeldungen: Beschreiben sie eine tatsächliche Annahme oder lediglich eine Browseraktion? Testen Sie leere Eingaben, falsche Daten und Serverfehler mit Testdaten. Diese Versuche zeigen, ob Besucher einen Fehler verstehen, korrigieren und den Vorgang fortsetzen können.
Anmeldung und wiederholte Eingaben kontrollieren
Prüfen Sie beim Anmelden, ob Passwortmanager funktionieren und sich Eingaben einfügen lassen. Kriterium 3.3.8 behandelt barrierefreie Authentifizierung einschließlich Hilfsmechanismen, Alternativen und bestimmter Ausnahmen. Es verbietet nicht pauschal Passwörter. Entscheidend ist, wie eine Person den Vorgang ohne unnötiges Erinnern oder Abschreiben abschließen kann. Untersuchen Sie Registrierung, Bestätigung, erneute Anmeldung und Wiederherstellung des Zugangs. Eine Barriere kann erst im letzten Schritt auftreten. Eine zugängliche Anmeldemaske hilft wenig, wenn der Zugang später nicht wiederhergestellt werden kann oder Rückmeldungen nach einem Fehlversuch unverständlich bleiben.
Beispiel: Ein Shop erlaubt das Einfügen des Passworts, verhindert aber das Einfügen eines Bestätigungscodes und fragt die bereits angegebene Adresse erneut ab. Bewerten Sie diese Teile einzeln im tatsächlichen Prozess. Dokumentieren Sie Herkunft des Codes, notwendige Schritte und Hinweise nach einem gescheiterten Versuch. Entfernen Sie nicht einfach den Kontoschutz als vermeintliche Lösung. Wählen Sie gemeinsam mit der Sicherheitsverantwortung einen zugänglichen Weg. Sicherheit und Bedienbarkeit benötigen unterschiedliche Prüfungen, sollten jedoch bereits bei der Gestaltung zusammen besprochen werden. Die Verbesserung eines Bereichs darf den anderen nicht schwächen oder die Schwierigkeit lediglich auf einen verpflichtenden Telefonkontakt verlagern.
Befunde so schreiben, dass sie reproduzierbar sind
Ein brauchbarer Befund enthält Adresse, Seitenzustand, Umgebung, Schritte, erwartetes Ergebnis und beobachtetes Verhalten. Ergänzen Sie Auswirkung, Kriterium und Belege ohne Kundendaten. Ein Beispiel lautet: Nach dem Öffnen der Lieferauswahl per Tastatur lässt sich das Formular nicht mehr erreichen, deshalb kann die Bestellung nicht fortgesetzt werden. Das hilft mehr als die Bezeichnung „ARIA-Fehler“. Entwicklung und Abnahme müssen wissen, was zu korrigieren und wie die Verbesserung zu prüfen ist. Ein Screenshot kann helfen, zeigt aber häufig nicht die auslösende Interaktion.
Priorisieren Sie nach Auswirkung und Reichweite. Ein gemeinsames Menü betrifft viele Seiten, ein einzelner Zahlungsfehler möglicherweise den wichtigsten Prozess. Gruppieren Sie wiederkehrende Probleme und behalten Sie konkrete Beispiele. Wiederholen Sie nach der Korrektur die abhängige Aufgabe sowie andere Verwendungen der Komponente. Schließen Sie einen Befund nicht allein deshalb, weil der Code geändert wurde. Unterscheiden Sie korrigierte, offene und ungeprüfte Bereiche. Nicht geprüft bedeutet nicht fehlerfrei. Aus dem Bericht sollte hervorgehen, welche Kundenaufgaben funktionieren und welche weiterhin blockiert sind.
Barrierefreiheit im Veröffentlichungsprozess erhalten
Erstellen Sie nach dem Audit kurze Arbeitsregeln für Redaktion und Gestaltung: Linkbezeichnungen, Bildbeschreibungen, Feldnamen und neue Komponentenvarianten. Kehren Sie vor Änderungen an Warenkorb, Menü oder externem Widget zu dokumentierten Aufgaben zurück. Automatisierung unterstützt wiederholbare Prüfungen, ersetzt aber keine menschliche Bewertung. Beziehen Sie nach Möglichkeit Menschen mit Behinderungen in aufgabenbezogene Tests ein. Ihre Teilnahme ist kein automatisches Zertifikat für die gesamte Website. Sie liefert Erkenntnisse über konkrete Tätigkeiten und Barrieren, die bei Codeprüfung oder Betrachtung einer statischen Oberfläche übersehen werden können.
Beginnen Sie mit einem wichtigen Kundenprozess, einer Testumgebung und einer verantwortlichen Person für Korrekturen. Vereinbaren Sie Prüfumfang und Bericht vor der Beauftragung. Nennen Sie DigiDraft bei der Kontaktaufnahme Adresse, wesentliche Aufgaben, externe Module und bekannte Schwierigkeiten. Daraus lässt sich eine passende Untersuchung ableiten. Rechtliche Anforderungen sind für die Unternehmenssituation gesondert zu bestimmen. WCAG ist ein technischer Standard; ein positives Werkzeugergebnis oder eine Erklärung bestätigt nicht sämtliche gesetzlichen Pflichten. Das nützliche Ergebnis besteht aus einem funktionierenden Prozess, dokumentierten Korrekturen und einem Verfahren, das wiederkehrende Barrieren nach späteren Änderungen erkennt.
Fragen und Antworten
Belegt ein gutes Scanner-Ergebnis die Konformität mit WCAG 2.2?
Es belegt keine Konformität der gesamten Website. Ein Scanner erkennt einen Teil der Probleme; zusätzlich sind manuelle Tests von Aufgaben, Fehlerzuständen und der Nutzung assistiver Technologien nötig. Der Bericht sollte WCAG-Version, Konformitätsstufe, Prüfumfang und Methode nennen.
Wie beginne ich einen Tastaturtest der Website?
Legen Sie die Maus beiseite und gehen Sie mit Tab durch Menü, Schaltflächen und Formular; mit Shift+Tab gelangen Sie zurück. Prüfen Sie, ob der Fokus sichtbar ist, sich Dialoge öffnen und schließen lassen und Formularfehler korrigierbar sind. Notieren Sie, wo sich eine Aufgabe nicht abschließen lässt.
Was gehört in eine Meldung zu einer Barriere?
Nennen Sie Adresse, Testumgebung, Schritte, erwartetes Verhalten und tatsächliches Ergebnis. Beschreiben Sie die Auswirkung, etwa dass eine Lieferart nicht ausgewählt werden kann. Wiederholen Sie nach der Korrektur den gesamten Ablauf und prüfen Sie nicht nur das geänderte Element.