Barrierefreie Formulare - Teil 1: Der Aufbau

Formulare sind oft das wichtigste Element einer Website. Ob Checkout, Newsletter-Registrierung oder Kontaktformular – ohne Formulare geht nichts. Deswegen ist Barrierefreiheit bei Formularen enorm wichtig. Wenn das Checkout-Formular nicht ausgefüllt werden kann, wird auch nichts verkauft. In diesem Artikel zeige ich euch, was ihr tun könnt, um so viele Nutzer*innen wie möglich abzuholen.

Der Artikel ist in drei Teile aufgeteilt. In Teil Eins geht es um den grundlegenden Aufbau von Barrierefreiheit in Formularen. Teil Zwei beschäftigt sich mit Nutzereingaben und Teil Drei mit der Validierung.

Richtlinien für Barrierefreiheit

Ein bisschen Theorie bevor wir loslegen: Die Empfehlungen, die ich in diesem Artikel ausspreche, basieren zum großen Teil auf den Web Content Accessibility Guidelines (WCAG). Diese Richtlinien sind der internationale Standard für digitale Barrierefreiheit. Für eine grobe Übersicht lest gerne meinen Blogartikel über die WCAG. In diesem Artikel verweise ich dort, wo es relevant ist, auf die entsprechende Richtlinie.

Semantische Labels

Jedes Formularfeld muss ein Label haben, damit die Nutzer*innen wissen, was sie eintragen sollen (WCAG 3.3.2). Klingt nach einer einfachen Regel, oder? So sieht das im Code aus:

<label for="firstName">Vorname</label>
<input type="text" id="firstName" name="firstName"/>

Wie ihr seht, benutze ich das label-Tag, ein semantisches Attribut. Semantische Attribute helfen dem Browser, die Bedeutung eines Elements zu erfassen und entsprechende Interaktionen anzubieten. Bei einem Button wäre das zum Beispiel die Möglichkeit, darauf zu klicken.

Außerdem ist das Label über das for-Attribut mit der Textbox verknüpft. Diese Information wird, zusammen mit den anderen semantischen Infos, durch den Browser in den sogenannten Accessibility Tree mit aufgenommen. Diesen Baum stellt der Browser Screenreadern und andere assistive Technologien zur Verfügung. Den Baum könnt ihr euch in den Developer Tools anzeigen lassen, z.B. im Firefox:

In dem Screenshot sehen wir, dass der Tree ähnlich wie der DOM-Tree aussieht. Der Unterschied ist, dass DOM-Elemente, die keine Bedeutung haben, im Accessibility-Tree nicht auftauchen.

Hervorgehoben habe ich im Screenshot unsere Textbox. Durch die Verknüpfung mit dem Label hat diese einen Namen erhalten: „Vorname“. Nur so bekommen Screenreader-Nutzer*innen überhaupt die Information, für was die Textbox verwendet werden soll. Lasst ihr die Info weg, wird einfach nur „Textbox“ vorgelesen, und die Nutzer*innen müssen raten, was sie eintragen sollen.

Mit diesem semantischen Aufbau unseres Eingabefeldes haben wir WCAG 1.3.1 erfüllt. Diese Richtlinie besagt, dass (unter anderem) Informationen, die durch die visuelle Repräsentation gegeben sind, auch programmatisch transportiert werden müssen.

Keyboard-Navigation

Manche Nutzer*innen füllen Formulare nur mit dem Keyboard aus. Teilweise sind sie darauf angewiesen, weil sie keine Maus bedienen können. Aber auch viele technik-erfahrene Menschen greifen in Formularen auf das Keyboard zurück, weil es oft schneller ist, als mit der Maus zu klicken.

Die drei wichtigsten Kriterien für die Keyboard-Navigation in Formularen sind die Folgenden:

• Das Feld muss mit dem Keyboard erreichbar und ausfüllbar sein (WCAG 2.1.1)
• Es muss immer erkennbar sein, wo sich die Nutzer*innen gerade befinden (WCAG 2.4.7)
• Die Reihenfolge, in der Elemente angesprungen werden, muss logisch sein (WCAG 2.4.3)

Wenn ihr nur die Standard-HTML-Tags wie input oder select benutzt, sind diese automatisch mit dem Keyboard bedienbar. Aufpassen müsst ihr dann nur mit dem Styling: der Fokus und ggf. die ausgewählten Elemente müssen gut erkennbar sein, wie in WCAG 2.4.7 beschrieben.

Häufig werden aus Design-Gründen selbstgebaute Formularelemente oder Bibliotheken verwendet statt der Standard-Tags verwendet. Hierbei müsst ihr nicht nur auf die Keyboardnavigation, sondern auch auf die Semantik achten. Ein guter Leitfaden dafür ist der Aria Authoring Practices Guide (APG). Dort gibt es Beispiel-Implementierungen, die auf eine maximale Kompatibilität mit den WCAG abzielen.

Über die grundlegende Bedienung hinaus könnt ihr auch einige Erleichterungen für Keyboardnutzer*innen einbauen. Ein klassisches Beispiel ist das Absenden des Formulars mit Enter. Dabei sparen sich Nutzer*innen den Extra-Schritt, zum „Absenden“-Button zu springen.

Designanpassungen

Die Beispiele in diesem Artikel sind durchweg nicht gestylt. Moderne UIs erfordern natürlich auch ein entsprechendes Styling für Formularfelder. Ein wesentlicher Punkt dabei, aus Sicht der Barrierefreiheit, ist der Kontrast: Labels müssen einen Kontrast von mindestens 4.5:1 aufweisen; bei Icons ist es 3:1 (WCAG 1.4.3). Es gibt eine Vielzahl von Tools zur Überprüfung des Kontrasts, zum Beispiel den Contrast Checker von WebAIM oder das Browser-Plugin WCAG Color Contrast Checker.

Über die Platzierung des Labels solltet ihr euch auch Gedanken machen. Traditionell stehen Labels vor oder über einem Feld. In vielen modernen UIs stehen Labels im Feld und wandern bei Eingabe in den oberen Bereich (das sogenannte “Floating Label”). Ob das so optimal für die Barrierefreiheit ist, darüber gehen die Meinungen auseinander.

Worin sich alle einig sind: das Placeholder-Attribut darf nicht als Label  verwendet werden. Der Standard-Placeholder hat einen zu geringen Kontrast und verschwindet, wenn man tippt. Damit verstößt er gleich gegen zwei WCAG Kriterien: 3.3.2 und 1.4.3. Außerdem sorgt er für einige weitere UX-Probleme. In diesem Artikel der Norman-Nielsen-Group wird ausführlicher darauf eingegangen.

Fazit und Ausblick

Jetzt kennen wir die grundlegenden Aspekte, auf die wir bei der Barrierefreiheit von Formularen achten müssen:

• Semantik
• Keyboard-Navigation
• Kontrast

In Teil Zwei werden wir uns damit beschäftigen, wie wir die Nutzer*innen bei der Eingabe unterstützen können. Diesen Teil findet ihr hier.