Zweiter Blick: Formulare barrierefrei

BarrierefreiheitDarstellungsoptionen



Formulare barrierefrei

Checkboxen

Bedeutung von Formularen im Web

Bedeutung der Barrierefreiheit von Formularen

Formulare sind im Internet ein zentrales Mittel zur Interaktion (Kontakt, Anmeldung, Bestellung, …) oder Information (Suchformulare). Formularelemente müssen daher für alle in ihrer Funktionalität wahrnehmbar und verständlich sein, damit sie bedient werden können.

Formulare stellen vor allem in der technischen Umsetzung eine der größten Anforderung für das Barrierefreie Webdesign dar. Aber auch grafische und textuelle Aufgaben sind zu berücksichtigen.

Vorteile von Webformularen

Webformulare bieten gegenüber anderen Formaten für Formulare erhebliche Vorteile sowohl bei der technischen Realisierung, als auch für Benutzer und Benutzerinnen:

Vorteile für Benutzerinnen und Benutzer

Analoge, also ausgedruckte Formulare können von Menschen mit Sehbehinderung nur schwer oder mit persönlicher Assistenz ausgefüllt werden. Auch motorisch Beeinträchtigte, die über entsprechende Hardware für die Tastaturbedienung verfügen, profitieren von Webformularen.

Formularpersonalisierung

Umfangreichere Webformulare lassen sich mit Scripts gut individualisieren. So kann etwa gleich in anfänglichen Schritten nach relevanten Persönlichkeitsprofilen gefragt werden, die für die weitere Auswahl der Formularelemente von Relevanz ist.

Persönlichkeitsprofile könnten sein:

  • Privatkunde / Unternehmen / Behörde
  • Selbst betroffen / Erziehungsberechtigt / Sachwalter

Fragen, die nur eine bestimmte Zielgruppe des Formulars betreffen können so technisch fokussiert werden. Überflüssige und für andere Zielgruppen oft unverständliche Formularelemente können anders als in analogen Formularen oder üblichen PDF-Formularen effizient und zur Zufriedenstellung der User eliminiert werden.

Vorteile für die technische Realisierung

Webformulare, die mit HTML realisiert werden, sind im Vergleich zu Formularen im PDF-Format technisch relativ leicht zu realisieren. Zumindest gibt es kaum Fachkräfte, die wirklich saubere PDF-Formulare realisieren können.

Formulare, die in Textverarbeitungsprogrammen ausgefüllt werden können benötigen umfangreiche Mechanismen zur Sicherung des Kontextes eines Formularelements. Die Beschriftung sollte ja nicht einfach geändert werden können, weil dies die Auswertung der Eingaben maßgeblich erschweren würde. Maßnahmen zur Sicherung des Kontextes eines Formularelements gehen jedoch oft zu lasten der Wahrnehmbarkeit und damit Bedienbarkeit.

Webtechnologien für Formulare

HTML - Das zentrale Markup

Bedeutung eines adäquaten Markup

Der adäquate Einsatz von HTML-Elementen und Attributen stellt das Grundgerüst für barrierefreie Formulare dar. Die technische Umsetzung durch Browser und Assistierende Technologien wird damit am zuverlässigsten gewährleistet.

Was semantisch ein Formularelement ist, muss auch als solches mit der individuellen Funktionalität im HTML Markup gekennzeichnet sein. Ein SUBMIT -Button (OK / Weiter / Absenden / …), der nur als Link realisiert ist, wird von einem Screen Reader semantisch nicht richtig als Formularelement erkannt.

Darüber hinaus müssen teilweise Informationen über Werte und Zustände eines einzelnen Formularelements explizit mit HTML-Anweisungen für Screen Reader versehen werden, damit sie wahrnehmbar und bedienbar werden. Pflichtfelder können etwa auf diese Weise als solche gekennzeichnet werden.

Vorteile eines HTML Markup

Wo immer möglich, sollten Formulare mit HTML-Elementen und Attributen realisiert werden. Dies weist folgende Vorteile auf:

  • Browser und Assistierende Technologien setzen HTML-Formulare am zuverlässigsten um.
  • Der Aufwand bei der Erstellung, Prüfung und Korrektur ist erfahrungsgemäß am geringsten.
  • Die manuelle Auswertung von maschinellen Validationen ist verhältnismäßig einfach.

Das erste Argument hat unmittelbare Relevanz für Barrierefreiheit. Die beiden anderen Argumente erleichtern zugegebenermaßen mir und den technisch Verantwortlichen einfach die Arbeit.

ARIA - Anweisungen für Assistierende Technologien

Bedeutung von ARIA - Anweisungen

Wie für kaum eine Komponente bieten ARIA States and Properties Möglichkeiten, Formularelemente für Screen Reader verständlicher und bedienbarer zu machen.

Deren Einsatz muss jedoch korrekt verstanden und gut dosiert eingesetzt werden.

Das Verständnis Folgender ARIA-Anweisungen scheinen mir für Formulare besonders relevant:

JavaScript - Clientseitige Programmierungen

Bedeutung von JavaScript für die Barrierefreiheit

Mit JavaScripts lässt sich in Bezug auf Barrierefreiheit viel bewerkstelligen, aber auch viel anstellen. Eventhandler, Fehlerprüfungen und vielerlei andere Komponenten lassen sich mit ihnen verwirklichen.

