Barrierefreie Formulare: Beschriftungen und Fehler

Sechs Erfolgskriterien für Formulare

WCAG 2.2 ist die aktuelle Empfehlung des W3C für barrierefreie Web-Inhalte. Für die Texte eines Formulars zählen sechs ihrer Erfolgskriterien am meisten:

• 1.3.1 Info and Relationships (Stufe A): Was das Layout zeigt, etwa welche Beschriftung zu welchem Feld gehört, steht auch im Code oder im Text.
• 1.3.5 Identify Input Purpose (Stufe AA): Felder, die nach Angaben zur Person fragen, etwa Name oder E-Mail, geben ihren Zweck im Code an.
• 3.3.1 Error Identification (Stufe A): Wird ein Eingabefehler automatisch erkannt, wird das Feld benannt und der Fehler als Text beschrieben.
• 3.3.2 Labels or Instructions (Stufe A): Wo Inhalte eine Eingabe verlangen, gibt es Beschriftungen oder Anweisungen.
• 3.3.3 Error Suggestion (Stufe AA): Wird ein Fehler erkannt und ist eine Korrektur bekannt, wird sie vorgeschlagen, außer das gefährdet die Sicherheit oder den Zweck des Inhalts.
• 4.1.2 Name, Role, Value (Stufe A): Jedes Bedienelement hat einen Namen und eine Rolle, die Software auslesen kann.

Jedes Feld braucht eine sichtbare Beschriftung

Eine Beschriftung sagt, was ins Feld gehört, und bleibt sichtbar, während jemand tippt. Im HTML verbindest du das label-Element mit dem Feld: Das for-Attribut des label hat genau denselben Wert wie die id des Feldes. Dann lesen Screenreader die Beschriftung mit dem Feld vor, und ein Klick auf die Beschriftung setzt den Cursor ins Feld. Ein Knopf bekommt seine Beschriftung aus seinem Text, und „Nachricht senden“ sagt mehr als „Absenden“. Beschriftungen stehen meist rechts von Optionsfeldern und Kontrollkästchen und links von oder über anderen Feldern; über dem Feld brauchen sie weniger Platz in der Breite.

Ein Platzhalter ist keine Beschriftung

Der graue Text in einem leeren Feld sieht aus wie eine Beschriftung, ist aber keine. Das W3C nennt die Probleme:

• Er verschwindet, sobald jemand tippt, und erschwert so die Kontrolle der Eingaben vor dem Absenden.
• Browser zeigen ihn oft in einer hellen Farbe mit zu wenig Kontrast.
• Screenreader behandeln ihn nicht als Beschriftung, und die Unterstützung ist uneinheitlich.

Nutze einen Platzhalter höchstens für ein Beispiel und schreib alles Wichtige in die Beschriftung oder einen Hinweis.

Hinweise und Pflichtfelder

• Schreib Regeln in einen Hinweis: das Datumsformat, die Länge einer Kundennummer, was ein Passwort braucht. Im HTML verbindest du den Hinweis mit aria-describedby, dann lesen Screenreader ihn nach der Beschriftung vor.
• Sag, welche Felder Pflicht sind und welche freiwillig. Nutzt du einen Stern, erklär ihn einmal am Anfang des Formulars.
• Setz Anweisungen für das ganze Formular vor das Formular, etwa zu einem Zeitlimit.
• Halte Hinweise kurz. Zu viele Anweisungen machen ein Formular schwerer, nicht leichter.

Zusammengehörige Felder gruppieren

Optionsfelder und Kontrollkästchen, die zusammengehören, gruppierst du mit dem fieldset-Element, und das legend-Element nennt die Gruppe, etwa „Wie sollen wir dich erreichen?“. Das W3C schreibt, dass Gruppen von Optionsfeldern immer so gruppiert werden sollen. Halte die Legende kurz, denn manche Screenreader lesen sie bei jedem Feld vor. Gruppen helfen auch bei Feldern mit gleicher Beschriftung, etwa der Straße in Liefer- und Rechnungsadresse.

autocomplete: den Browser helfen lassen

Für Felder mit Angaben zur Person verlangt 1.3.5, dass ihr Zweck im Code bestimmbar ist. WCAG 2.2 hat dafür eine Liste von Zwecken, die auf dem Abschnitt zum automatischen Ausfüllen der HTML-Spezifikation beruht, etwa name, given-name, family-name, email, tel, street-address und postal-code. Im HTML setzt du sie mit dem Attribut autocomplete, zum Beispiel autocomplete="email". Browser können dann gespeicherte Werte einsetzen, und das spart Tipparbeit. Felder, die nicht nach der Person fragen, brauchen keinen Zweck.

Fehlermeldungen, die helfen

Eine Fehlermeldung hat drei Aufgaben: das Feld nennen, sagen, was falsch ist, und sagen, wie es richtig geht. 3.3.1 verlangt die ersten beiden, und zwar als Text, ein roter Rahmen oder ein Symbol allein reicht also nicht. 3.3.3 verlangt die Korrektur, wo sie bekannt ist.

• Zeig die Meldung neben dem Feld und verbinde sie mit aria-describedby, damit Screenreader sie mit dem Feld vorlesen.
• Zeig nach dem Absenden oben, vor dem Formular, eine Liste aller Fehler unter einer klaren Überschrift. Jeder Eintrag nennt Feld, Problem und Lösung und verlinkt auf das Feld.
• Ändere auch den Seitentitel, etwa „2 Fehler – Kontaktformular“, und setz den Fokus auf das erste Feld mit Fehler.
• Behalte, was schon eingegeben wurde. Das ist unser Rat, keine Regel von WCAG: Wer nach einem Fehler alles neu tippen muss, gibt oft auf.

Dein Formular mit Do4U prüfen

Das Werkzeug Formulartexte prüft die Texte eines Formulars. Du fügst das HTML des Formulars ein oder gibst die Adresse der Seite an und kannst die Fehlermeldungen deines Formulars dazugeben. Der Code liest jedes Feld: seine Beschriftung und woher sie kommt, Hinweise, Platzhalter, Pflichtfelder, autocomplete-Werte und Gruppen von Optionsfeldern oder Kontrollkästchen. Er findet Probleme wie ein Feld ohne Beschriftung, einen Platzhalter als einzige Beschriftung, Pflichtfelder, die der Text nicht nennt, fehlende autocomplete-Werte und vage Fehlermeldungen, jeweils mit dem Erfolgskriterium. Die KI schlägt eine klare Beschriftung, einen kurzen Hinweis und eine Fehlermeldung vor, die das Feld nennt und sagt, wie die Eingabe richtig wird. Der Code prüft jeden Vorschlag und baut aus deinem Formular einen verbesserten HTML-Entwurf.

Do4U findet Hinweise und baut einen Entwurf, du prüfst und entscheidest. Das Werkzeug prüft das Markup, nicht deine Stile, Skripte oder die Bedienung per Tastatur, und es sagt dir nicht, ob dein Formular barrierefrei ist. Teste das verbesserte Formular mit Tastatur und Screenreader.