Wie ein Shop geprüft wird und nach welchen Standards

Das W3C veröffentlicht die Web Content Accessibility Guidelines (WCAG 2.1, WCAG 2.2). ETSI veröffentlicht die EN 301 549. Ihr Abschnitt 9 übernimmt die Erfolgskriterien der WCAG auf den Stufen A und AA als Anforderungen an Webinhalte. Die Abschnittsnummer entsteht, indem der Nummer des Kriteriums eine 9 vorangestellt wird: Das Kriterium 1.1.1 ist Abschnitt 9.1.1.1. Ein Kriterium, das erst WCAG 2.2 hinzugefügt hat, etwa 2.5.8 Target Size (Minimum), hat nur in der EN 301 549 V4.1.1 einen Abschnitt. Das ist die Version, deren Webanforderungen an WCAG 2.2 ausgerichtet sind.

Validiscan richtet sich nach WCAG 2.2 Stufe AA, weil das die neuere Version ist und weil die EN 301 549 V4.1.1, die ETSI im September 2026 veröffentlicht hat, an sie ausgerichtet ist. Die Accessibility Guidelines Working Group des W3C, die die WCAG erarbeitet, empfiehlt Websites, WCAG 2.2 als neues Konformitätsziel zu übernehmen, auch wenn formale Verpflichtungen frühere Versionen nennen (WCAG 2.2). Die Ergebnisse werden auch nach WCAG 2.1 Stufe AA angegeben, weil das die Stufe ist, die die EN 301 549 V3.2.1 übernimmt, die Version, deren Fundstelle im Amtsblatt zur Richtlinie (EU) 2016/2102 veröffentlicht ist.

Die beiden Versionen überschneiden sich fast vollständig. Jedes Erfolgskriterium von WCAG 2.1 auf den Stufen A und AA steht auch in WCAG 2.2, außer 4.1.1 Parsing, das WCAG 2.2 gestrichen hat. WCAG 2.2 fügt auf diesen Stufen sechs Kriterien hinzu:

• 2.4.11 Focus Not Obscured (Minimum), Stufe AA
• 2.5.7 Dragging Movements, Stufe AA
• 2.5.8 Target Size (Minimum), Stufe AA
• 3.2.6 Consistent Help, Stufe A
• 3.3.7 Redundant Entry, Stufe A
• 3.3.8 Accessible Authentication (Minimum), Stufe AA

Jedes Kriterium wird einmal bewertet. Das Remediation Evidence Package zeigt die Ergebnisse dann zweimal, in einer Tabelle für WCAG 2.1 Stufe AA und in einer für WCAG 2.2 Stufe AA. Für 4.1.1 Parsing, das nur die Tabelle zu WCAG 2.1 aufführt, hält das Paket das Kriterium als unterstützt fest, mit der Begründung „Bei HTML-Inhalten immer erfüllt (WCAG 2.1 Errata)“.

Das Paket beschreibt in diesem Satz, was es abdeckt: „Konformität mit den Erfolgskriterien von WCAG 2.1 Stufe AA und WCAG 2.2 Stufe AA, geprüft auf den aufgeführten Seiten zu den angegebenen Daten.“ Außerdem heißt es dort: „Dieses Paket belegt eine Prüfung und die durchgeführten Arbeiten zur Behebung. Es ist kein Zertifikat und trifft keine Aussage über die Einhaltung gesetzlicher Vorgaben.“

Der Scanner von Validiscan lädt jede Seite in einem echten Browser (Chromium, gesteuert von Playwright) und führt darauf zwei Arten von Regeln aus: die Regeln von axe-core, einer Open-Source-Engine für automatisierte Regeln zur Barrierefreiheit, und eigene Prüfungen von Validiscan für Barrieren, die für Onlineshops typisch sind. Jeder Befund nennt seine Regel, die Elemente und Seiten, auf denen er auftritt, und die WCAG-Kriterien und Abschnitte der EN 301 549, die zu dieser Regel gehören.

Viele Erfolgskriterien der WCAG verlangen das Urteil eines Menschen. Die manuelle Checkliste von Validiscan hat 35 Punkte, jeder für ein Erfolgskriterium der Stufe A oder AA, das sich automatisiert nicht vollständig nachweisen lässt. Von den 55 Erfolgskriterien von WCAG 2.2 auf den Stufen A und AA werden 22 von keiner ausgeführten Regel getestet; sie deckt nur diese Checkliste ab. Die übrigen 33 werden von mindestens einer ausgeführten Regel getestet. Für einige davon, etwa die Bedienung per Tastatur, die Fokusreihenfolge und Untertitel, hat die Checkliste ebenfalls einen Punkt, weil eine Regel sie nur zum Teil testet. Für die übrigen hat sie keinen.

