Barrierefreier Checkout: Formulare nach WCAG prüfen

In der Kasse entscheidet sich, ob ein Kauf zustande kommt. Dort stehen die Eingabefelder, an denen der Vertrag hängt, und § 19 BFSGV nennt Zahlungs- und Authentifizierungsfunktionen ausdrücklich. Dieser Beitrag ordnet die Erfolgskriterien der WCAG 2.1, an denen ein Formular hängt, zeigt eine Fehlermeldung, die auch ohne Farbe funktioniert, und trennt, was ein automatischer Scan an der Kasse prüfen kann und was nur ein Test von Hand beantwortet.

Warum die Kasse im BFSG eine eigene Rolle hat

Das BFSG selbst nennt kein Formularfeld. Es erlaubt dem Dienstleistungserbringer, seine Dienstleistung nur anzubieten, wenn sie die Barrierefreiheitsanforderungen der Rechtsverordnung erfüllt (§ 14 Abs. 1 Nr. 1 BFSG). Barrierefrei heißt nach § 3 Abs. 1 Satz 2 BFSG: für Menschen mit Behinderungen in der allgemein üblichen Weise, ohne besondere Erschwernis und grundsätzlich ohne fremde Hilfe auffindbar, zugänglich und nutzbar.

Die Verordnung dazu ist die BFSGV. § 12 Nr. 3 BFSGV verlangt, dass Webseiten samt Online-Anwendungen wahrnehmbar, bedienbar, verständlich und robust gestaltet werden. § 19 Nr. 2 BFSGV legt für den elektronischen Geschäftsverkehr nach: Identifizierungs-, Authentifizierungs-, Sicherheits- und Zahlungsfunktionen, die im Rahmen der Dienstleistung bereitgestellt werden, müssen denselben vier Merkmalen genügen. Anmeldung und Zahlungsschritt fallen damit ausdrücklich darunter. Was die Verordnung sonst verlangt, steht in Was die BFSGV konkret vom Onlineshop verlangt.

Die Erfolgskriterien, an denen ein Formular hängt

Kein einzelnes Kriterium heißt „Formular“. Die Anforderungen verteilen sich über alle vier Prinzipien. Die Tabelle ordnet die Kriterien der Stufen A und AA, die in einer Kasse regelmäßig greifen, nach dem Ort, an dem sie sichtbar werden.

Für 4.1.2 hält die WCAG selbst einen Hinweis bereit, der Arbeit spart: Standard-Bedienelemente von HTML erfüllen das Kriterium bereits, wenn sie nach Spezifikation eingesetzt werden. Aufwendig wird es erst bei nachgebauten Elementen, etwa einer Länderauswahl aus div-Blöcken oder einem Kontrollkästchen, das nur ein gestaltetes Bild ist. Solche Bauteile brauchen Name, Rolle und Zustand von Hand, und jede Aktualisierung des Designs kann sie wieder verlieren.

Zwei Stellen verdienen einen zweiten Blick. Die erste ist der Platzhalter: Er steht grau im Feld und verschwindet, sobald jemand tippt. Wer seine Eingabe danach prüfen will, sieht nicht mehr, wofür das Feld war. Als alleinige Beschriftung taugt er deshalb nicht.

Die zweite ist 1.3.5. Das Kriterium gilt nur für Felder, die Angaben über den Nutzer erfragen, und nur für die Zwecke, die WCAG 2.1 in Abschnitt 7 aufzählt. Im HTML geschieht das über das Attribut autocomplete, etwa mit dem Wert postal-code für die Postleitzahl. Ob ein Feld Daten über die ausfüllende Person aufnimmt, entscheidet sein Zweck und nicht sein Aussehen.

Fehlermeldungen, die auch ohne Farbe ankommen