Gemeinsam ist allen Möglichkeiten, dass sie mit maschinellen Validatoren bestenfalls als mögliche Problembereiche erkannt werden. Jedes einzelne Script ist daher insbesondere mit Screen Readern manuell zu testen. Generell können erfahrungsgemäß bei der Bedienung ohne Maus Probleme auftauchen.

Und nicht vergessen: Scripts können im Browser deaktiviert werden. Die Informationen und Funktionalitäten, die mit den Scripts verbunden sind, müssen in wesentlichen Bereichen trotzdem vorhanden bleiben.

Assistierende Technologien und JavaScript für die Barrierefreiheit

Elemente und Aktionen, die in Formularen mit Scripts realisiert werden, benötigen eine genaue Prüfung auf mögliche Erfordernisse für den Einsatz von ARIA States and Properties. Sie sollten auf jeden Fall auch mit aktuellen assistierenden Technologien auf deren Umsetzung getestet werden.

Wenn sich etwa durch Scripts mittels Eingaben in Formularelementen der Kontext ändern kann, muss dies für den Benutzer wahrnehmbar und verständlich sein. Die Änderung des Kontextes sollte von Mechanismen auf der Webseite bestimmt werden können.

CSS - Technische Gestaltung der visuellen Darstellung

Bedeutung der Darstellung mittels CSS

HTML-Elemente sollten in der Regel mit Stylesheets aus einer zentralen CSS Formatierung -Datei grafisch formatiert werden. Dies gilt natürlich auch für Formularelemente.

In Formularen sind bei der visuellen Gestaltung die Kontraste zwischen Schrift und Hintergrund und Fokuseffekte bei der Tastaturbedienung von Sehenden von Relevanz.

Fokuseffekte für Formularelemente

Mit der Tabulatortaste kann der Fokus im Browser von Link zu Link oder Formularelement bewegt werden. Für die Bedienung ohne Maus ist dieser Mechanismus von zentraler Bedeutung. Allerdings kann dieser Mechanismus zur Bedienung nur genützt werden, wenn am Bildschirm sichtbar ist, wo sich der Fokus gerade befindet.

Browser verändern visuell standardmäßig dezent Formularelemente, wenn sich der Fokus auf ihnen befindet. Ich empfehle, sich nicht auf den Browser zu verlassen und die visuellen Effekte in zentralen CSS-Dateien deutlich wahrnehmbar festzulegen. Üblich sind Veränderungen des Hintergrunds oder des Rahmens.

Landmark Roles für Formularelemente

Bedeutung von Landmark Roles

ARIA Landmark Roles sind eine Möglichkeit zur semantischen Kennzeichnung von Seitenbereichen. Sie können als solche von Assistierenden Technologien erkannt und bei der Nutzung insbesondere mit dem Screen Reader zur Navigation verwendet werden.

Für Formulare stehen die allgemeine Kennzeichnung als Formularbereich und die spezielle Kennzeichnung eines Suchbereichs zur Verfügung.

FORM (Landmark Role)

Ein Seitenbereich, der aus einer Ansammlung von Elementen und Objekten für eine Formularinteraktion besteht, sollte mit role="form" semantisch gekennzeichnet werden.

Der Formularbereich kann ein Mix aus HTML-Formularelementen, gescripteten Elementen und Links sein. Nach Möglichkeit sollten jedoch HTML-Formularelemente zum Einsatz kommen.

Der Bereich kann und soll in vielen Fällen auch beschreibende Elemente, wie Tooltipps, enthalten oder Mechanismen zur Fehlervermeidung oder Fehlererkennung.

Für Formulare mit expliziten Suchfunktionen sollte die Landmark Role Search eingesetzt werden. Es gelten für sie ansonsten die allgemeinen Anforderungen an Formularbereiche.

Typische Formularelemente (type-Attribut)

Bedeutung des Typs eines Formularelements

Die korrekte Verwendung von Elementtypen in Formularen sorgt nicht nur für eine adäquate Darstellung und allgemeinen für technische Funktionalitäten. Sie ist auch Voraussetzung für einzelne technische Funktionalitäten zur Verbesserung der Barrierefreiheit, etwa bei automatischen Vorschlägen bei der Eingabe in Textfeldern (autocomplete ).

Techniken zum Zuweisen eines Elementtyps

Für die wichtigsten Formularelemente stehen parallel HTML-Attribute und ARIA-Roles zur Verfügung. Es genügt, eines der beiden Verfahren zur Kennzeichnung zu verwenden.

Technisch verfügbare Elementtypen (HTML Input Types)

Standardtypen von Formularelementen

Type-Attribute für zentrale Formularelemente
Typ Verwendung
button Schalter ohne explizites Standardverhalten (im Gegensatz etwa zu submit oder reset).
checkbox Einzelne Kontrollkästchen, die angekreuzt und deaktiviert werden können.
password Ein einzeiliges Textfeld dessen Eingabewerte visuell und technisch nicht wahrnehmbar sind.
Mit den Attributen maxlength und minlength kann die Länge des Eingabewerts begrenzt werden.
Ich denke, es sollte nicht in Verbindung mit dem Attribut autocomplete verwendet werden.
radio Element, das eine singuläre Auswahl innerhalb einer Gruppe zur Verfügung stellt.
reset Schalter zum Zurücksetzen auf die Standardwerte, sprich zum Löschen aller Eingaben.
submit Schalter zum Absenden der Formulareingaben.
text Feld für einzeilige Texteingabe. Zeilenumbrüche werden automatisch entfernt.

HTML5-Typen von Formularelementen

