Formulare & Fehlerbehandlung

Viele Websites und Web-Apps verfügen über Formulare, über die sich Benutzer anmelden, registrieren, Produkte bestellen oder Kommentare hinterlassen können. Diese Formulare bieten häufig eine Fehlerbehandlung.

Ein Formular mit Fehlerbehandlung in Aktion

Das folgende einfache Kontaktformular zeigt, wie die Fehlerbehandlung funktioniert - in diesem Fall, wenn der Benutzer das Formular abschickt. Der Bildschirmleser NVDA ist eingeschaltet, um zu zeigen, wie nicht-visuelle Benutzer den Vorgang wahrnehmen.

Video-Beschreibung

Ein Screenreader-Benutzer füllt ein einfaches Kontaktformular auf der Website nomensa.com aus.

  • Beim Fokussieren des Feldes Your full name (ganzer Name) wird das programmatisch zugeordnete Label gelesen, gefolgt von der Information, dass dies ein Pflichtfeld ist.
  • Der Nutzer gibt seinen Namen ein.
  • Der Nutzer wechselt zum Pflichtfeld Your email (required) und gibt seine E-Mail-Adresse ein.
  • Der Nutzer überspringt das Pflichtfeld Your telephone number (required) und fährt mit dem Textfeld Your enquiry (Anfrage) fort.
  • Der Benutzer schreibt eine kurze Nachricht und seine Telefonnummer in das Feld Ihre Anfrage.
  • Er schickt das Formular über den Schalter Send ab.
  • Oben im Formular wird nun eine Fehlermeldung mit einem Link zu dem Feld angezeigt, in dem ein Eintrag fehlt.
  • Der Benutzer folgt dem Link und der Fokus wird auf das Feld Your telephone number gesetzt.
  • Der Benutzer gibt nun die Nummer in das richtige Feld ein.

Typische Nutzungsprobleme bei Formularen und Fehlerbehandlung

Für Nutzer mit Behinderungen gibt es viele verschiedene Probleme mit Formularen.

Sehbehinderte Nutzer haben es schwerer, Formulare zu finden,, Sind sie gefunden, ist es in der Vergrößetrung oft schwerer, die Bedeutung herausfinden, zum Beispiel, wenn Beschriftungen von Eingabefeldern abgeschnitten sind oder einen schlechten Kontrast haben.

Ein häufiges Problem für Screenreader-Nutzer ist, dass das die Beschriftung nicht ausgegeben wird, wenn sie ein Feld fokussieren. Die Fehlerbehandlung kann für blinde Benutzer besonders schwierig sein, wenn nicht klar ist, ob Fehler aufgetreten sind oder wo sie aufgetreten sind. Auf vielen Websites werden Fehlermeldungen oder Hinweise nur visuell angezeigt, so dass der blinde Benutzer raten und suchen müssen, was "schief gelaufen ist".

Formulare verursachen auch oft kognitive Probleme. Wenn Beschriftungen nicht einfach zu verstehen sind, haben die Benutzer Schwierigkeiten. Es gibt viele Fälle, in denen Websites technischen Jargon in Labels verwenden. Oft gibt es keine Erklärungen, oder hilfreiche Eingabebeispiele fehlen. In anderen Fällen gibt die Site nicht das erwartete Eingabeformat an, zum Beispiel für Datumsfelder.

Wie bei den meisten menschlichen Aktivitäten treten beim Ausfüllen von Formularen Fehler auf. Aus diesem Grund ist eine gute Fehlerbehandlung wichtig. Hier sind einige typische Beispiele für Fehler:

  • Der Nutzer überspringt ein oder mehrere Felder, in denen Informationen benötigt werden (Pflichtfelder)
  • Der Nutzer möchte in einigen Feldern keine Informationen eingeben und lässt sie absichtlich leer
  • Der Benutzer verschreibt sich bei der Eingabe und das Feld wird überprüft. Beispiele sind eine ungültige E-Mail-Adresse oder ein Feld für die Wiederholung des Kennworts, bei dem die Eingabe nicht mit der Eingabe im ersten Kennwortfeld übereinstimmt.
  • Der Benutzer liefert Eingaben in einem Format, das vom Formular nicht akzeptiert wird (z. B. tippt er in das Feld Geburtsdatum 27.10.1995 statt 27/10/1995)

1 Nutzung mit Vergrößerung: Sucheingabefeld wird wegen ungewohnter Platzierung nicht gefunden

In diesem Beispiel sucht ein Vergrößerungsbenutzer nach dem Suchfeld in der oberen rechten Ecke und identifiziert etwas anderes als Suche, bis er weiter hineinzoomt und seinen Fehler erkennt.

Video-Beschreibung

