Barrierefreie Formulare - Teil 2: Ausfüllen unterstützen

Formulare sind oft das wichtigste Element einer Website. Ob Checkout, Newsletter-Registrierung oder Kontaktformular – ohne Formulare geht nichts. Deswegen ist Barrierefreiheit bei Formularen enorm wichtig. Wenn das Checkout-Formular nicht ausgefüllt werden kann, wird auch nichts verkauft. In diesem Artikel zeige ich euch, was ihr tun könnt, um so viele Nutzer*innen wie möglich abzuholen.

Der Artikel ist in drei Teile aufgeteilt. In Teil Eins geht es um den grundlegenden Aufbau von Barrierefreiheit in Formularen. In diesem Teil, Teil Zwei, beschäftigen wir uns damit, wie wir unsere Nutzer*innen beim Ausfüllen unterstützen können. Im dritten Teil lernen wir, wie Eingaben barrierefrei validiert werden können.

Eingaben unterstützen

Das oberste Prinzip bei Formularen ist, Nutzer*innen bestmöglichst bei der Eingabe zu unterstützen. So können Fehler vermieden werden, bevor sie entstehen. Die Menschen kommen dann schneller und vor allem frustfreier durch euer Formular.

Erforderliche Felder markieren

Damit die Nutzer*innen wissen, welche Felder zwingend ausgefüllt werden müssen, solltet ihr das deutlich markieren. Dabei bleibt es euch überlassen, ob ihr die erforderlichen oder die optionalen Felder oder beides markiert.

Ein Pattern, dass man oft sieht, ist, die erforderlichen Felder mit Stern zu markieren. Doch obwohl es so häufig benutzt wird, solltet ihr nicht davon ausgehen, dass alle Nutzer*innen das verstehen. Besser, ihr schreibt es noch einmal über das Formular:

1<span>Mit Stern (*) markierte Felder müssen ausgefüllt werden.</span>
2<form>
3    <label for="username">Nutzername</label>
4    <input type="text" id="username" name="username"/>
5    <label for="email">E-Mail*</label>
6    <input type="email" id="email" name="email" required aria-required="true"/>
7    <button type="submit">Abschicken</button>
8</form>

In dem Beispiel habe ich auch das HTML-Attribut required verwendet. Das sorgt dafür, dass das Feld auch semantisch als erforderlich markiert wird. Screenreader greifen diese Information auf und teilen sie ihren Nutzer*innen mit. Das andere Attribut, aria-required, transportiert die selbe Information. Es kann vereinzelt noch dazu kommen, dass required vom Screenreader nicht unterstützt wird, deswegen ist die aktuelle Empfehlung, beide Attribute zu verwenden.

Wir haben hier erstmals ein Beispiel für den Einsatz von ARIA. ARIA steht für Accessible Rich Internet Applications und erweitert HTML um semantische Rollen und Attribute. Es wird an den Stellen eingesetzt, an denen mit HTML keine Semantik definiert werden kann. Zum Beispiel gibt es in HTML kein natives Menü, aber mit Hilfe von ARIA könnt ihr ein selbstprogrammiertes Menü als solches deklarieren. Eine knackige Einführung in ARIA findet ihr zum Beispiel in den MDN Docs. Im weiteren Verlauf der Artikelserie werden wir mehr Beispiele für ARIA kennenlernen.

Hilfestellung bei der Eingabe

Nutzer*innen müssen immer wieder aufs Neue abgeholt werden. Bloß, weil eine Info weiter oben oder auf der vorherigen Seite erwähnt wurde, heißt es nicht, dass sie diese Info noch auf dem Schirm haben.

Ihr könnt nämlich nicht davon ausgehen, dass die Nutzer*innen eurem Formular immer ihre volle Aufmerksamkeit widmen. Sie können beim Ausfüllen auch mal abgelenkt oder unterbrochen werden und dadurch den Kontext verlieren. Manchen fällt es auch schwer, sich länger zu konzentrieren.

Deswegen sollten Hilfen für die Eingabe direkt am entsprechenden Feld stehen und auch programmatisch damit verknüpft sein. Hier kommt wieder WCAG 3.3.2 zum Tragen, die wir schon im ersten Teil kennengelernt haben: "Labels or instructions are provided when content requires user input."