Die Checkliste verlangt unter anderem diese Prüfungen:

• der Weg in den Warenkorb allein mit der Tastatur: die Menüs, eine Produktseite, die Wahl einer Variante, das Legen in den Warenkorb, dann die Änderung einer Menge und das Entfernen eines Artikels;
• jeder Dialog und das Cookie-Banner mit der Tastatur: Der Fokus wandert hinein, Esc schließt, der Fokus kehrt zurück;
• die Suche, Produktvarianten, der Warenkorb und die Felder im Checkout mit einem Screenreader;
• Formularfehler: Sie werden angesagt, sobald sie auftreten, nennen das Feld und sagen, wie sich der Fehler korrigieren lässt;
• die Seite bei 400 % Zoom;
• Videos: Untertitel und Audiodeskription.

Die Checkliste nennt die Screenreader für diese Durchgänge: NVDA mit Chrome unter Windows und VoiceOver mit Safari auf einem Mac. Für jeden Punkt hält Validiscan „Bestanden“, „Nicht bestanden“ oder „Nicht anwendbar“ fest, mit Notizen und Belegen. Das Ergebnis entscheidet, wie das Kriterium im Remediation Evidence Package ausgewiesen wird.

Ein vollständiger Scan, der Ausgangsscan eines Projekts, lädt eine Auswahl von Seiten jedes Seitentyps im Shop, standardmäßig bis zu 150 ausgewählte Seiten: die Startseite, Produktlisten, Produktseiten und Seiten der übrigen Seitentypen, die er findet, und zusätzlich den Warenkorb, den ersten Schritt im Checkout, Suchergebnisse, die Anmelde- oder Registrierungsseite, die Kontaktseite und die Rechtstexte, wenn der Scan sie findet. Standardmäßig wird jede Seite in Desktop-Größe (1440 × 900 Pixel) und in Smartphone-Größe (390 × 844 Pixel, mit Touch-Eingabe) geladen, und alle Prüfungen laufen in beiden Größen.

Um den Warenkorb und den Checkout zu erreichen, legt der Scan ein Produkt, das auf Lager ist, in den Warenkorb, öffnet den Warenkorb und dann den ersten Schritt im Checkout. Er schließt nie einen Kauf ab und gibt nie Zahlungsdaten ein.

Ein Cookie-Banner wird zuerst als Teil der Seite getestet. Standardmäßig akzeptiert der Scan es dann, damit sich der Rest der Seite testen lässt. Bekannte Analyse-, Werbe-, Chat- und Bewertungsdienste werden bei einem Scan standardmäßig blockiert, damit die Ergebnisse nicht von ihnen abhängen. Einwilligungstools werden nicht blockiert, weil das Cookie-Banner Teil dessen ist, was getestet wird.

Validiscan scannt einen Shop vollständig nur mit der Einwilligung seiner Betreiberin oder seines Betreibers. Ein vollständiger Scan, ein Verifizierungsscan und ein Lauf des Regressionsschutzes setzen die schriftliche Einwilligung der Betreiberin oder des Betreibers des Shops voraus, festgehalten in der Anwendung von Validiscan mit dem Zeitpunkt und dem Namen der Person, die sie erfasst hat. Ohne diesen Eintrag nimmt die Anwendung den Scan nicht in die Warteschlange auf, und ein geplanter Lauf des Regressionsschutzes entfällt.

Ein vollständiger Scan befolgt standardmäßig die robots.txt des Shops. Nur bei einem Shop, für den die Einwilligung der Betreiberin oder des Betreibers erfasst ist, lässt er sich so einstellen, dass er die robots.txt ignoriert.

Der kostenlose Check läuft ohne diese Einwilligung, innerhalb fester Grenzen. Er lädt höchstens 15 Seiten, legt nie etwas in einen Warenkorb und öffnet nie den Checkout. Er befolgt die robots.txt des Hosts des Shops und lässt zwischen den Anfragen, die er selbst startet, mindestens 1 s Abstand, mit bekannten Ausnahmen: Seine erste Anfrage, für die Startseite, wird gestellt, bevor die robots.txt gelesen ist, und wenn der Shop auf das Laden einer Seite im Browser mit einer Weiterleitung antwortet, folgt der Browser ihr sofort, ohne diesen Abstand und ohne die robots.txt zu prüfen. Die Seite zum kostenlosen Check beschreibt jede Grenze und jede Ausnahme.

