Formulare & Tastatur-Bedienung

Tab-Reihenfolge & Fokus

Ohne Maus oder Touchscreen kann man einen Browser trotzdem bedienen: Dafür gibt es einen eigenen Cursor, den “Fokus”. Er wird meist durch eine blaue Umrandung angezeigt.

Der Fokus kann auf Eingabefeldern, Links oder Buttons liegen. Mit der Tabulator-Taste wird der Fokus bewegt, mit Enter/Space wird das fokussierte Element aktiviert: ein Link wird aufgerufen, ein Button gedrückt, eine Dropdown-Liste geöffnet.

Die Reihenfolge, in der Tab durch die Seite springt, folgt normalerweise der Reihenfolge im HTML - ein weiterer Grund, HTML-Elemente in einer sinnvollen, logischen Reihenfolge zu schreiben, statt sie nur per CSS visuell umzusortieren.

Häufiger Fehler: outline: none

/* NICHT so - der Fokus wird komplett unsichtbar! */
button:focus {
  outline: none;
}

Damit verlieren TastaturnutzerInnen jede Orientierung, wo sie sich gerade befinden. Wenn euch der Standard-Umriss stilistisch nicht gefällt, ersetzt ihn durch eine eigene, aber deutlich sichtbare Alternative - z.B. box-shadow oder eine dickere border - entfernt ihn nie ersatzlos.

Beschriftungen für Formulare

Alle Eingabefelder in einem Formular brauchen eine sichtbare Beschriftung mit <label> - nicht nur einen Placeholder oder Default-Wert:

<p>Schlechtes Beispiel: <input name="bad" placeholder="50kg"></p>
<p>Gutes Beispiel: <label>Gewicht: <input name="good" placeholder="50kg"></label></p>

Warum Placeholder als Label nicht reicht

Ein Placeholder verschwindet, sobald man zu tippen beginnt - beim erneuten Ansehen des Formulars (z.B. beim Korrigieren) ist die Bedeutung des Feldes dann weg. Für Screenreader-NutzerInnen wird ein Placeholder oft gar nicht oder anders vorgelesen als ein echtes <label>. Außerdem vergrößert ein <label> die klickbare Fläche - ein Klick auf den Text setzt den Fokus ins Feld.

Siehe MDN WCAG Guide: Text labels and names

Fehlermeldungen barrierefrei anzeigen

Ein Formular mit einem ungültigen Feld zeigt oft nur eine rote Umrandung - das reicht nicht: siehe Farben-Abschnitt, Information nie nur über Farbe vermitteln. Ein Screenreader muss den Fehler zusätzlich vorlesen können.

<label for="email">E-Mail</label>
<input
  type="email"
  id="email"
  aria-describedby="email-error"
  aria-invalid="true"
>
<p id="email-error" role="alert">
  Bitte eine gültige E-Mail-Adresse eingeben.
</p>

• aria-describedby="email-error" verknüpft das Eingabefeld mit der Fehlermeldung - ein Screenreader liest sie zusätzlich zum Label vor, sobald das Feld fokussiert wird
• aria-invalid="true" markiert das Feld selbst als ungültig
• role="alert" sorgt dafür, dass die Meldung sofort angekündigt wird, sobald sie per JavaScript zur Seite hinzugefügt wird - auch wenn der Fokus gerade woanders liegt

Nativ vor allem für Pflichtfelder

Für einfache Fälle reicht oft schon natives HTML: <input required> und type="email" lassen den Browser selbst eine (bereits barrierefreie) Fehlermeldung anzeigen, ganz ohne eigenes JavaScript. Erst bei eigener, gestalteter Fehleranzeige braucht es aria-describedby/role="alert" wie oben.