Die Liste der Input-Types wird mit HTML5 deutlich erweitert. Auch dies ist als Indiz anzusehen, dass es wichtig ist, den korrekten Typ anzugeben.

Die mit den neuen Typen verbundenen Funktionalitäten sind für die Benutzung und den Betrieb von Formularen vielfach sehr hilfreich. Allerdings mangelt es noch an der Browser-Unterstützung, insbesondere unter Safari und im Internet Explorer (Stand Juli 2018).

Neue Elementtypen für Formulare in HTML5
Typ Verwendung
color Kontrollelement zum Festlegen einer Farbe.
Ob und wie dieser Typ für Style Switcher einzusetzen ist, ist noch zu klären.
date Ein Kontrollelement zur Eingabe eines Datums (Jahr, Monat und Tag ohne Zeitangaben).
datetime-local Kontrollelement zur Eingabe von Datum und Zeit ohne Zeitzone.
email Eingabefeld für eine E-Mail Adresse.
file Ein Kontrollelement zur Auswahl einer Datei.
Mit dem accept-Attribut können zulässige Dateiformate festgelegt werden.
hidden Ein verborgenes Kontrollelement, dessen Wert aber an den Server übermittelt wird.
image Ein grafischer Submit Button.
Für Screen Reader muss die Funktionalität etwa mittels alt="Absenden" verständlich gemacht sein.
month Ein Kontrollelement zur Eingabe eines Monats und Jahres ohne Angabe der Zeitzone.
number Ein Kontrollelement zur Festlegung einer Zahl.
range Ein Kontrollelement zur Eingabe eines Zahlenwerts, der nicht exakt sein muss.
search Ein einzeiliges Textfeld zur Eingabe von Suchausdrücken.
tel Eingabefeld für eine Telefonnummer.
time Kontrollelement zur Eingabe eines Zeitwerts ohne Zeitzone.
url Eingabefeld für eine URL.
week Kontrollelement zur Eingabe einer Wochennummer innerhalb eines Jahres ohne Zeitzone.

Obsolete Elementtypen

type="datetime" wird auf mozilla.org als obsolet angegeben. Sie berufen sich auf die Web Hypertext Application Technology Working Group (WHATWG). (Stand 2017)

Es war ursprünglich als Kontrollelement für eine exakte Zeitangabe von Jahr bis Sekunde und Zeitzone angedacht. Stattdessen wird type="datetime-local" empfohlen.

Die Entwicklung sollte auf den W3C Empfehlungen zu Formularen verfolgt werden.

Beschriftung und Beschreibung von Formularelementen

Bedeutung von Beschriftungen und Anleitungen

Formularelemente müssen sowohl visuell als auch technisch so beschriftet oder beschrieben sein, dass klar ist, welche Eingabe erforderlich ist. Dies empfiehlt sich insbesondere auch zur Fehlerprävention.

Beschriftung durch das HTML-Element <label>

Bedeutung der Beschriftung mit dem <label>-Element

Um ein Formularelement bedienen zu können, muss dessen Funktion visuell und technisch beschriftet werden. Am einfachsten und sichersten erfolgt dies durch einen adäquaten Text im <label>-Element von HTML.

Bei der Nutzung von Screen Readern ist es von zentraler Bedeutung, dass die Funktion und die Bezeichnung eines Formularelements technisch wahrnehmbar sind. Bei HTML-Formularen erkennt der Screen Reader die Funktion eines Formularelements aus dem type-Attribut des input-Elements. Er gibt wieder, ob es sich um ein Eingabefeld, eine Ausklappliste, einen Auswahlschalter oder Ähnliches handelt.

Darüber hinaus erleichtert der Einsatz des <label>-Elements zur Beschriftung von Formularelementen auch die Bedienung mit der Maus. Es genügt ein Klick auf die Bezeichnung des Elements, um den Fokus in das Eingabefeld zu setzen oder ein Auswahlelement zu aktivieren.

Technische Umsetzung von <label>-Beschriftungen

Die Syntax sieht etwa folgendermaßen aus:

<label for="nn">Nachname</label>
<input id="nn" type="text" ... >

Mit dem Attribut for im input-Element wird auf die ID des label-Elements referenziert. Die Beschriftung muss visuell verständlich im Formular platziert werden.

Anordnung von <label>- und <input>-Element

  • Bei Eingabefeldern oder Dropdown-Boxen sollte sich das <label> vor dem Formularelement befinden.
  • Bei Checkboxen und Radiobuttons sollte das <label> im Code hinter das Formularelement eingefügt werden, damit die entsprechenden Symbole für das Kontrollelement links vor dem Text angezeigt werden.

Die Reihenfolge ist nur ein Problem der visuellen Darstellung. Screen Reader liefern immer zuerst die Bezeichnung des Formularelements und dann den Typ bzw. den Zustand des Formularelements.

Gruppen von Auswahlelementen mit <legend> bezeichnen

Bedeutung der Beschriftung mittels <legend>

Eine Gruppe von Optionselementen (Radio Buttons) oder Checkboxen muss in ein <fieldset> eingebettet werden, das über eine knappe und adäquate <legend> verfügt. Auf diese Weise wird für den Screen Reader für die einzelnen Elemente jeweils auch der Kontext wiedergegeben. Bei einer entsprechenden CSS-Formatierung verbessert dies auch die Übersichtlichkeit eines Formulars.

Technische Beschriftung mittels <legend>

  • Ein <fieldset> umrandet den Formularbereich.
  • Die <legend> ist die Beschriftung für die Gruppe, die vom Screen Reader bei jedem einzelnen Optionselement wiedergegeben wird.