Manche Barriere einer Kasse zeigt sich erst nach dem Klick auf „Weiter“. Ein Feld färbt sich rot, und nichts sonst passiert. Für Menschen, die Rot und Grün nicht unterscheiden, und für Screenreader-Nutzer ist damit kein Fehler passiert. Hier greifen mehrere Kriterien gleichzeitig: 1.4.1 verbietet Farbe als einziges visuelles Mittel, 3.3.1 verlangt, den Fehler zu benennen und in Text zu beschreiben, und 3.3.3 verlangt einen Korrekturvorschlag, wenn er bekannt ist.

Die WCAG schreiben keine bestimmte Technik vor. Ob die Meldung neben dem Feld steht, oben in einer Fehlerliste mit Sprungmarken oder beides, ist eine Gestaltungsfrage. Verlangt ist das Ergebnis: Der Fehler ist als Text wahrnehmbar und dem Feld zuzuordnen.

Eine Falle liegt in der letzten Zeile der Grafik. Zeigt aria-describedby auf eine id, die es nicht gibt, bleibt die Meldung stumm, obwohl sie sichtbar dasteht. Wer die Fehlerbausteine zur Laufzeit erzeugt, vergibt die id oft erst beim Einblenden und den Verweis schon beim Laden.

Vor dem Kaufknopf: Fehlervermeidung und Zeitlimits

Der Knopf „Zahlungspflichtig bestellen“ löst eine rechtliche Verpflichtung und eine Zahlung aus. Für solche Seiten verlangt 3.3.4, dass mindestens eine von drei Bedingungen erfüllt ist: Die Übermittlung ist umkehrbar, die Eingaben werden auf Fehler geprüft und können korrigiert werden, oder es gibt vor dem Abschluss einen Weg, alles zu prüfen, zu bestätigen und zu berichtigen. Eine Übersichtsseite vor dem Kaufknopf erfüllt die dritte Bedingung, sofern sich von dort jede Angabe noch ändern lässt.

Daneben läuft oft eine Uhr, die niemand sieht: die Sitzung. Legt der Shop selbst ein Zeitlimit fest, verlangt 2.2.1, dass es sich abschalten oder auf mindestens das Zehnfache der Voreinstellung verstellen lässt, oder dass vorher gewarnt wird und die Verlängerung mit einem einfachen Handgriff möglich ist. Wer mit Sprachausgabe eine Anschrift eingibt, braucht dafür länger als der Durchschnitt, für den das Limit einmal eingestellt wurde.

Praxisbeispiel: eine Kasse in vier Schritten prüfen

Ein erfundenes Beispiel mit plausiblen Zahlen: Ein Teeversand mit 14 Beschäftigten verkauft an Verbraucher. Die Ausnahme für Kleinstunternehmen greift nicht, denn sie verlangt weniger als 10 Beschäftigte und höchstens 2 Mio. Euro Umsatz oder Bilanzsumme. Die Kasse hat vier Schritte: Warenkorb, Anschrift, Zahlung, Prüfen und Bestellen. Warum gerade diese Seiten in den Prüfumfang gehören und nicht nur die Startseite, beschreibt Welche Seiten eines Onlineshops in die Erstprüfung gehören.

Die Inhaberin legt die vier Adressen in BarriereRadar als Bestellstrecke an. Der Streckenlauf prüft jede Adresse mit demselben Regelkatalog wie ein Einzelscan, und über die Ampel der Strecke entscheidet der schlechteste Schritt. Ein Mittelwert würde eine Kasse grün färben, an der jemand hängen bleibt.

Die grüne Zeile ist die lehrreichste. Der Abruf liest den ausgelieferten Quelltext ohne JavaScript, ohne Anmeldung und ohne Warenkorb. Die Übersichtsseite zeigte deshalb „Ihr Warenkorb ist leer“, und an einem leeren Warenkorb gibt es kein Feld, das fehlschlagen könnte. Das Team öffnet die Seite deshalb mit echtem Inhalt im Browser, kopiert das Dokument aus dem Entwicklerwerkzeug und fügt es in den Schnellscan ein, der bis 100.000 Zeichen annimmt; größere Dokumente lassen sich in der App als Quelltext einfügen. Der meldet jetzt, dass die Beschriftung des AGB-Kontrollkästchens auf eine id zeigt, die es nicht gibt, und das Kästchen damit ohne Beschriftung dasteht. Wer nur das Formular statt des ganzen Dokuments einfügt, bekommt zusätzlich Meldungen zu Seitentitel und Sprache, die den Ausschnitt betreffen und nicht die Seite.

