Formulare

Es werden keine überflüssigen Daten abgefragt.

Die Anzahl der Eingabefelder muss auf das notwendigste Minimum reduziert werden. Bevor man ein Formular erstellt, muss man sich im Klaren sein, welche Information man unbedingt benötigt, in welcher Form, und wie sie weiterverarbeitet wird. Dafür eigenet sich die Erstellung eines Fragenprotokolls.

Wenn Information zu einem späteren Zeitpunkt oder auf eine andere Art und Weise erfasst werden kann, dann sollte das auch so gemacht werden.

Es werde passende Formularelemente verwendet.

Für jede Abfrage muss evaluiert werden, welche Lösung am sinnvollsten ist. Beispielsweise, eigenen sich bei wenigen Optionen Radio Buttons oder Checkboxen besser als ein Select. Bei langem Text eignet sich eine Textarea besser als ein einzelliges Eingabefeld.

Es werde etablierte Formularelemente verwendet.

Anstatt neue Formularmuster zu entwickeln, sollte man bei bewährten Mustern bleiben. Unbekannte Muster erhöhen die kognitive Last für Benutzer*innen.

Eingabefelder erfüllen die wahrgenommene Erwartung.

Das visuelle Design eines Formularelements kreiert gewisse Erwartungen bei Benutzer*innen. Um diese zu erfüllen, müssen die Funktionalität, die Semantik und die visuelle Darstellung übereinstimmen. Semantische Buttons sehen aus wie Buttons, Radio Buttons sehen aus wie Radio Buttons, und so weiter.

Benutzer*innen werden informiert.

Wenn gewisse Daten oder Dokumente benötigt werden um das Formular auszufüllen, müssen Bürger*innen zu Beginn darüber informiert werden. In langen Formularen, die in mehrere Schritte aufgeteilt sind, muss immer klar sein, was beim nächsten Schritt passiert.

Natives HTML wird bevorzugt

Bevor auf komplexe Lösungen in JavaScript zurückgegriffen wird, sollte immer überprüft werden, ob es eine native Lösung in HTML gibt. Native HTML-Elemente sind üblicherweise standardmäßig barrierefrei und liefern erwartbare Funktionalität.

Jedes Element besitzt ein sichtbares Label.

Bis auf wenige seltene Ausnahmen, besitzt jedes Formular-Element ein sichtbares Label.

Demo

Labels sind einzigartig und beschreibend.

Feld-Bezeichnungen müssen so kurz und konkret wie möglich sein.

Labels werden einheitlich ausgerichtet.

Mit Ausnahme von Checkboxen und Radio-Buttons, befinden sich Labels immer vertikal über dem jeweiligen Formular Element.

Hinweise unterstützen beim Ausfüllen.

Hinweise oder Hilfetexte können besonders nützlich sein für Dinge wie:

• Technische Begriffe
• Juristische Begriffe
• Das geforderte Format für die Eingabe
• Wo Informationen zu finden ist
• Was mit persönlichen Daten passiert
• Konsequenzen von einer Auswahl im Vergleich zur anderen

Hinweise werden offensichtlich platziert.

Um zu verhindern, dass Hinweise von anderen UI–Elementen überlagert werden können, sollten sie zwischen Label und Formularelement platziert werden.

Demo

Hinweise für das gesamte Formular oder größere Bereiche sollten jeweils zu Beginn positioniert werden.

Demo

Um Ihren Account verifizieren zu können, müssen Ihre Angaben bei „Familienname“, „Vorname“ und „Geburtsdatum“ exakt den Angaben auf Ihrem Identitätsnachweis entsprechen.

…

Platzhalter beinhalten keine kritische Information.

Es gibt viele Gründe warum Platzhalter in Formularelementen problematisch sind.

• Platzhaltertext verschwindet wenn Benutzer*innen beginnen zu schreiben, was die kognitive Last erhöht.
• Die Auto–Vervollständigungsfunktion im Browser könnte Felder vorausfüllen, was bedeutet, dass unter Umständen nicht klar ist, welches Feld mit welchen Daten befüllt worden ist.
• Der Kontrast von Platzhaltertext ist sehr gering.
• Langer Platzhalter Text könnte abgeschnitten werden.
• Benutzer*innen verwechseln Platzhaltertext oft mit vorausgefüllten Text.

Semantische Gruppierungen werden sinnvoll aber sparsam eingesetzt.

Semantische Gruppierungen (fieldsets) kommen nur dann zum Einsatz, wenn eine Gruppe von Radio-Buttons oder Checkboxen ausgezeichnet werden soll oder wenn eine Gruppierung von anderen im Formular öfter vorkommenden Elementen Benutzer*innen dienlich ist.

Die Auto-Vervollständigung im Browser wird genutzt.

Mithilfe des autocomplete-Attributs kann man den Browser dabei unterstützen Felder automatisch vorauszufüllen. Das ist besonders nützlich für Menschen mit motorischen oder kognitiven Behinderungen.