Im Code sieht es so aus:

1<label for="customerNumber">Kundennummer</label>
2<input type="text" id="customerNumber" name="customerNumber" aria-describedby="infoCustomerNumber"/>
3<span id="infoCustomerNumber">Ihre Kundennummer finden Sie oben rechts auf dem letzten Schreiben</span>

Mit aria-describedby könnt ihr die Zusatzinformationen auch semantisch mit der Textbox verknüpfen. Das Attribut nimmt dabei eine Liste von ids der entsprechenden Elemente; so können auch mehrere Infos verlinkt werden. Screenreader-Nutzer bekommen die Zusatzinfos zusammen mit dem Feld vorgelesen.

Automatisches Ausfüllen

Nutzer*innen kommen noch schneller voran, wenn sie gar nicht mehr groß Eingaben tätigen müssen. Das nimmt Einiges an Last ab, vor allem wenn sie kognitiv eingeschränkt sind. Aus diesem Grund ist es auch in den WCAG vorgeschrieben: WCAG 1.3.5 legt fest, dass der Zweck eines Eingabefelds programmatisch auslesbar sein soll, damit assistive Technologien dem Nutzer Hilfestellung bieten können.

Dafür könnt ihr in HTML das autocomplete-Attribut verwenden. Mit dem Wert „given-name“ zum Beispiel legt ihr fest, dass das Feld den Vornamen enthalten soll.

1<label for="firstName">Vorname</label>
2<input type="text" id="firstName" name="firstName" autocomplete="given-name"/>

In diesem Fall ist mit assistive Technologien mal nicht der Screenreader gemeint, sondern eher die Autofill-Funktion des Browsers. Wenn sie aktiv ist, merkt sich der Browser bei der ersten Eingabe eines Feldtyps, was in das Feld kommt, und bietet es der Nutzerin beim nächsten Ausfüllen direkt an. Eine enorme Erleichterung für viele Nutzer*innen.

Redundanz vermeiden

Bei manchen längeren Formularstrecken kommt es vor, dass Nutzer*innen Informationen erneut eingeben müssen. Zum Beispiel könnte bei einem Checkout-Formular eine zusätzliche Lieferadresse abgefragt werden.

In den WCAG wurde auch das in einem Kriterium festgehalten: WCAG 3.3.7 legt fest, dass Nutzer*innen die selbe Eingabe nicht mehrmals tätigen sollten. Dabei gibt es Ausnahmen, zum Beispiel macht es beim Festlegen eines Passworts durchaus Sinn, das Passwort zweimal einzugeben.

Im Beispiel des Checkout könnten wir das Kriterium ganz einfach mit einer Checkbox „Lieferadresse wie Rechnungsadresse“ erfüllen. Die vorher eingegebene Adresse solltet ihr dabei noch einmal anzeigen. Das könnt ihr noch kombinieren mit einer Änderungsoption, falls einer Nutzerin an dieser Stelle ein Fehler in der Adresse auffällt.

Bei richtig langen Formularen könnt ihr auch das Formular auf mehrere Seiten aufteilen. Das macht es den Nutzer*innen einfacher, sich zu fokussieren. Gleichzeitig müssen sie aber noch den Überblick bewahren können, d.h., ihr solltet Zusammenfassungen anzeigen.

Außerdem müssen die Nutzer*innen sich auch rückwärts bewegen können, um nachträgliche Änderungen zu machen. Das ist deutlich aufwendiger als nur eine Seite Formular. Ob es den Aufwand wert ist, müsst ihr im Einzelfall abwägen.

Fazit und Ausblick

In diesem Teil haben wir gelernt, wie wir unsere Nutzer*innen beim Ausfüllen eines Formulars unterstützen können. Durch Hilfestellungen, automatisches Ausfüllen und weniger Redundanz sollten sie das Formular schneller und frustfreier ausfüllen können, und dabei weniger Fehler machen.

Trotzdem lassen sich fehlerhafte Eingaben nicht ganz vermeiden vor. Im Teil Drei der Serie zu barrierefreien Formularen erfahrt ihr, wie ihr am Besten damit umgehen könnt.