Barrierefreie Formulare

TL;DR

Einen Spickzettel mit vollständigem Quelltext-Beispiel, Checkliste zum abhaken und WCAG-Auflistung findest Du hier: Spickzettel: barrierefreie Formulare.

Vorwort

Die hier vorgestellte Umsetzung spiegelt meine persönliche Herangehensweise wider, basierend auf umfangreichen Recherchen und Überlegungen. Sie ist nicht als absolute oder vollständige Lösung gedacht, sondern als ein Ansatz, der Raum für Weiterentwicklung und Verbesserung bietet. Solltest Du Fehler entdecken oder Vorschläge zur Optimierung haben, freue ich mich über Deine Nachricht.

Um die Lesbarkeit zu verbessern, wurden die Beispielcodes auf das Wesentliche reduziert.

Verwendete Abkürzungen

Diese Abkürzungen werden folgend verwendet:

  • HTML: Hypertext Markup Language
  • WCAG: Web Content Accessibility Guidlines
  • px: Pixel

HTML-Aufbau

Die Grundlage für ein barrierefreies Formular ist semantisches HTML. Dabei ist insbesondere die korrekte Beschriftung der Formularfelder von entscheidender Bedeutung.

Es ist wichtig sicherzustellen, dass für jedes Formularfeld ein semantisch verknüpftes Label vorhanden ist. Dies kann mithilfe des for-Attributs in einem <label>-Element realisiert werden. Alternativ können die Attribute aria-label und aria-labelledby verwendet werden, um das jeweilige Formularfeld zu kennzeichnen.

Checkboxen und Radio-Buttons können direkt in das <label>-Element eingefügt werden, wodurch das for-Attribut in diesem Fall nicht erforderlich ist. Falls mehrere zusammengehörende Checkboxen oder Radio-Buttons vorhanden sind, können sie in einem <fieldset>-Element mit einer entsprechenden <legend>-Beschriftung gruppiert werden.

Um etwaige Beschreibungen, wie beispielsweise Hilfestellungen zur Befüllung, semantisch mit den entsprechenden Formularfeldern zu verknüpfen, kann das aria-describedby-Attribut auf dem Formularfeld genutzt werden.

Beispiel-Quellcode: HTML-Aufbau 

<form>
  <label for="input-field">Name</label>
  <input id="input-field" type="text" name="name"/>
  <fieldset>
    <legend>Auswahlmöglichkeiten</legend>
    <label><input type="checkbox" name="options"/>Option 1</label>
    <label><input type="checkbox" name="options"/>Option 2</label>
    <label><input type="checkbox" name="options"/>Option 3</label>
  </fieldset>
  <input type="submit" value="Absenden" />
</form>

Pflichtfelder

Pflichtfelder in Formularen sind wie Wegweiser, die Nutzer durch den Prozess führen und sicherstellen, dass alle benötigten Informationen eingetragen werden. Diese wichtigen Felder müssen deutlich gekennzeichnet werden, damit Nutzer sofort erkennen, was erforderlich ist.

Das required-Attribut ist hierbei ein nützliches Werkzeug. Dieses ermöglicht dem Browser, Pflichtfelder zu erkennen und vor dem Absenden entsprechende Hinweise auszugeben. Das Formular wird erst versendet, wenn alle Pflichtfelder ausgefüllt sind, was eine fehlerfreie Übermittlung gewährleistet. Darüber hinaus erhalten auch Screenreader-Nutzer durch dieses Attribut die Information, welches Feld verpflichtend ist, was zu einer verbesserten Benutzererfahrung beiträgt.

Zusätzlich zur technischen Umsetzung ist es wichtig, visuelle Nutzer darüber zu informieren, welche Felder Pflichtfelder sind, idealerweise bevor der Browser darauf hinweist.

Hier sind einige wichtige Aspekte zu berücksichtigen.