<label for="plz">Postleitzahl</label>
<input autocomplete="postal-code" size="4" id="plz">

Formulare sind vollumfänglich mit dem Keyboard bedienbar.

Jegliche kritische Funktionalität und Informationen, die mit einer Maus gemacht oder erfasst werden kann, kann genauso auch mit der Tastatur gemacht werden.

Natives Browserverhalten bleibt intakt.

Native Funktionalität wie Browser-Zoom oder die Vor- und Zurück-Buttons im Browser müssen wie gewohnt funktionieren.

Änderungen am DOM werden angekündigt.

Wenn UI-Elemente dynamisch angezeigt und entfernt werden, müssen diese Änderungen am DOM auch an Screen Reader kommuniziert werden.

Lange Formulare werden aufgeteilt.

Um das Ausfüllen von langen Formularen zu vereinfachen, sollten diese auf mehrere Seiten aufgeteilt werden. Dabei sollte das Formular in logische Gruppen aufgeteilt werden und durch eine interaktive Fortschrittsanzeige Orientierung bieten.

Eingegebene Daten werden vor Abschluss angezeigt.

Alle eingegebenen Daten werden am Ende eines Formulars zusammengefasst mit der Möglichkeit direkt zu einem vorherigen Schritt zu springen und Daten zu ändern.

Eingegebene Daten können bearbeitet werden.

Es muss für Benutzer*innen jederzeit möglich sein, die eingegebenen Daten zu bearbeiten. Indem sie Schritte zurückgehen und die Daten ändern und über die Kontrollseite am Ende des Formulars.

Focus wird gemanagt

Wenn Elemente gelöscht werden, sich öffnen, sich schließen oder sich der zentrale Fokuspunkt verlagert wird Fokus auch programmatisch entsprechend verschoben.

Buttons werden nicht disabled.

Buttons, die via disabled-Attribut deaktiviert werden, sind problematisch für die generelle UX und die Barrierefreiheit.

• Es gibt kein Feedback wenn man auf einem Button klickt. Man weiß nicht, was das Problem ist oder wie man es lösen kann.
• Buttons sind nicht fokussierbar für Keyboard- oder Screen Reader-User.
• Kontraste sind meist sehr niedrig.
• Sie können verwirren, weil nicht immer klar ist, warum oder ob ein Button disabled ist.

Native Validierung wird vermieden.

Die native Validierung in HTML hat einige Nachteile:

• Fehlermeldungen können nicht gestylt werden.
• Einige Formularsteuerelemente können nicht validiert werden.
• In einigen Browsern gibt es Probleme bei der Gestaltung fehlerhafter Felder.
• Die Fehlermeldungen sind nicht immer klar und enthalten keine hilfreichen Vorschläge.
• Der Text der Fehlermeldung passt sich nicht immer an, wenn Sie die Seite vergrößern.
• Fehlermeldungen sind nicht korrekt mit dem entsprechenden Feld verknüpft.

Fehler werden programmatisch und visuell ausgzeichnet.

Fehler müssen auf unterschiedliche Weise kommuniziert werden, beispielsweise durch den Einsatz von Farbe und Piktogrammen aber auch programmatisch, beispielsweise durch den Einsatz von ARIA-Attributen.

Fehlermeldungen werden offensichtlich platziert.

Fehlermeldungen werden räumlich nahe zum jeweiligen Eingabefeld positioniert und sind immer sichtbar, zumindest solange der Fehler noch besteht. Tooltips oder ephemerale Fenster sollten vermieden werden.

Fehlermeldungen schaffen Klarheit.

• Fehlermeldungen sind kurz, aber lassen keine Wörter auf Kosten der Klarheit weg.
• Es wird konsequent und durchgängig der gleiche Tonfall und die gleiche Zeichensetzung verwenden.
• Höflichkeitsfloskeln wie „Bitte“ werden vermieden, denn sie implizieren eine Option.
• Spezifische angeben werden gegenüber allgemeinen Formulierungen bevorzugt. Anstatt zu sagen: „Es ist ein Fehler aufgetreten“, wird erklärt, was schief gelaufen ist.
• Einfache, natürliche Sprache wird bevorzugt und Jargon wie „ungültig” und „obligatorisch“ vermieden.
• Die aktive Stimme wird verwendet: „Geben Sie Ihren Namen ein“ anstatt „Ein Name muss eingegeben werden“.
• Benutzer werden darüber informiert, was schief gelaufen ist und wie man es beheben kann.

Viele Fehler werden zusammengefasst.

Wenn es mehr als einen Fehler gibt, werden die Fehler zu Beginn des Formulars zusammengefasst, alle Fehler dienen als Anker zum jeweiligen Eingabefeld, und Fokus ist auf dem ersten Fehler in der Liste.

Demo

1. Bitte Vorname ausfüllen
2. Ungültiges Zeichen & in Familienname
3. Bitte Hausnummer angeben