Beschriftung mittels aria-labelledby

Mit dem HTML-Element <label> kann jeweils nur ein einzelnes Formularelement bezeichnet werden. Es gibt jedoch Fälle, in denen mehrere Eingabefelder dieselbe Bezeichnung erhalten sollten.

Mit aria-labelledby kann auf eine gemeinsame Bezeichnung mehrerer Formularelemente referenziert werden. Dies kann beispielsweise die Spaltenüberschrift eines tabellarisch angeordneten Formulars sein.

Die Beschriftung erfolgt durch die Angabe der ID des bezeichnenden Elements. Die einzelnen Zellen der Spalte erhalten etwa folgenden Code:

<td><input type="text" aria-labelledby="th_age"

Die Spaltenüberschrift muss über eine eindeutige ID innerhalb der Datei verfügen und kann etwa folgendermaßen aussehen:

<th id="th_age">Alter</th>

Bewegt sich der Fokus in die Spalte, liest der Screen Reader die Spaltenüberschrift Alter vor.

Sollte einmal eine zweite Bezeichnung referenziert werden müssen, kann diese wiederum durch die eindeutige ID des bezeichnenden Elements erfolgen:

aria-labelledby="th_hugo th_age"

Der Screen Reader liest die Bezeichnungen in der Reihenfolge, in der die IDs angegeben sind. In diesem Beispiel wäre das etwa die Bezeichnung Hugo Alter für ein Eingabefeld in einer Tabellenzelle.

Werden für ein Formularelement sowohl das HTML Element <label> als auch aria-labelledby eingesetzt, liest der Screen Reader nur die Bezeichnung durch den ARIA-Befehl vor.

<label> oder aria-labelledby?

Der große Vorteil von aria-labelledby ist, dass die Eins-zu-Eins Relation zwischen Bezeichnung und bezeichnetem Formularelement aufgebrochen werden kann. Besteht jedoch eine Eins-zu-Eins Relation, sollte das HTML <label> Element verwendet werden. Nur so kann durch Klick auf die Bezeichnung der Fokus in das Formularelement gesetzt werden.

aria-describedby: Hinweise für fokussierte Elemente

Es gibt Fälle, wo ein Screen Reader Erläuterungen vorlesen soll, wenn ein Formularelement den Fokus erhält. Diese Erläuterungen werden vom Formularelement zweckmäßigerweise mittels aria-describedby referenziert.

Tooltipps

Es kann gelegentlich hilfreich und zweckmäßig sein, für Formularelemente ergänzend zur Beschriftung Hinweise als Tooltipps anzubieten.

Der Tooltipp wird angezeigt, wenn sich die Maus über dem Element befindet (Hover-Effekt). Er muss aber auch erscheinen, wenn sich der Fokus durch Tastatureingaben auf dem Element befindet (Fokus-Effekt).

Je nach eingesetzter Technik und Inhalt des Tooltipps kann es auch sinnvoll sein, den Text mittels aria-describedby für Screen Reader gesondert verfügbar zu machen.

Ausdrücke und Formulierungen

Formularelemente verfügen zweckmäßigerweise über kurze und knappe Texte. Für das Verständnis der jeweiligen Formularelemente ist es daher umso wichtiger, sich über die Gestaltungen der einzelnen Ausdrücke oder Formulierungen Gedanken zu machen. Sie finden hier Tipps, die ich aus meiner Erfahrung gesammelt habe.

  • Die Bezeichnung der Schaltflächen soll verständlich sein. Submit oder Los! sind etwa möglicherweise keine adäquaten Bezeichnungen für Schalter. Anmelden, Suchen, Absenden oder Weiter könnten präzisere Formulierungen sein.
  • Die Bezeichnung von Schaltern sollte innerhalb eines Webauftritts konsistent sein, sofern derselbe Kontext besteht. (Anmelden / Bestellen / Los geht’s / Suchen / Weiter, …)
  • Negative Formulierungen sollen vermieden werden, wie etwa:
    Ich möchte keinen automatischen Fokus.
    Besser: Fokus automatisch in das erste Formularelement setzen.).
    Der Programmcode muss natürlich entsprechend auch an die Formulierungen angepasst werden.

Unsichtbare Formularbeschriftungen

Es gibt Fälle, in denen eine sichtbare Formularbeschriftung nicht wirklich Sinn macht oder nötig ist. Dies gilt insbesondere für das Eingabefeld für Suchbegriffe auf Webseiten. Die Position auf der Webseite und der dazugehörige Suchen-Schalter machen die Bedeutung des Eingabefeldes für sehende Menschen klar.

Für den Screen Reader sollte jedoch auf eine der folgenden Weisen eine Beschriftung des Suchfeldes erfolgen:

  • Ein HTML <label> Element wird mittels CSS Anweisungen vom Bildschirm verborgen. Üblicherweise wird für diese Technik eine CSS-Klasse sr-only angelegt.
  • Das Formularelement erhält ein title – Attribut, das vom Screen Reader dann vorgelesen wird, wenn kein Label vorhanden ist.
  • Das Formularelement erhält ein aria-label – Attribut mit der Bezeichnung des Formularelements, z.B. aria-label="Suchausdruck".

Anmerkungen

  • Es genügt jeweils eine dieser drei Varianten einzusetzen. Eine Kombination von mehreren dieser Strategien kann dazu führen, dass der Screen Reader die Bezeichnung wiederholt.
  • Ein Platzhalter im Eingabefeld ist keine ausreichende Strategie, weil Screen Reader Platzhalter teilweise ignorieren.
  • Unsichtbare Beschriftungen stellen für Menschen, die mit Spracheingabe arbeiten, ein Problem dar.

