Die Schwachstellen von Tools zum Testen der Barrierefreiheit – Labels und Eingabefelder

Formulare sind ein wichtiger Teil beim Testen der Barrierefreiheit, und es ist super wichtig, dass sie komplett barrierefrei sind. Auf den falschen Link auf einer Website zu klicken, kann nervig sein, aber eine Kreditkartennummer in einem Textfeld an den falschen Empfänger zu schicken, kann teuer werden und sogar vor Gericht landen.

In Joomla werden Felder und Beschriftungen als Kontrollgruppen richtig erstellt. Wenn wir aber Erweiterungen installieren oder ein Formular manuell erstellen, müssen wir sicherstellen, dass alles richtig und ohne Probleme bei der Barrierefreiheit umgesetzt wird.

Die Frage ist: Können wir uns darauf verlassen, dass die Barrierefreiheitsprüfungen alle Probleme finden?

Die relevanten WCAG 2.1-Regeln in diesem Artikel sind:

• 1.3.1 Informationen und Beziehungen: Informationen, Struktur und Beziehungen, die durch die Darstellung vermittelt werden, können programmgesteuert ermittelt werden oder sind in Textform verfügbar.
• 3.3.2 Beschriftungen oder Anweisungen: Beschriftungen oder Anweisungen werden bereitgestellt, wenn Inhalte Benutzereingaben erfordern.

Alles, was in früheren Artikeln der Reihe „Blinde Flecken von Tools zur Überprüfung der Barrierefreiheit” erwähnt wurde, gilt auch hier. Farbkontrast, Fokus, Tabulatorreihenfolge und Schaltflächen sind in Formularen wichtig.

Diese Artikel findest du hier: Fokus und Schaltflächen

Die für diesen Artikel verwendeten Tools zum Testen der Barrierefreiheit sind: Wave, IBM Accessibility Checker, AXE, Web Developer Tools, unser integrierter Barrierefreiheitsprüfer JOOA11Y und der Screenreader NVDA.

Web Developer Tools unterstützen das Testen von Formularen mit verschiedenen Funktionen:

Beschriftung und Feld

Eines der häufigsten Probleme bei der Barrierefreiheit sind fehlende Beschriftungen, vor allem bei Suchfeldern. Sehende Nutzer haben kein Problem damit zu verstehen, dass eine Lupe-Klasse „Gib hier dein Suchwort ein” bedeutet, aber assistive Technologien brauchen das <label>.

Alle Testtools schlagen Alarm, wenn sie ein Eingabefeld ohne Label oder verwaiste Labels finden. Ein Label kann für sehende Nutzer unsichtbar bleiben, aber es muss vorhanden sein und – das ist wichtig – es muss mit dem Feld verknüpft sein. Ist das nicht der Fall, kann es von assistiven Technologien nicht genutzt werden.

(Zur Klarstellung: Mit ARIA ist es möglich, ein Feld auch ohne <label> zugänglich zu machen, aber das ist nicht die beste Vorgehensweise).

Dies ist ein einfaches Formular, und ein Label-/Eingabefeld-Paar wird wie folgt geschrieben:

<label for="lname">Nachname</label>

<input id="lname" type="text">

Wenn die Beschriftung nicht mit dem Eingabefeld verknüpft ist, sehen sehende Benutzer keinen Unterschied, aber es ist ein Problem der Barrierefreiheit. Blinde Benutzer könnten nicht herausfinden, in welches Feld welche Daten eingegeben werden sollen.

<label>Nachname</label>

<input id="lname" type="text">

Für die Prüfung der Verknüpfung von Beschriftungen mit Eingabefeldern können wir uns auf die automatischen Testtools verlassen (außer bei vertauschten IDs).

Im folgenden Screenshot erkennt WAVE zwei Fehler: ein fehlendes Label und ein verwaistes Label. Alle anderen Tools kommen zu dem gleichen Ergebnis.

Pflichtfelder und optionale Felder

Siehst du, dass im obigen Formular das Feld „Nachname” ein Pflichtfeld ist?

<label for="lname">Nachname</label>

<input id="lname" type="text" required=„true“>

Tatsächlich ist dies eine der seltenen Situationen, in denen blinde Nutzer einen Vorteil haben: Ein Screenreader gibt bekannt, dass die Eingabe erforderlich ist. Für sehende Nutzer ist diese Anforderung nicht erkennbar. Kein automatisiertes Tool überprüft, ob Felder als erforderlich oder optional gekennzeichnet sind, und WCAG 2.1 enthält keine spezifische Regel oder Anforderung hierfür.

Normalerweise werden Pflichtfelder mit einem (aria-hidden) Sternchen (*) oder dem Text „(erforderlich)” gekennzeichnet, aber das ist eher eine Konvention als eine Regel.

In WCAG 2.1 wird das sehr gut als Technik H90 beschrieben.

Kein Accessibility-Checker kann feststellen, ob alle Pflichtfelder richtig gekennzeichnet oder beschrieben sind.

Platzhalter

Die Verwendung von Platzhaltern in Eingabefeldern ist an sich kein Problem für die Barrierefreiheit, sondern kann die Benutzererfahrung verbessern. Aus Sicht der Barrierefreiheit ist dies jedoch keine bewährte Vorgehensweise, wie im WCAG-Tutorial für Formularanweisungen beschrieben.

Platzhalter verschwinden, wenn der Benutzer mit der Eingabe beginnt, wodurch einige Informationen ausgeblendet werden. NVDA gibt den Platzhalter bekannt, wenn das Feld den Fokus erhält und nur dann, wenn keine Beschriftung vorhanden ist. Andere Screenreader verhalten sich möglicherweise anders.

Tools zum Testen der Barrierefreiheit berücksichtigen den Platzhalter nicht (mit Ausnahme von JOOA11Y, das eine Warnung anzeigt).

Der Bildschirm hier zeigt ein Beispiel. Die erste Beschriftung „Ablaufdatum” zeigt das erwartete Eingabeformat direkt in der Beschriftung an, das zweite Feld verwendet einen Platzhalter, der eine Warnung von Jooa11y auslöst.

Autofokus

Autofokus ist aus Sicht der Barrierefreiheit problematisch. Für Nutzer von Screenreadern bedeutet das, dass ein Teil der Infos auf einer Website, einschließlich der Beschriftung des Feldes, übersprungen wird. Im schlimmsten Fall kann das zu einer Fokusfalle für Tastaturbenutzer führen.

Alle Testtools ignorieren das Autofokus-Attribut, was mich überrascht hat. Ich hätte gedacht, dass das bei jedem Scan erkannt wird.

Fazit

Formulare bergen viele potenzielle Fallstricke. Barrierefreiheits-Tools werben zwar mit Erkennungsraten von bis zu 50 %, aber letztendlich erscheinen 30 % weitaus realistischer.

Wenn Sie Joomla! verwenden, brauchen Sie sich keine Sorgen zu machen. Das Joomla-Entwicklungsteam kennt diese Fallstricke genau. Wenn Sie sich an „nur Joomla!” halten, wird keines der in diesem Artikel genannten Probleme in Ihren Formularen auftreten.