Was danach bleibt, prüft kein Werkzeug aus dem Quelltext, und BarriereRadar behauptet es auch nicht:

• Tastatur: die Kasse ohne Maus durchlaufen, einschließlich Zahlungsdialog und Länderauswahl (2.1.1).
• Fehlermeldungen: jedes Pflichtfeld leer absenden und hören, was der Screenreader ansagt (3.3.1, 3.3.3).
• Statusmeldungen: einen Gutschein einlösen und prüfen, ob die Bestätigung ankommt, ohne dass der Fokus springt (4.1.3).
• Farbe: die Fehlerdarstellung in Graustufen ansehen (1.4.1).
• Eingabezweck: für jedes Feld mit Angaben über die Person den autocomplete-Wert gegen Abschnitt 7 der WCAG 2.1 abgleichen (1.3.5).

Die Grenze gilt für jeden automatisierten Scan und steht bei jedem Ergebnis dabei. Ausführlich erklärt ist sie in Was der automatisierte Barrierefreiheits-Scan prüft. Nach der Korrektur läuft die Strecke erneut. Dieser Lauf gehört auch nach jeder neuen Auslieferung der Kasse dazu, denn ein geändertes Vorlagenmodul kann eine Beschriftung wieder entfernen, ohne dass es jemand bemerkt.

Häufige Fragen

Muss der Checkout nach BFSG barrierefrei sein?

Ja, wenn das Angebot unter das BFSG fällt und keine Ausnahme greift. § 19 Nr. 2 BFSGV nennt für den elektronischen Geschäftsverkehr Identifizierungs-, Authentifizierungs-, Sicherheits- und Zahlungsfunktionen ausdrücklich. Die Ausnahme für Kleinstunternehmen gilt nur für Dienstleister mit weniger als 10 Beschäftigten und zugleich höchstens 2 Mio. Euro Umsatz oder Bilanzsumme.

Reicht ein Platzhalter als Beschriftung für ein Formularfeld?

Als alleinige Beschriftung taugt ein Platzhalter nicht. Er verschwindet, sobald jemand tippt, und wer seine Eingabe prüfen will, sieht nicht mehr, wofür das Feld war. Verlässlich sind ein sichtbares label, das mit dem Feld verknüpft ist, oder ein label, das das Feld umschließt.

Was verlangt WCAG bei Fehlermeldungen im Formular?

Ein automatisch erkannter Fehler muss benannt und in Text beschrieben werden (3.3.1, Stufe A). Ist eine Korrektur bekannt, wird sie vorgeschlagen, sofern das Sicherheit oder Zweck nicht gefährdet (3.3.3, Stufe AA). Eine rote Umrandung allein genügt nicht, weil Farbe nicht das einzige visuelle Mittel sein darf (1.4.1).

Kann ein automatischer Scan den Checkout vollständig prüfen?

Nein. Ein Scan des Quelltextes findet fehlende Beschriftungen, Schaltflächen ohne Namen und Verweise ins Leere. Ob Fehlermeldungen angesagt werden, ob die Kasse mit der Tastatur bedienbar ist und ob ein Feld Angaben über den Nutzer erfragt, zeigt erst ein Test von Hand mit Tastatur und Screenreader.

Das Wichtigste in Kürze

Dieser Beitrag ersetzt keine Rechtsberatung. Eine automatisierte Erstprüfung ersetzt nicht den vollständigen BITV-/WCAG-Test – maßgeblich sind BFSG, BFSG-Verordnung und die harmonisierte Norm EN 301 549 in ihrer aktuellen Fassung.