Zunächst sollte eine klare Erklärung bereitstehen, was das Sternchen (*) bedeutet. Um sicherzustellen, dass Benutzer diese Information vor dem Ausfüllen des Formulars erhalten, sollte es vor allen Formularfeldern platziert werden. Da diese visuelle Hilfestellung jedoch nur für sehende Nutzer relevant ist, ist es ratsam, sie für Screenreader zu verbergen. Dies kann durch Verwendung des aria-hidden-Attributes erfolgen. Da das Sternchen (*) an der Beschriftung ebenfalls nur für visuelle Nutzer gedacht ist, kann auch dieses für Screenreader ausgeblendet werden. Obwohl das Sternchen-Zeichen normalerweise nicht vorgelesen wird, kann dies je nach Screenreader-Konfiguration variieren. Daher ist es besser, auf Nummer sicher zu gehen und es auszublenden.

Beispiel-Quellcode: Pflichtfeld-Angabe 

<form>
  <div aria-hidden="true">*Pflichtfeld</div>
  <label for="input-field">Name<span aria-hidden="true">*</span></label>
  <input id="input-field" type="text" name="name" required/>
  ...
</form>

Das Placeholder-Attribut

In der Praxis sind Platzhalter-Texte mit Hilfe des placeholder-Attributes in Formularfeldern weit verbreitet und können vielfältige Funktionen erfüllen, von der Beschriftung bis hin zur Anleitung zur richtigen Befüllung. Jedoch können sie für bestimmte Nutzergruppen, insbesondere für Menschen mit eingeschränktem Sehvermögen, problematisch sein.

Ein Hauptproblem ist der oft zu geringe Kontrast des Platzhalter-Textes, der es einigen Nutzern erschwert, die Informationen wahrzunehmen. Dies kann dazu führen, dass wichtige Anweisungen übersehen werden und das Formular möglicherweise falsch ausgefüllt wird.

Während es möglich ist, den Kontrast des Platzhalter-Textes über CSS anzupassen, birgt dies potenziell neue Probleme. Ein zu hoher Kontrast könnte den Eindruck erwecken, dass das Feld bereits ausgefüllt ist, was zu Verwirrung führen kann, wenn später ein Fehler auftritt.

Ein weiteres Problem ist, dass der Platzhalter-Text verschwindet, sobald das Feld aktiviert wird, was dazu führen kann, dass die Informationen verloren gehen. Um dies zu vermeiden, ist es ratsam, Informationen wie Anweisungen oder Beispiele in einem separaten Element bereitzustellen, das über das aria-describedby-Attribut mit dem entsprechenden Formularfeld verknüpft ist. Diese Methode stellt sicher, dass die relevanten Informationen für alle Nutzer zugänglich bleiben, unabhängig davon, ob sie den Platzhalter-Text sehen können oder nicht.

Beispiel-Quellcode: Platzhalter-Alternative 

<form>
  ...
  <input id="input-field" type="text" aria-describedby="input-field-description" />
  <div id="input-field-description">Mind. 10 Zeichen</div>
  ...
</form>

Autovervollständigung

Die Autovervollständigungsfunktion ist eine großartige Unterstützung beim Ausfüllen von Formularen. Der Browser erkennt automatisch, welche Informationen in welches Feld einzutragen sind, und bietet an, bereits hinterlegte Daten direkt einzufügen. Dadurch können die häufigsten Felder im Handumdrehen ausgefüllt werden, sodass wir uns nur noch mit den verbleibenden Details befassen müssen.

Diese praktische Funktion wird über das autocomplete-Attribut gesteuert. Mit festgelegten Werten können wir angeben, welche Art von Inhalt in jedem Feld erwartet wird. Eine umfassende Liste der verfügbaren Parameter steht hier zur Verfügung, um die Autovervollständigung optimal anzupassen.

Fehlerfall-Kommunikation

fehlerhafte Felder