Ein sehbehinderter Nutzer, der mit starker Vergrößerung arbeitet, versucht, das Suchformular auf der Website haw-hamburg.de auf seinem Mobiltelefon zu finden.

  • Er öffnet die Startseite.
  • Er verwendet den Pinch-Zoom des Browsers und verschiebt die Seite, so dass die obere rechte Ecke sichtbar wird.
  • Er identifiziert einen Text (Selfservice), den er für das Suchfeld hält.
  • Er zoomt weiter ein und verwendet die Zoom-Funktion des Telefons, um seine Vermutung zu überprüfen.
  • Er erkennt, dass dies nicht das Suchfeld ist.
  • Er vertritt die Ansicht, dass die Suche immer oben rechts zu finden sein sollte.

2 Nutzung mit Vergrößerung: Schwierige Identifizierung des Suchfelds wegen schlechter Beschriftung

In diesem Beispiel versucht ein sehbehinderter Nutzer mit starker Zoom-Vergrößerung das Suchfeld zu identifizieren. Das Feld ist nur durch einen kontrastarmen und abgeschnittenen Platzhaltertext beschriftet.

Video-Beschreibung

Ein sehbehinderter Nutzer versucht auf seinem Mobiltelefon, auf der Website haw-hamburg.de das Suchfeld zu identifizieren.

  • He sucht auf der Seite nach etwas, das nach einem Suchfeld aussieht.
  • Er findet ein Quicklinks-Ausklappmenü und vermutet, dass das Feld links davon das Suchfeld sein könnte.
  • Er liest den – nicht hilreichen und zudem abgeschnittenen – Platzhaltertext des Eingabefeldes, "Benutzerde".
  • Er aktiviert das Feld, um sich abschließend zu bestätigen, dass es sich tatsächlich um das Suchfeld handelt.
  • Der Platzhaltertext wird durch einen blinkenden Cursor ersetzt.
  • Der Nutzer ist ist nun sicher, die Suche gefunden zu haben.

3 Nutzung mit Vergrößerung: Platzhaltertext im Formularfeld mit ungenügendem Kontrast

Der Platzhaltertext von Formularfeldern hat häufig keinen ausreichenden Kontrast. Bei mobilen Layouts ist der Platzhaltertext häufig die einzige Beschriftung der Eingabefelder.

Video-Beschreibung

Eine sehbehinderte Nutzerin versucht auf ihrem Handy, die Beschriftungen eines Suchformulars in den Gelben Seiten von München zu lesen.

  • Sie öffnet den Bereich der gelben Seiten.
  • Sie erkennt etwas, das wie Eingabefelder aussieht, kann den Text jedoch aufgrund des unzureichenden Kontrastes nicht lesen.
  • Sie verwendet die iPhone-Zoom-Vergrößerung, um weiter in die Seite hineinzuzoomen
  • Sie kann nun die Etiketten lesen.

4 Verständlichkeit: Unklare beziehungsweise technische Beschriftung von Formuarelementen

In diesem Beispiel hat ein Formular zum Melden von Ampel-Störungen Beschriftungen in einem Fachjargon, den die Benutzerin nicht verstehen kann.

Video-Beschreibung

Eine Screenreader-Nutzerin versucht, eine Ampel-Störung auf der Website hhva.de zu melden, und hat Schwierigkeiten, die richtige Kategorie für die Störung zu wählen.

  • Durch Pfeiltastennavigation nach unten gelangt die Nutzerin zur Überschrift des Störungsmeldungsabschnitts, der durch ein Zeilenumbruchelement in zwei Teile zerfällt.
  • Drei Optionsfeldbeschriftungen für die zu wählenden Fehlerkategorien werden nacheinander bei Fokuserhalt gelesen.
  • Die Nutzerin kann die Kategorien nicht verstehen - sie sagt, dass er nicht weiß, wo sie die Störung nun melden soll.

Hinweis: Für den Kern des Problems ist es unerheblich, ob die Nutzerin mit dem Screenreader arbeitet oder nicht – nur die Folgen einer falschen Wahl sind für Screenreader-Nutzer gravierender (es dauerte lange, den richtigen Abschnitt auf dieser Seite zu finden).

5 Screenreader-Nutzung: Visuelle Hinweise ohne Screenreader-Output

In diesem Beispiel zeigt das Kennwortfeld einen Hinweis, dass ein Benutzerpasswort aus mindestens 8 Buchstaben bestehen muss und eine Zahl oder ein Sonderzeichen enthalten muss. Diese Informationen stehen blinden Nutzern nicht zur Verfügung.

Video-Beschreibung

  • Ein blinder Nutzer füllt das PayPal-Registrierungsformular aus und fokussiert das Kennwortfeld.
  • Ein Hinweis zu den Kennwortanforderungen wird visuell angezeigt, jedoch nicht vom Screenreader ausgegeben.

Zugänglichkeits-Tipps für Formulare und Fehlerbehandlung

  • Stellen Sie sicher, dass alle Formulareingaben eine beschreibende und eindeutige Bezeichnung oder einen eindeutigen Namen haben. Zeigen Sie das erwartete Format neben der Eingabe an, wenn dies sinnvoll ist (z. B. DD.MM.YYYY für eine Datumseingabe).
  • Platzieren Sie die Beschriftung bzw. Labels über oder links neben dem Eingabefeld (rechts für Checkboxen und Optionsfelder).
  • Stellen Sie sicher, dass Labels programmatisch mit Eingaben verknüpft werden, z. B. indem Sie das label-Element verwenden, das auf das mit dem for-Attribut auf das Eingabefeld verweist.
  • Verwenden Sie Platzhaltertext nicht als alleinige Beschriftung eines Textfelds. Das placehoder-Attribut verschwindet, sobald der Benutzer in das Feld schreibt. Wenn Sie Platz sparen müssen, verwenden Sie barrierefreie Beschriftungen (siehe den Abschnitt Quellen).
  • Verwenden Sie die Elemente fieldset und legend, um bei Bedarf den beschrifteten Feldern einen Kontext zuzuweisen, z. B. zur Unterscheidung der Rechnungs- und Lieferadresse, oder für Gruppen von Optionsfeldern, die durch direkte Label allein nicht klar beschriftet sind.
  • Verwenden Sie das HTML type Attribut für Felder, in denen Benutzer bestimmte Informationstypen eingeben, wie Telefonnummer, E-Mail-Adresse oder Passwort.
  • Verlassen Sie sich nicht auf die automatische Fehlerbehandlung von HTML5 – die so erzeugten Fehlermeldungen sind generisch und verschwinden nach kurzer Zeit.
  • Verlassen Sie sich nicht nur auf die Farbe, um fehlerhafte Eingaben anzuzeigen (z. B. durch rote Darstellung des Labeltextes).
  • Stellen Sie einen guten Kontrast des Textes der Fehlermeldung sicher. Verwenden Sie Farben oder zusätzliche Symbole, um sie hervorzuheben.
  • Wenn Sie Fehlermeldungen in der Nähe der Eingabefelder generieren, stellen Sie sicher, dass sie programmatisch mit der Eingabe verknüpft sind (aktualisieren Sie das Label-Element oder verknüpfen Sie die Meldungen mit Hilfe der von aria-describedby). Dann werden sie vom Screenreader gesprochen, wenn das Eingabefeld fokussiert wird.
  • Wenn Sie nach dem Abschicken des Formulars Fehlermeldungen anzeigen, setzen Sie den Fokus auf das erste fehlerhafte Feld, wenn Sie keine separate Liste mit Fehlern am Anfang des Formulars einfügen.
  • Wenn Sie nach dem Abschicken des Formulars eine Liste mit Fehlern anzeigen, fügen Sie siw vor dem Formular ein, setzen Sie den Fokus auf den Anfang der Liste und verknüpfen Sie jede Fehlermeldung mit der Eingabe, die korrigiert werden muss.

Neue Anforderungen für Formulare in WCAG 2.1

n der neuesten Version der Richtlinien für barrierefreie Webinhalte, WCAG 2.1, gibt es zwei neue Anforderungen, die sich besonders auf Formulare beziehen.

Zweck von Eingabefeldern

Das neue Erfolgskriterium 1.3.5 Identify Input Purpose verlangt, dass Eingabefelder, in denen Informationen über den Benutzer erfasst werden (z. B. Name, Adresse, Telefonnummer usw.), ihren Zweck programmatisch ermittelbar kommunizieren. Die Idee dahinter ist, dass bestimmte Technologien Benutzer dann besser unterstützen können. Beispielsweise könnten sie zusätzlich zur Textbeschriftung ein Bild anzeigen, das den Zweck eines Feldes darstellt. Ein Beispiel ist das Bild eines Telefons für ein Telefonnummerneingabefeld. Visuelle Hinweise sind für Menschen mit bestimmten kognitiven Behinderungen wichtig. Derzeit ist die Verwendung des HTML5 autocomplete Attributs die beste Möglichkeit, den Eingabezweck zu identifizieren. Weitere Informationen finden Sie im Understanding text for 1.3.5 Identify Input Purpose. Techniken für dieses neue Erfolgskriterium sind in der Entwicklung.

Statusmeldungen

Manchmal ändert sich der Seiteninhalt dynamisch, wenn Benutzer mit Formularen interagieren. Die Seite zeigt dann häufig visuelle Statusmeldungen. Ein Beispiel ist "Danke, das Formular wurde abgeschickt".

Ein anderes Beispiel tritt auf, wenn Benutzer Suchergebnisse filtern, indem sie Suchbegriffe hinzufügen oder Optionen auswählen. Eine visuelle Statusmeldung informiert Benutzer häufig darüber, wie viele Sucheinträge basierend auf den eingestellten Filtern gefunden wurden. Das neue Erfolgskriterium 4.1.3 Status Messages erfordert, dass diese visuellen Nachrichten auch programmatisch ermittelbar sein müssen, damit nicht-visuelle Nutzer die Änderung bemerken. Dies kann mithilfe des Attributs aria-live für die Statusnachricht erfolgen. Weitere Informationen finden Sie im Text Understanding Text for 4.1.3 Status Messages.

Quellen für Formulare und Fehlerbehandlung