Fazit

Um den Bedürfnissen von Mausbedienung, Screen Readern und Spracheingabe zu entsprechen, schlage ich folgende Schritte vor:

  1. Das Eingabefeld wird ganz klassisch mit einem <label>-Element beschriftet, damit Screen Reader zuverlässig eine Bezeichnung des Formularelements angeben.
  2. Das <label>-Element wird mit CSS-Anweisungen zum Verbergen vom Bildschirm versehen, um das Eingabefeld für Sehende nicht zu überfrachten.
  3. Das <input>-Element erhält einen Platzhalter, in dem die Bezeichnung des Eingabefelds für eine Spracheingabe sichtbar wiedergegeben wird.

Der Code könnte also etwa folgendermaßen aussehen:

<label
  for="search"
  class="sr-only">
  Suchbegriffe
</label>
<input
  id="search"
  type="search"
  placeholder="Suchbegriffe" />

Die CSS-Klasse sr-only muss dafür sorgen, dass der Text vom Bildschirm verborgen wird und nur für Screen Reader zugänglich ist.

Best Practise Beschriftung und Beschreibung für Eingabefelder

Best Practise Beispiel für Eingabefelder

<label for="vsnr-id">
  Versicherungsnummer
</label>
<p
  class="input-hint"
  id="vsnr-hint">
  Sie finden Ihre Versicherungsnummer etwa auf Ihrer E-Card, die Sie beim Arztbesuch benötigen. <br />
  Beispiel: <samp>1234 110174</samp>.
</p>
<input
  aria-describedby="vsnr-hint"
  id="vsnr-id"
  name="vsnr"
  type="text" />

Pflichtfelder (required)

Bedeutung von Pflichtfeldern

Pflichtfelder sind Formularelemente oder Bereiche, die unbedingt ausgefüllt werden müssen. Typischerweise werden diese Felder mit dem Zeichen * (Sternchen) oder einem speziellen Icon versehen.

Es gibt Möglichkeiten zur technischen Kennzeichnung von Pflichtfeldern. Zudem sollten die visuellen Indikatoren für Zielgruppen reflektiert erklärt und angeordnet werden.

Technische Realisierung von Pflichtfeldern

Attribute für verpflichtende Eingabefelder

Zur technischen Kennzeichnung unbedingt erforderlicher Eingaben steht das ARIA-Attribut aria-required="true" zur Verfügung. In HTML5 genügt es darüber hinaus schlicht required als Attribut in das <input>-Element einzufügen.

<input type="email" required ... />

Optionsgruppen oder Kontrollelemente als Pflichtfelder

Bedeutung von Pflichtfeldern für Optionsgruppen oder Kontrollelemente

In einem Onlineformular für eine Pizzabestellung kann es erforderlich sein, dass eine bestimmte Pizza oder deren Belegung eine verpflichtende Eingabe erfordert. Ebenso kann ein Kontrollkästchen zur Zustimmung zu den AGB für die Absendung relevant sein.

Problematiken bei verpflichtenden Optionselementen oder Checkboxen

Einzelne Elemente einer Optionsgruppe oder Checkboxen sollten (natürlich) nicht als Pflichtfelder gekennzeichnet werden. Dies wäre zu missverständlich und könnte zu Fehleingaben führen.

Der Screen Reader JAWS meldet in einer Optiongroup für Beilagen zur Hauptspeise mit verpflichtender Eingabe etwa folgendes, wenn sich der Fokus auf Kartoffel befindet:

Nicht Aktiviert Erforderlich Auswahlschalter Kartoffel.

Ein einzelnes Kontrollkästchen zur Zustimmung zu rechtsverbindlichen Bestimmungen kann natürlich als Pflichtfeld vor der Datenabsendung vorgesehen werden.

Technik der Kennzeichnung verpflichtender Optionselemente oder Checkboxen

Wenn eine Auswahl in einer Gruppe von Formularelementen erforderlich ist, muss die ganze Gruppe als verpflichtend gekennzeichnet werden. Es empfiehlt sich, das Attribut in das übergeordnete Element einzufügen.

Das übergeordnete Element könnte das <fieldset> sein oder die <ul> in einer Liste von Checkboxen. Leider ist die Umsetzung in Browsern und Assistierenden Technologien sehr unzuverlässig

<ul required>
  Folgende Optionen stehen zur Verfügung:
  ...
</ul>

Visuelle Realisierung von Pflichtfeldern

Visuelle Indikatoren zur Kennzeichnung von Pflichtfeldern

Üblicherweise werden Sternchen (*) oder Icons zur visuellen Kennzeichnung von Pflichtfeldern verwendet. Da diese trotzdem nicht als allgemein bekannt angesehen werden können, bedürfen sie textlicher Erläuterungen.

Am Beginn des Formularbereichs muss daher eine Erklärung erfolgen und nicht erst am Ende oder irgendwo außerhalb des Formulars. Anmerkungen in Fußnoten kennen wir zwar aus Textdokumenten, diese sind jedoch für Webseiten nicht geeignet.

Zusätzlich können das Sternchen oder das Icon mit einem TITLE-Attribut versehen werden.

Weil das Sternchen standardmäßig sehr klein erscheint, ist es fein, wenn es vergrößert wird. Entsprechende visuelle Darstellungen können mittels CSS-Anweisungen oder dem HTML-Element <strong> realisiert werden.