Formulare sind von Menschen für Menschen gemacht, und genauso wie wir alle Fehler machen können, können auch Formulare fehlerhaft sein. Es kann vorkommen, dass ein Pflichtfeld vergessen wurde oder der eingegebene Inhalt nicht den Erwartungen entspricht, zum Beispiel wenn er zu kurz ist.

Um solche Fehler im Formular zu erkennen und dem Nutzer bei ihrer Behebung zu helfen, ist eine effiziente Darstellung der Fehler von entscheidender Bedeutung. Hierbei gibt es ein paar Punkte zu beachten.

Fehler sollten nicht ausschließlich durch Farben kommuniziert werden. Die Verwendung eines zusätzlichen Symbols, zum Beispiel eines Icons, kann Menschen helfen, die Farbe nicht wahrnehmen können. Dennoch ist es sinnvoll, eine auffällige Farbe zu verwenden, um die Fehlermeldung gut sichtbar zu machen. Dabei müssen jedoch Kontrastvorgaben berücksichtigt werden, um sicherzustellen, dass die Fehlermeldung deutlich erkennbar ist. Weitere Hinweise zu den Kontrasten finden sich im Abschnitt "Gestaltung".

Es ist außerdem hilfreich, die Fehlermeldung direkt neben dem betroffenen Feld anzuzeigen. So ist sofort erkennbar, welches Feld fehlerhaft ist. Um dem Nutzer auch zu erklären, warum das Feld einen Fehler enthält, sollte die Fehlerbeschreibung möglichst präzise sein. Ein einfaches "Das Feld enthält einen Fehler" ist hier wenig hilfreich.

Um auch Screenreader-Nutzer über den Fehler zu informieren, ist es ratsam, das Element, das die Fehlermeldung enthält, mit dem entsprechenden Feld zu verknüpfen, idealerweise mit dem aria-labelledby-Attribut. So wird der Fehler frühzeitig und eindeutig ausgegeben. Dabei ist wichtig sicherzustellen, dass die ursprüngliche Beschriftung des Feldes erhalten bleibt, während die Fehlermeldung zusätzlich ausgegeben wird. Alternativ kann die Fehlermeldung auch über das aria-describedby-Attribut mit dem entsprechenden Feld verknüpft werden.

Beispiel-Quellcode: fehlerhaftes Formularfeld 

<form>
  ...
  <label for="input-field" id="input-field-label">Name</label>
  <input id="input-field" type="text" name="name" aria-labelledby="input-field-label input-field-error"/>
  <div id="input-field-error">Die Eingabe muss mindestens 10 Zeichen lang sein.</div>
  ...
</form>

Fehlerauflistung

Nach dem Absenden des Formulars erfolgt oft eine Neuladung der Seite, was dazu führen kann, dass der Nutzer wieder zum Anfang der Seite zurückkehrt. Wenn auf der Seite ein Formular mit Fehlern vorhanden ist, kann dem Nutzer bereits vor dem Anzeigen des Formulars eine Fehlerliste präsentiert werden, die ihm mitteilt, in welchen Feldern Fehler aufgetreten sind.

Es ist ratsam, diese Fehlerliste vor dem eigentlichen Formular zu platzieren und optisch deutlich vom restlichen Inhalt abzuheben. Ähnlich wie bei den Fehlermeldungen kann dabei auf eine kontrastreiche Farbgebung und die Verwendung eines Symbols zurückgegriffen werden.

Die Fehler sollten in einer ungeordneten Liste aufgeführt werden und möglichst unterstützende Informationen enthalten, einschließlich der Feldbezeichnung. Auf diese Weise ist sofort klar, warum welches Feld fehlerhaft ist. Idealerweise sollten die einzelnen Aufzählungspunkte zu den jeweiligen Feldern verlinkt sein, um dem Nutzer eine schnelle Navigation zu ermöglichen.

Beispiel-Quellcode: Fehlerauflistung 

<ul aria-label="Formularfehler">
  <li><a href="#input-field">"Name": Die Eingabe muss mindestens 10 Zeichen lang sein.</a></li>
</ul>

...

<form>
  <div aria-hidden="true">*Pflichtfeld</div>
  <label for="input-field" id="input-field-label">Name<span aria-hidden="true">*</span></label>
  <input id="input-field" type="text" aria-labelledby="input-field-label input-field-error" aria-describedby="input-field-description" required/>
  ...
</form>

Gestaltung

Farbwahl

Bei der Gestaltung von Farben ist es wichtig, auf ein ausgewogenes Kontrastverhältnis zu achten. Texte sollten im Vergleich zum Hintergrund mindestens ein Kontrastverhältnis von 4,5:1 aufweisen (gemäß WCAG 1.4.3 - Contrast (Minimum) (Level AA)). Für größere Texte genügt ein Kontrastverhältnis von 3:1.

Wenn man über die Mindestanforderung hinausgehen möchte, kann man ein Kontrastverhältnis von mindestens 7:1 für normalen Text bzw. 4,5:1 für größeren Text anstreben (gemäß WCAG 1.4.6 - Contrast (Enhanced) (Level AAA)).

Es ist jedoch nicht nur der Kontrast zwischen Text und Hintergrund zu berücksichtigen, sondern auch der Kontrast von farbigen Flächen zu ihren Nachbarn. Dies ist beispielsweise der Fall, wenn sich die Farbe eines Elements bei einem :hover-Ereignis ändert. Der Kontrast zwischen der Standardfarbe und der Farbe im :hover-Status sollte mindestens ein Verhältnis von 3:1 aufweisen, damit diese Änderung von möglichst vielen Menschen wahrgenommen werden kann (gemäß WCAG 1.4.11 - Non-text Contrast).

 

Schaltflächen

Um eine einfache Bedienung von Bedienelementen oder Verlinkungen für eine breite Palette von Benutzern zu gewährleisten, ist es wichtig, auf eine ausreichende Größe dieser Elemente zu achten. Dies ist besonders hilfreich für Menschen mit Parkinson oder ähnlichen Bedingungen, die Schwierigkeiten beim präzisen Klicken haben könnten.

Elemente, die mit einer Maus geklickt werden können oder müssen, sollten eine Mindestgröße von 24px haben (gemäß WCAG 2.5.8 - Target Size (Minimum)(Level AA)), aber es gibt Ausnahmen. Bei kleineren Zielen ist wichtig sicherzustellen, dass sich kein weiteres Element innerhalb eines Radius von 24px um das zu kleine Klickziel befindet.

Es gibt auch Situationen, in denen diese Mindestgröße nicht gilt, wenn

  • die Funktionalität anderweitig verfügbar ist.
  • sich das Element innerhalb eines Satzes oder Textes befindet.
  • die Größe vom User-Agent festgelegt und nicht veränderbar ist.
  • die Größe für die Funktion oder gesetzliche Anforderungen entscheidend ist.

Neben der 24px-Vorgabe gibt es eine erweiterte Variante, um die Bedienung für noch mehr Menschen zu erleichtern. Bedienelemente oder Klickziele sollten dann eine Mindestgröße von 44px haben (gemäß WCAG 2.5.5 - Target Size (Level AAA)), aber auch hier gibt es Ausnahmen.

Die Mindestanforderung entfällt, wenn

  • ein anderes Element mit derselben Funktion und einer Mindestgröße von 44px auf der Seite vorhanden ist.
  • das Element sich innerhalb eines Satzes oder Textes befindet.
  • die Größe vom User-Agent festgelegt und nicht anpassbar ist.
  • die Größe für die Übermittlung der Information wesentlich ist.

Fokus

Auch bei der Gestaltung des Fokusses für Tastaturnutzende sind einige Punkte zu beachten. Hierfür habe ich eine eigene Notiz "Der Fokus", da dieses Thema nicht nur hier gilt.