Automatisierte Prüfungen finden nur einen Teil aller Barrieren, und ein Scan beschreibt die Seiten, die er geladen hat, an den Tagen, an denen er lief. Das Remediation Evidence Package gibt seine eigenen Einschränkungen aus. Die folgende Liste nennt außerdem Lücken, die Validiscan in seinem Scanner festgehalten und noch nicht geschlossen hat.

• Automatisierte Prüfungen weisen nur einen Teil der WCAG nach. Eine Regel kann nicht beurteilen, ob eine Textalternative ihr Bild beschreibt, ob eine Fehlermeldung Sinn ergibt, wenn sie vorgelesen wird, oder ob Untertitel stimmen. Die manuelle Checkliste deckt die letzten beiden ab. Die Qualität von Textalternativen hat heute keinen Punkt auf der Checkliste, daher beruht das Ergebnis „Unterstützt“ für 1.1.1 Non-text Content allein auf automatisierten Prüfungen. Die Fehler, die ein Scan meldet, sind eine Untergrenze, keine Gesamtzahl.
• Die Seiten sind eine Stichprobe. Ein Scan prüft eine Auswahl von Seiten jedes Seitentyps. Von anderen Seiten aus denselben Templates wird erwartet, dass sie sich gleich verhalten; einzeln geprüft werden sie nicht.
• Ein Scan ist eine Momentaufnahme. Die Ergebnisse beschreiben den Shop zum Zeitpunkt der Scans. Spätere Änderungen am Theme, an Apps oder an Inhalten sind erst mit dem nächsten Scan abgedeckt; der Regressionsschutz scannt den Shop nach Zeitplan erneut.
• Der Checkout endet bei seinem ersten Schritt. Es wird keine Bestellung aufgegeben, und es werden keine Zahlungsdaten eingegeben, daher werden die späteren Schritte des Checkouts nicht automatisch getestet.
• Frames anderer Herkunft und geschlossenes Shadow DOM. Inhalte in Frames anderer Herkunft (Cross-Origin) und in geschlossenem Shadow DOM, etwa Zahlungsfelder sowie einige Einwilligungstools und Widgets, werden nicht automatisch geprüft. Die Prüfung des Cookie-Banners von Validiscan bewertet kein Banner, das in Shadow DOM oder in einem Frame anderer Herkunft liegt.
• Blockierte Dienste werden nicht getestet. Die Analyse-, Werbe-, Chat- und Bewertungsdienste, die ein Scan blockiert, werden nicht getestet. Auch die Korrektur eingebundener Dienste von Drittanbietern, etwa für Zahlung und Chat, gehört nicht zu einem Projekt.
• Ergebnisse, die eine Nachprüfung brauchen, werden noch nicht gemeldet. Kann axe-core oder eine der Prüfungen von Validiscan ein Ergebnis nicht entscheiden, wird es zur Nachprüfung markiert, statt als Fehler gemeldet zu werden. Der Scanner speichert diese Ergebnisse heute nicht, daher erscheinen sie nicht als Befunde. Das betrifft Links auf PDFs und andere Dokumente, die die Dokumentenprüfung von Validiscan nur zur Nachprüfung markiert, sowie Ergebnisse zu Cookie-Banner, Fokus, Tastatur und Formularen, die eine Prüfung nicht klären konnte. Wenige der ausgeführten Regeln können deshalb heute keinen Befund erzeugen. Solange der Scanner diese Ergebnisse nicht speichert, prüft Validiscan das Cookie-Banner von Hand und hält das Ergebnis in der manuellen Checkliste fest. PDFs selbst gehören nicht zu einem Projekt.
• Screenshots zeigen den ersten Bildschirm. Der Scanner nimmt jede Seite in Bildschirmgröße auf, nicht in ihrer ganzen Länge. Ein Screenshot zu einem Befund weiter unten auf einer Seite zeigt den Seitenanfang. Solange der Scanner nicht ganze Seiten oder einzelne Elemente aufnimmt, prüft Validiscan die Abbildungen jedes Remediation Evidence Package von Hand, bevor das Paket ausgestellt wird.