Textuelle Erläuterungen bei Pflichtfeldern

Es kann abhängig von der Zielgruppe überlegt werden, als Text etwa Eingabe erforderlich grundsätzlich in der Beschriftung anzufügen.

Screen Reader und visuellen Kennzeichnungen von Pflichtfeldern

Wenn das Pflichtfeld technisch korrekt als solches gekennzeichnet ist, sollten der visuelle Indikator oder eine textuelle Erläuterung mittels aria-hidden für den Screen Reader verborgen werden. Ansonsten kommt es zu redundanten Meldungen durch die Sprachausgabe.

Solange required-Attribute nicht zuverlässig von Browsern und Assistierenden Technologien unterstützt werden, sollten Icons zur Kennzeichnung von Pflichtfeldern mit einem Alternativtexte versehen werden.

CSS-Anweisungen für Pflichtfelder

Elemente mit aria-required="true" können auch mit CSS hervorgehoben werden. Der Code kann etwa folgendermaßen aussehen:

[required], [aria-required=true] {
  border: red dotted 1px;
}

Usability Überlegungen zu Pflichtfeldern

Pflichtfeld minimieren auf das Notwendige

Formularelemente sollten sich auf das nötige Minimum beschränken, damit das Ausfüllen mit einem minimalen Aufwand möglich ist. Ebenso sollte sich die Kennzeichnung als Pflichtfeld innerhalb eines Formulars auf das Wesentliche konzentrieren.

In einem Kontaktformular sind wohl meist nur die E-Mail Adresse und eine Telefonnummer wirklich unbedingt erforderlich. Zusätzliche Wohnortangaben dürften dann darüber hinaus nur selten noch als verpflichtend notwendig sein.

Pflichtfelder, die sich aus dem Kontext ergeben, müssen auch nicht extra als solche gekennzeichnet werden. Dies gilt etwa für das Eingabefeld für Suchbegriffe in einem Suchformular oder das Eingabefeld für die E-Mail Adresse in einem Anmeldeformular für einen Newsletter.

Einheitliche Darstellung von Pflichtfeldern

Pflichtfelder lassen sich textuell und technisch auf unterschiedliche Weisen realisieren. Innerhalb eines Formulars und möglichst auch innerhalb eines Webauftritts sollten jedoch Pflichtfelder einheitlich wahrnehmbar sein. Unterschiedliche textuelle oder technische Realisierung ist nur nach gründlicher Überlegung zulässig.

Platzierung des visuellen Indikators für ein Pflichtfeld

Ein * oder Icon zur Kennzeichnung eines Formularelements als Pflichtfeld wird üblicherweise links vor dem Text des Elements platziert.

Eine volltextuelle Kennzeichnung, etwa mit (Erforderlich) hingegen dürfte eher hinter dem Text erwartet werden.

Pflichtfelder nur für Screen Reader

Das Attribut aria-required sollte nur dann eingesetzt werden, wenn ein visuelles Pendant in Form eines Sternchens oder Icons erforderlich scheint. Es gibt wohl kaum Pflichtfelder nur für Menschen die auf Screen Reader angewiesen sind.

autocomplete: Automatisches Vervollständigen von Texteingaben

Bedeutung des automatischen Vervollständigens

Automatische Vorschläge bei der Eingabe kennen wir von Suchmaschinen oder dem Suchformular von Wikipedia. Gelegentlich wird im Eingabefeld für eine E-Mail Adresse auch schon die eigene Adresse vorgeschlagen.

Nach den ersten Eingaben in einem Eingabefeld erscheinen Vorschläge für die weitere Eingabe. Diese können singulär innerhalb der Eingabezeile oder als Gruppe von Vorschlägen unterhalb des Eingabefeldes dargestellt sein.

Solche Funktionalitäten können den Eingabevorgang beschleunigen und der Fehlerprävention dienen.

Technische Umsetzung von Eingabevorschlägen

Mit dem HTML Attribut autocomplete kann festgelegt werden, ob eine automatische Ergänzung oder Eingabevorschläge zulässig sind. Die Syntax sieht folgendermaßen aus:

<input autocomplete="on|off">
  • Voraussetzung ist zunächst, dass der Browser diese Funktionalität überhaupt unterstützt bzw. sie aktiviert ist.
  • Um präzise Vorschläge geben zu können, muss der individuelle HTML Input Types des Eingabefeldes mit einem möglichst präzisen type-Attribut vorgegeben werden.

aria-autocomplete-Attribut

Mit dem aria-autocomplete-Attribut kann für den Screen Reader angegeben werden, in welcher Form Eingabevorschläge dargeboten werden.

Werte für aria-autocomplete
Wert Verwendung
inline Nach der ersten Eingabe kann im Eingabefeld ein Eingabevorschlag eingeblendet werden. Die vorgeschlagene Ergänzung befindet sich nach dem Cursor.
list Bei der Eingabe steht ein Element zur Verfügung, das verfügbare Werte in einer Liste darstellt.
both Bei der Eingabe steht eine Liste mit Vorschlägen zur Verfügung. Es ist jedoch auch eine Eingabe unabhängig von den Vorschlägen möglich.
Das Element der Liste ist hervorgehoben, das am ehesten dem vermuteten Eingabewunsch entspricht. Im Eingabefeld erscheint die entsprechende Textergänzung hinter dem Cursor.
none (Standardwert) Keine Eingabewerte werden vorgeschlagen.

Beim Einsatz einer Auswahlliste kann ein ganzer Strauß an ergänzenden ARIA-Attributen für die technische Umsetzung erforderlich sein. Ich verweise momentan nur auf die Spezifikation und weiterführende Links in der folgenden Sammlung.

Ein Problem scheint mir dabei jedoch, dass bei einem adäquaten Einsatz von HTML Input-Typen schon standardmäßig erforderliche Wahrnehmbarkeit und Bedienbarkeit in vielen Bereichen gewährleistet wird und ein zusätzlicher Einsatz von ARIA-Attributen zu überbordenden und redundanten Zusatzinfos durch Screen Reader führen kann. Eine sorgfältige Reduktion auf das nötige sollte daher in den gängigen Browser / Assistierende Technologien - Kombinationen getestet werden.

Platzhalter zur Beschreibung von Eingabefeldern (placeholder-Attribut)

Bedeutung des Platzhalter-Attributs

Textfelder in Formularen können mittels placeholder einen sichtbaren Hinweis zu Eingabemöglichkeiten erhalten. Der Text des Platzhalters wird im Browser gegraut dargestellt. Dies kann die intuitive Bedienung erleichtern. Der Platzhalter verschwindet jedoch bei der Eingabe.

Platzhalter sind keine hinreichende Methode zur Beschriftung von Eingabefeldern. Sie können bestenfalls für einige einen ersten Eingabehinweis darstellen, der wohl besser generell sichtbar und wahrnehmbar realisiert wird.

Erstellen von Platzhaltern

Der Code kann beispielsweise so aussehen:

<input id="search" name="suche" placeholder="Suchausdruck" type="search" />

Der Text des Platzhalters sollte möglichst knapp gehalten werden. Höfliche Anweisungen wie Bitte Suchbegriff eingeben sind nicht nötig. Es genügt der Ausdruck Suchbegriff.

Problematik von Platzhaltern

Platzhalter können für eine erste Kurzbeschreibung von Eingabefeldern eingesetzt werden. Bei deren Einsatz sollten jedoch folgende Problembereiche berücksichtigt werden:

  • Platzhalter stellen keine ausreichende Beschriftung für Formularelemente dar.
  • Die Beschreibung, die ein Platzhalter bietet, verschwindet, sobald eine Eingabe erfolgt ist.
  • Platzhalter können über zu geringe Kontraste verfügen, weil sie gewöhnlich ergraut erscheinen. (Gibt es überhaupt zuverlässige Verfahren zum Styling?)
  • Platzhalter gewährleisten keine programmtechnischen Funktionalitäten für fremdsprachige Systemeinstellungen.
  • Platzhalter könnten als vorausgefüllte Felder missverstanden und dadurch übersprungen werden.

Es muss also in jedem Fall für eine adäquate Beschriftung gesorgt werden und erforderliche Beschreibungen müssen visuell und technisch auf andere Weise verfügbar sein.

autofocus-Attribut: Direkter Einstieg in einem Formularelement

Bedeutung des Autofokus

Mit dem Attribut autofocus in einem Formularelement kann beim Laden einer Seite der Tastaturfokus automatisch in das Element gesetzt werden. Dies kann bei Seiten, die alleine zum Suchen oder Login dienen, von Vorteil sein.

Allerdings kann der Einsatz dieses Attributs insbesondere bei der Arbeit mit einem Screen Reader und allgemein bei der Tastaturbedienung zu Missverständnissen und Problemen führen.

Techniken zum Einsatz von Autofokus

Code für Autofokus

Um den Fokus beim Laden direkt in ein Formularelement zu setzen, genügt es, als Attribut autofocus in das input-Element einzufügen. Dies kann etwa folgendermaßen aussehen:

<input type="search" autofocus ...>

Technische Usability-Überlegungen für Autofokus

Wenn sich außerhalb des Formularelements relevante Informationen zum Ausfüllen befinden, müssen diese Beschreibungen mit aria-describedby an den Screen Reader übergeben werden.

Der Fokus sollte gegebenenfalls natürlich immer auf das erste Formularelement gesetzt werden.

Opt-In Mechanismus für Autofokus

Wenn ich eine Seite mit einem von mir häufig benötigten Formular kenne, kann ein Opt-In Mechanismus für einen Autofokus hilfreich sein. Ich kann selbst bestimmen, dass der Fokus beim Laden einer Seite automatisch in ein Formularfeld gesetzt ist und ich mir dadurch einige wenige Tastaturbefehle erspare.

Problemfelder beim Einsatz von Autofokus

Potentielle Problemfelder für Screen Reader beim Einsatz von Autofokus

Bei der Benutzung von Screen Readern wird der Fokus gewöhnlich am Beginn einer Seite erwartet. Eine Navigation mittels Tabulator oder Pfeiltasten erfolgt daher gewöhnlich nach unten. Informationen oder Funktionen oberhalb des automatisch fokussierten Formularelements können daher leicht übersehen werden.

Ein Screen Reader gibt zwar gewöhnlich durch ein typisches akustisches Signal das Betreten eines Eingabefeldes bekannt. Es kann trotzdem für einige bei der Nutzung von Screen Readern verwirren, wenn sich der Fokus nicht am Beginn der Seite befindet.

Potentielle Problemfelder mit der Tastatur beim Einsatz von Autofokus

Menschen, die ohne Screen Reader auf die Tastaturbedienung angewiesen sind, können unter Umständen nicht mehr effizient zum Seitenanfang navigieren. STRG + Pos1 bewegt möglicherweise im Browser nur den Bildschirm, aber nicht den Fokus.

Verwendungsgebiete von Autofokus

Für reine Suchseiten, Login-Seiten oder Rechner ist ein Autofokus wohl zu überlegen. Ansonsten sollte dieses Attribut vermieden werden.

Komplexe Komponenten in Formularen

Eingabefelder, Checkboxen oder Optionsgruppen sind einfache Typen von Formularelementen. Darüber hinaus gibt es höchst komplexe Komponenten in Formularen. Einige davon erarbeite ich auf folgenden Seiten:

Fehler vorbeugen, erkennen und zur Behebung beschreiben

Bedeutung der Fehlerbehandlung

Bei der Eingabe in Textfelder, gelegentlich aber auch beim Bearbeiten von Optionselementen oder Checkboxen können Fehler auftreten. Wo diese technisch erkannt werden können, müssen sie aufgearbeitet werden.

Damit Fehler oder Mängel behoben werden können, müssen folgende Punkte gewährleistet werden:

  • Das Vorhandensein eines Fehlers oder Mangels muss wahrnehmbar sein.
  • Für die Fehlerbehebung muss eine verständliche Anleitung in textueller Form vorhanden sein, die auch für Screen Reader zugänglich ist.
  • Lassen sich Gründe für Mängel technisch erheben, sollte die Anleitung zur Fehlerbehebung individualisiert werden.

Fehlerprävention

Um mangelhaften Eingaben vorzubeugen, empfehlen sich folgende Maßnahmen:

  • Die semantische Bedeutung eines Formularelements muss technisch sauber realisiert werden, etwa als Eingabefeld, Optionselement, Pflichtfeld und Ähnliches.
  • Die Beschriftung der Formularelemente muss textuell und technisch wahrnehmbar sein.
  • Die Beschriftung der Formularelemente muss textuell verständlich sein.
  • Für potentiell missverständliche Formularelemente sollten Erläuterungen oder Hilfetools verfügbar sein.

Fehlererkennung

Fehlende oder fehlerhafte Eingaben, die technisch erkannt werden können, müssen als fehlend oder mangelhaft analysiert werden, um sie adäquat vermitteln zu können.

Dies ist zunächst ganz leicht bei leeren Pflichtfeldern möglich. Eine offensichtlich fehlerhafte Eingabe liegt etwa bei E-Mail Adressen vor, wenn sich im Text klein Klammeraffe befindet. Namen enthalten nur im aristokratischen Kontext selten einmal Ziffern.

Fehlerbehebung durch Fehlerbeschreibung

Für die Fehlerbehebung sind folgende Punkte zweckmäßig:

  • Auf den Fehler wird visuell und technisch auf deutlich wahrnehmbar Weise hingewiesen.
  • Das fehlerhafte Formularelement sollte unmittelbar (wieder) den Fokus erhalten oder in der Fehlermeldung verlinkt sein.
  • Die bereits eingegebenen Angaben sind nicht verloren, sondern wurden bereits zwischengespeichert und werden erneut im Formular eingeblendet.
  • Bei komplexen Formularen ist es zweckmäßig, wenn vor dem definitiven Absenden die (technisch geprüften) Eingaben noch einmal zur Bestätigung aufgelistet werden.

aria-invalid: Technische Kennzeichnung von fehlerhaften Eingaben

Bedeutung der technischen Kennzeichnung von fehlerhaften Eingaben

Mit aria-invalid="true" können Formularelemente mit mangelhaften Eingaben technisch als solche gekennzeichnet werden. Der Vorteil gegenüber einer rein textuellen Warnung ist, dass etwa der Screen Reader auch auf fremdsprachigen Seiten den Fehlerhinweis auf Deutsch geben kann, sofern Deutsch als Standardsprache eingestellt ist.

Allerdings kann mit aria-invalid nur darauf hingewiesen werden, dass eine fehlerhafte Eingabe vorliegt. Anleitungen zur Fehlerbehebung müssen ergänzend zu diesem Attribut eingesetzt werden.

aria-errormessage: Referenzieren zu Fehlerhinweisen

Bedeutung des Referenzierens zu Fehlerhinweisen

Das Attribut aria-errormessage stellt technisch einen Spezialfall des aria-describedby-Attributs für Fehlermeldungen dar. Es kann damit auf ein Element mit erläuternden Hinweisen referenziert werden.

Technische Realisierung

Testbeispiel

Ihre eingegebene E-Mail Adresse enthält kein @-Zeichen!

Konformitätsstufe AAA für Formulare

Bedeutung der Konformitätsstufe AAA für Formulare

Die Konformitätsstufe AAA (Triple A) wird gesetzlich nirgends verlangt und auch von der WAI nicht als realistisches Ziel angesehen. Trotzdem empfiehlt es sic im Hinblick auf Zielgruppen Seitenbereiche über die rechtlichen Anforderungen hinaus zu optimieren.

Gerade beim Ausfüllen von Formularen sollten Überlegungen zu Usability und Konformitätsstufe AAA (Triple A) erfolgen. Diese Bedienungsüberlegungen erleichtern nicht nur aus der Perspektive des Frontend. Sie führen auch zu valideren Formulardaten zur weiteren Verarbeitung.

Erfolgskriterien der Konformitätsstufe AAA für Formulare

Folgende Triple A Erfolgskriterien erscheinen mir für Formulare zur Optimierung der technischen Barrierefreiheit relevant: