Formulare

Wenn man E-Commerce auf seine wesentlichen Bestandteile herunterbricht, hat man Informationen in Textform, Bilder, die das Produkt oder die Dienstleistung beschreiben – und vor allem eines: Formulare.

E-Commerce ist noch vor dem „Web 2.0“ der Teilbereich des Webs gewesen, wo nicht nur ein Lesezugriff auf Informationen oder Medien wichtig war, sondern ab dem auch einen Rückkanal an die Betreibenden eines Webauftritts (in dem Fall: Händler oder Händlerinnen) gab. Andernfalls konnten für einen Kauf wichtige Daten nicht gesammelt werden. Zum Beispiel:

Auch zum Produkt oder zur Dienstleistung selbst kann bzw. muss der/die Kaufwillige Angaben machen, zum Beispiel die gewünschte Produktfarbe, -größe oder allgemein -variante.

All diese Informationen stellen sowohl Shop-Betreibende, als auch die Kundschaft über besondere Elemente aus dem HTML-Baukasten bereit: Eingabefelder. Diese können z. B. einfache Texteingabefelder, Textareas, Radio-Inputs, Auswahlfelder wie selects oder Checkboxen und vieles weitere sein. Diese Elemente sind für Online-Shops also zentral. Gleichzeitig werden sie sehr häufig falsch implementiert (siehe WebAim Million-Zahlen) und diese essenzielle Eingabe können unüberwindbare Barrieren für Menschen mit Behinderungen bedeuten. Oberflächen, die an entscheidender Stelle unbenutzbar oder unklar sind, dass eigentlich Interessierte den Kaufprozess abbrechen, sind selbst rein kaufmännisch betrachtet unklug, denn es hält potenzielle Kaufwillige von einem Vertragsabschluss ab oder schließt diese aus. Zudem werden in solchen Fällen auch gesetzliche Verpflichtungen zur Web-Barrierefreiheit eingehalten, woraus zusätzlich ein juristisches Problem erwachsen kann. Deswegen soll es in diesem Modul um Formularfelder und ihren richtigen, zugänglichen Einsatz gehen.

Aus der Wichtigkeit und Allgegenwart von Formularfeldern im Kontext von E-Commerce ergibt sich, dass für einen zugänglichen Webshop alle Menschen diese Elemente verstehen und wahrnehmen müssen. Denn wenn das nicht der Fall ist, kann keine Transaktion stattfinden und das E-Commerce-Projekt hat seine Hauptaufgabe verfehlt. Und wenn dies passiert, findet gleich auf vielen Ebenen gleichzeitig eine Verletzung statt: menschenrechtlich (Stichwort: UN-Behindertenrecht), europarechtlich (Stichwort: Barrierefreiheitsstärkungsgesetz bzw. EU-Richtlinie 2019/882, „European Accessibility Act“ und selbst rein betriebswirtschaftlich argumentiert (Stichwort: Ungenutztes Kund*innenpotential).

Das größte Problem beim Nichtverständnis von Eingabefeldern besteht darin, dass nicht eindeutig oder klar wird, welche Information von Menschen konkret abgefragt wird (die Aktion Mensch hat in ihrer systematischen Betrachtung der Zugänglichkeit von Webshops herausgefunden, dass im E-Commerce recht häufig ausgerechnet die Formularfelder für „Menge“ und „Größe“ nicht beschriftet sind – Seite 22 im PDF). Dazu gibt es in den Web-Standards die Möglichkeit, Eingabefelder (und übrigens auch Ausgabefelder) zu beschriften. Die Web-Barrierefreiheitsstandards WCAG gehen weiter: Bezeichnungen von Feldern sind hier keine Option, sondern eine Pflicht (Erfolgskriterien 1.3.1 und 3.3.2). Und das sowohl im rein programmatischen Sinne (der z. B. Menschen mit Sehbehinderungen und ihren Bildschirmvorleseprogrammen zu Gute kommt), als auch im Sinne der Verständlichkeit (hat ein Feld eine optisch sichtbare Beschriftung oder steht es kontextlos in der Gegend herum und verwirrt?). Schauen wir uns zunächst einmal an, wie man Eingabefelder programmatisch beschriften kann:

Für diese und die nächste Variante ist das <label>-Element zentral, das speziell für Beschriftungen von Eingabefeldern existiert. Wenn man eine sogenannte implizite Bezeichnung vornimmt, verschachtelt man das Eingabefeld im Label-Element, beispielsweise so: <label>Vorname: <input type="text" name="firstname" /></label>. Durch dieses Ineinanderschachteln der Elemente ist eine programmatische Verbindung zwischen ihnen hergestellt. Das führt dazu, dass, wenn das Eingabefeld beispielsweise von einem Screenreader-Nutzenden angesteuert wird das Feld als z. B. "Vorname, Eingabefeld" vorgestellt wird. Der oder die Nutzende erfährt, dass das Interface hier erwartet, dass ein Vorname angegeben wird. Bei Checkboxes, wie z. B. beim akzeptieren von AGB, sind Verschachtelungen bzw. implizite Labels übrigens üblich. Beispiel: <label><input type="checkbox" name="agb" /> Ich akzeptiere die AGB</label>.

Falls ein Ineinandersetzen der HTML-Elemente aus einem Grund nicht möglich ist, gibt es noch die Möglichkeit der expliziten Bezeichnung. Hierzu benötigt das zu beschriftende Eingabefeld eine eindeutige Identifikation in Form eines id-Attributes und Wertes. Das <label>-Element, das das Eingabefeld beschriften soll, bekommt dabei ein for-Attribut mit dem gleichen Wert. Mit dieser Brücke „zeigt“ das bezeichnende Element also auf das Eingabefeld und eine Assoziation zwischen beiden ist gewährleistet. Und das übrigens völlig unabhängig davon, ob <label> und zum Beispiel <input> verschachtelt oder meilenweit im Dokument voneinander entfernt sind – die Brücke zwischen beiden ist gebaut. Ein Beispiel: <label for="first-name">Vorname:</label><input type="text" id="first-name" />.

Übrigens: nur weil man mit diesem Mittel das Label völlig vom Eingabefeld lösen und riesige Abstände zwischen beiden ermöglichen kann, heißt das nicht, dass man dies auch tun sollte. Beide müssen auch optisch nachvollziehbar und vor allem zusammengehörig positioniert werden. Und, weil es häufig falsch gemacht wird, der klare Hinweis: for nimmt den Wert von id entgegen, nicht den von z. B. name.

Hinweis: In allen Fällen bedeutet eine programmatische Verbindung zwischen einen label und einem Eingabefeld (input und textarea) übrigens auch eine Verbesserung der Usability: Klickt man nämlich auf ein Label, das mit einem Feld assoziiert ist, erhält letztgenanntes den Tastaturfokus und Sie können gleich loslegen mit der Dateneingabe (probieren Sie es gerne z. B. auf dieser Seite aus!).

Soweit die reine Lehre, nun ein konkreter Ratschlag: In der Praxis ist zu empfehlen, implizite Bezeichnungen mit expliziten Verbindungen zu kombinieren, also Verschachtelung und for-/id-Brücke wie folgt zu nutzen: <label for="agreement"><input type="checkbox" name="agb" id="agreement" /> Ich akzeptiere die AGB</label>. Das Ganze ist leider nötig wegen einer bestimmten assistiven Technologie, die mit einer reinen Verschachteltung nicht klarkommt (konkret ist das die Software Dragon Speech).

Auch ein Button ist genau genommen ein Formularfeld, auch wenn er häufig ausserhalb von Formularen anzutreffen ist. Beispiel: Ein Schalter, mit dem man ein Produkt in einen Warenkorb legen kann, ist nur mit einem „Einkaufskorb“-Symbol befüllt, aber nicht durch einen sichtbaren Text beschriftet. Ein Piktogramm ist dann also einziger Inhalt des Buttons, das Bild ist als „funktional“ oder „aktiv“ anzusehen. Kritisch wird es jetzt, wenn diesen Bildern kein Alternativtext gegeben wurde oder die Bilder sogar als dekorativ markiert wurden. Damit existieren sie nämlich für Screenreader-Nutzende nicht, siehe Medien-Modul. Wenn dies nämlich der Fall ist, kann auch der Schalter keine Bezeichnung von seinem Inhalt bekommen und verbleibt schlimmstenfalls programmatisch unbeschriftet und lässt Nutzende von Hilfstechnologie im Unklaren über die Funktion des Buttons. Ein Beispiel für einen letztendlich unbeschrifteten Button: <button type="button"><img src="in-den-warenkorb.svg alt="" /></button> (Achtung: Codebeispiel ist bewusst fehlerhaft, nicht nutzen!) .

Das Problem tritt übrigens genau so nicht nur in Buttons, sondern auch in Links auf: Liegt nur ein verlinktes Icon vor (sprich: befindet sich nur ein z. B. Piktogramm in einem Link) und hat dieses dann keinen Alternativtext und hat der Link keine weiteren Beschriftungsquellen (wie visuell verborgener Text in seinem Inneren, aria-label, aria-labelledby - siehe unten - und notfalls sogar title), ist dieses Mal der Link unbeschriftet – und sein Linkzweck nicht-visuell unklar.

Auf welche Arten man Alternativtexte für „aktive“ (also funktionelle) Bilder in so einem Fall beschriftet, klärt das Medien-Modul auf. Falls eine Beschriftung über ein Bild aus irgendwelchen Gründen nicht möglich ist, gibt es noch drei weitere Methoden:

Mit einer häufig visually-hidden oder sr-only genannten CSS-Klasse können Sie Texte visuell unsichtbar (damit in einem scheinbaren Nur-Icon-Button brauchbar) gestalten. Gleichzeitig ist der Text aber vor Screenreadern immer noch vorhanden und wird von ihnen wie anderer Text auch vorgelesen. Folgende CSS-Anweisungen sind dafür nötig (es lohnt sich, eine Klasse wie die folgende als allgemeine Hilfsklasse in seinem CSS-System zu etablieren):

Der Name der CSS-Klasse muss übrigens nicht zwingend „visually-hidden“ lauten, allerdings sind Hilfsklassen dieser Art häufig als „sr-only“ oder eben mit dieser Bezeichnung ausgestattet.

Mit diesem Attribut auf z. B. einem Button, Link oder allgemein einem interaktiven Element ist es möglich, ein Element mit z. B. dem Textinhalt eines anderen (notfalls sogar visuell unsichtbaren) Elements zu beschriften. Der Ansatz ist übrigens vergleichbar mit dem for-Attribut, das eine ID oder sogar mehrere IDs entgegennehmen kann.

Beispiel: <div id="name">Nachname</div><input aria-labelledby="name" type="text" />. Wie bei allem Dingen, die mit ARIA zu tun haben, gilt hier aber: Wenn Sie die Möglichkeit haben, ARIA zu vermeiden und ein anderes, einfacheres und passenderes Element aus dem HTML-Baukasten verwenden können (wie das oben erwähnte <label>), dann machen Sie das. Der oben erwähnte Klick auf dieses Beschriftungs-Element, das programmatisch mit einem Eingabefeld verbunden ist und dann sofort den Fokus in das Feld setzt, zeigt nur einen von vielen Vorteilen, die HTML-Elemente als „Inklusivleistungen“ erbringen, aria-labelledby bringt diese Funktion nicht automatisch mit.

Für aria-label gilt vergleichbares: Vermeiden Sie ARIA, wenn Sie können. Wenn Sie allerdings keine andere Wahl haben, ermöglicht aria-label eine Beschriftung eines z. B. Formularelements oder Links per Attribut allein (der Attributwert ist keine Referenz auf eine ID, sondern eine menschenlesbare Zeichenkette). So ist zum Beispiel <input type="text" aria-label="Postleitzahl" /> zumindest für die programmatische Beschriftung zulässig. Aber nicht ideal, weil eine sichtbare Beschriftung fehlt, um die es im nächsten Abschnitt gehen soll:

Die programmatische Beschriftung ist nicht die einzige, die für Barrierefreiheit und das Verständnis einer Oberfläche relevant ist: viel häufiger hat das nämlich auch mit sichtbaren Beschriftungen zu tun. Nicht nur rein technisch unbeschriftete Eingabefelder können eine Barriere darstellen – auch wenn rein dogmatisch ein Label (z. B. via aria-label) existiert, so können sehende User verwirrt oder ausgeschlossen werden, wenn nicht klar ist, welche Beschriftung zu welchem Feld gehören oder die programmatische Beschriftung nicht zu sehen ist. Insbesondere Menschen mit Seheinschränkungen sind zum Beispiel von Beschriftungen, die nicht nah genug an einem eigentlich dazugehörigen Feld stehen, betroffen. Damit sie ein Interface halbwegs gut oder gut wahrnehmen können, nutzen diese meist Bildschirmvergrößerungen. Und wenn dann in einer Zoomstufe die optische Verbindung zwischen Eingabefeld und Beschriftung nicht erkannt werden, weil diese zu weit auseinander stehen, kann dies zum Problem werden. Aus diesem Grund gibt es im WCAG-Erfolgskriterium 3.3.2 die Anweisung, dass Eingabefelder auch klar optisch beschriftet werden müssen. Barrierefreiheits-Sachverständige haben auch die besondere Herausforderung in Bezug auf Zoomstufen im Hinterkopf und empfehlen deswegen ein Platzierung von Beschriftungen oberhalb des Eingabefeldes.

Wenn die WCAG von Fehlererkennung spricht, ist damit zuerst, aber nicht allein die programmatische Markierung von Eingabefeldern im Fehlerzustand gemeint. Der oder die Nutzende muss auch in einer nicht-visuellen Art und Weise Informationen über den Zustand eines Eingabefeldes bekommen: wurden Daten falsch oder in einem falschen Format eingegeben? Ist das Feld jetzt gerade in einem Fehlerzustand? Bei einer rein technischen Zustandsmarkierung hört es aber noch nicht auf: Die Web Content Accessibility Guidelines (WCAG) erfordern, dass ein Fehlerzustand auch visuell eindeutig zu erkennen ist. Eine rote Umrandung um ein fehlerhaftes Feld allein reicht beispielsweise nicht aus, weil in diesem Fall Informationen allein über Farbe kommuniziert werden (und das verbietet die WCAG in ihrem Erfolgskriterium 1.4.1).

Somit ergeben Fehlermeldungen sehr viel Sinn, wenn man möchte, dass ein Kaufinteressent das Formular „unfallfrei“ ausfüllt. Das WCAG-Erfolgskriterium 3.3.1 spricht deswegen nicht nur von einer programmatischen Markierung, sondern auch von einer technischen Assoziation von fehlerhaftem Feld und der passenden Fehlermeldung. Letztgenannte sind zwar rein theoretisch optional, aber hilfreiche Instrumente, um das Verständnis von Formularen (und was sie eigentlich von einem wollen) zu erleichtern. Es folgt ein Codebeispiel von einem Eingabefeld, das sich gerade im Fehlerzustand befindet und eine verbundene Fehlermeldung hat:

In dem Codebeispiel sind zwei Dinge hervorzuheben:

Weiterhin müssen wir nun noch sichergehen, dass Screenreader-Nutzende auch mitbekommen, dass ihr Formular-Versand nicht erfolgreich war und entsprechend Fehlermeldungen erzeugt hat. Als Umsetzende oder Umsetzender hat man dazu viele Optionen, ich empfehle aber folgende Strategie für die jeweils genannte technische Situation:

Gehen wir also nochmal davon aus, dass unsere Formulare Fehlermeldungen werfen, sobald sie falsch ausgefüllt werden. Wir als Beitreibende wollen, dass die Fehler behoben werden und unsere Kund*innen in spe zu unserer und ihrer Zufriedenheit korrekt und vollständig ausfüllen. Wenn es also doch zu Fehleingaben kommt, möchten wir Hilfestellungen geben. Dazu gibt es in der WCAG das Erfolgskriterium 3.3.3, das sich um den Wortlaut von Fehlermeldungen dreht und sie darauf überprüft, wie hilfreich sie zur Fehlerbehebung sind. Folgende Fragen stellen WCAG-Prüfende an das fehlermeldende Formular:

Übrigens sind Anmelde- und Passwortfelder von dieser strengen Betrachtung ausgenommen, da zu genaue Hinweise, was mit den eingegebenen Login-Daten nicht stimmt, ein Sicherheitsrisiko darstellen könnten.

Zu guter Letzt halten die Web Content Accessibility Guidelines noch Regeln im Formular-Zusammenhang bereit, die besonders im Online-Shop-Kontext wichtig sind: Erfolgskriterium 3.3.4 dreht sich um Eingaben von wichtigen Daten. Damit gemeint sind unter anderem auch finanzielle Transaktionen und damit etwas, was ja wesentlicher Bestandteil des E-Commerce ist (es sei denn, Sie verkaufen alles auf Rechnung – aber auch in diesem Szenario sollte die Rechnungsadresse stimmen).

Bei wichtigen Datenübertragungen im Sinne von WCAG 3.3.4 ist dann eine Überprüfungsmöglichkeit verlangt, bevor sensible Daten final versendet werden. Dies kann auf drei Wegen geschehen:

Eine finale Bestätigungsseite ist glücklicherweise etwas, was Sie schon von vielen Online-Kaufprozessen kennen oder sogar bereits selbst umgesetzt haben. Nun wissen Sie allerdings, dass diese (mindestens) Verbesserung des Nutzungserlebnisses Ihres Shops für die WCAG niemals nur Option, sondern schon immer Pflicht im Sinne der Web Content Accessibility Guidelines, Level AA war.

Der letzte Abschnitt zur Zusammenfassungs- oder Undo-Funktion hat gezeigt, dass es manchmal große Überschneidungen zwischen Nutzungsfreundlichkeit, guter UX-Praxis und Barrierefreiheit gibt. Im Falle von „wiederholte Eingabe“ (im Original redundant entry) ist das ebenfalls so: Das Erfolgskriterium 3.3.7 will vermieden wissen, dass Benutzende in einem mehrteiligen Prozess die gleichen Daten mehrmals eingeben müssen. Obwohl dies als UX-Verbesserung bereits häufig auf E-Commerce-Seiten vorkommt, will ich nochmal betonen, dass die WCAG, damit Erfolgskriterium 3.3.7 Teil der EN 3015 49 ist – damit wird auch dieses bisherige Best Practice zu einer Art Verpflichtung.

Warum aber wurde die Vermeidung von doppelter Dateneingabe ein Thema der Web-Barrierefreiheit? Die Hauptabsicht dahinter ist es, Menschen die durch Umstände oder Behinderung Probleme mit ihrem Erinnerungsvermögen oder Kurzzeitgedächtnis haben, zu entlasten. Ein konkretes Beispiel findet sich auf ecbf.shop (und wie gesagt, bereits in vielen Online-Bestellprozessen der freien Wildbahn).

Wenn es um die Eingabe der Rechnungsanschrift geht, existiert die Möglichkeit, die Lieferadresse ebenfalls mit den jüngst eingegebenen Daten zu füllen. Häufig wird dies in Form einer Checkbox gelöst, die zumeist mit „Lieferadresse entspricht Rechnungsadresse“ oder Ähnlichem beschriftet ist. Wird die Checkbox dann geklickt (bzw. ein anderer Mechanismus aktiviert, der die Lieferadress-Daten mit den Rechnungsdaten füllt), erfährt der Händler, dass die Rechnungs- der Lieferadresse entspricht. Der oder dem Nutzenden wird damit erspart, die bereits eingegebenen Daten nochmals einzugeben.

Weitere Hinweise zum Erfolgskriterium 3.3.7 sind:

Anknüpfend an den letzten Punkt, in dem es um die Vermeidung doppelter Dateneingaben geht, soll die Nutzung von autocomplete-Attributen auf Eingabefeldern Nutzenden mit Problemen beim Kurzzeit-Gedächtnis und allgemein kognitiven oder motorischen Problemen weiterhelfen. Diese Erleichterung soll über den Weg passieren, dass User Agents(wie Browser und weiterer Hilfstechnologie) programmatische Informationen zu den geforderten Eingabedaten gegeben werden. Eine sichtbare und/oder programmatische Beschriftung übernimmt diesen Job in Richtung menschliche User. Dazu verbindet man Attribut-Wertpaare wie z. B. autocomplete="first-name" mit personenbezogenen Eingabefeldern. Dies soll den Browsern der Nutzerschaft helfen, einmal zentral hinterlegte persönliche Stammdaten automatisch einzutragen zu lassen und damit die Nutzung des Formulars zu erleichtern.

Die WCAG verlangt die Erfüllung auch dieses Erfolgskriteriums 1.3.5, sofern eine Seite insgesamt konform sein soll. Wie schon gesagt, ist das autocomplete-Attribut der einzige Weg, um benutzerbezogene Eingabefelder programmatisch Informationen zu ihrem Zweck bereitzustellen. Was bedeutet, dass man sich im E-Commerce-Kontext mit ihm auseinandersetzen muss. Um von der Theorie in die Praxis zu kommen – folgende Formulararten werden üblicherweise in einem WCAG-Test als personenbezogen eingestuft:

Alle 53 möglichen autocomplete-Werte sind hier aufgelistet. Eventuell fällt Ihnen eine Tendenz zu US-amerikanischen Datenformaten auf, was eine Anpassung auf ein z. B. deutsches Rechungsdaten-Formular erschwerlich macht, und vielleicht Fragen wie „Was ist genau mit address-level1 gemeint?“ hervorruft. Deswegen im Folgenden eine Aufzählung der originalen US-Werte und möglicher Gegenstücke für Deutschland und Österreich, gefunden bei zweiterblick.at: