Formulare barrierefrei
[Materialsammlung]
Bedeutung von Online Formularen
Nutzen von Online Formularen für alle
Formulare sind im Internet ein zentrales Mittel zur Interaktion. Mit ihnen wird kommuniziert, gesucht oder bestellt und das unabhängig von Öffnungszeiten.
HTML-Formulare lassen sich im Gegensatz zum Papierformat oder PDF dynamisch verändern. Wer einmal als Familienstand alleinstehend angeklickt hat, braucht beispielsweise nicht mehr den Formularbereich über Haushaltsangehörige angezeigt bekommen. Fragen, die nur eine bestimmte Zielgruppe des Formulars betreffen können so technisch fokussiert werden. Mit entsprechenden Vorkehrungen werden Formulare dadurch kürzer und verständlicher.
Webformulare können bei entsprechenden technischen Vorkehrungen teilweise vorausgefüllt erscheinen. Auf fehlerhafte Eingaben kann individuell hingewiesen werden. Mit derartigen Mechanismen wird das Ausfüllen erleichtert.
Vorteile aus der Barrierefreiheit
Analoge, also ausgedruckte Formulare können von Menschen mit Sehbehinderung nur schwer oder nur mit persönlicher Assistenz ausgefüllt werden. Auch motorisch Beeinträchtigte, die über entsprechende Hardware für die Tastaturbedienung verfügen, profitieren von Webformularen. Mechanismen zur einfacheren Bedienung und besseren Verständlichkeit erleichtern Menschen mit Lernbehinderung oder geringeren Sprachkenntnissen das Ausfüllen.
Einzelne Formularelemente müssen dabei für alle in ihrer Funktionalität wahrnehmbar und verständlich sein, damit sie bedient werden können. Insbesondere beim Ausfüllen mit Sprachausgabe, allein mit der Tastatur oder Spracheingabe müssen Beschriftungen sowohl visuell als auch technisch wahrnehmbar sein.
Vorteile für den Betrieb einer Webseite
Formulare stellen vor allem in der technischen Umsetzung eine der größten Anforderung an das barrierefreie Web Design dar. Aber auch grafische und textuelle Aufgaben sind zu berücksichtigen. Ein Einsatz in dieser Königsdisziplin des Web Designs zahlt sich trotzdem aus:
- 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.
- Webformulare erlauben Mechanismen zur Gewährleistung valider Eingaben. Fehler können teilweise maschinell erkannt und mit Hinweisen versehen werden.
- Formulardaten können technisch ausgewertet werden und reduzieren dadurch den Verwaltungsaufwand.
- Barrierefreie Online-Formulare ermöglichen einer größeren Zielgruppe ein selbständiges und korrektes Ausfüllen.
Webtechnologien für Formulare
HTML für Markup und Attribute
Bedeutung eines adäquaten Markup
Der adäquate Einsatz von HTML-Elementen und Attributen sollte das Grundgerüst für barrierefreie Formulare darstellen. Die technische Umsetzung durch Browser und assistierende Technologien wird damit am zuverlässigsten gewährleistet.
HTML ermöglicht eine präzise semantische Kennzeichnung. Was etwa semantisch ein Formularelement ist, muss auch als solches mit der individuellen Funktionalität im HTML Markup gekennzeichnet sein. Ein SUBMIT -Button (Anmelden / Absenden / …), der als Link realisiert ist, wird von einem Screen Reader semantisch nicht korrekt als Formularelement erkannt.
Attribute innerhalb der HTML-Elemente sind vielfach zur Präzisierung (Formulartyp) oder speziellen Kennzeichnung (Pflichtfeld) erforderlich. Die jeweiligen Anforderungen können dabei durchaus individuell und detailreich sein.
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 technischen Erstellung, Prüfung und Korrektur des Formulars ist erfahrungsgemäß am geringsten.
- Die manuelle Auswertung von maschinellen Validationen ist verhältnismäßig einfach.
Das erste Argument hat unmittelbare Relevanz für die Barrierefreiheit. Die beiden anderen Argumente erleichtern zugegebenermaßen mir und den technisch Verantwortlichen einfach die Arbeit.
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.
Links zu CSS für die visuelle Gestaltung von Formularen
ARIA Attribute
Bedeutung von ARIA-Anweisungen
ARIA (Accessible Rich Internet Applications) ist eine Sammlung von Attributen mit Zusatzinformationen speziell für assistierende Technologien, insbesondere Screen Reader. Mit ihrer Hilfe können in Formularen vor allem semantische Informationen (ARIA Roles) zugewiesen oder Metainformationen (ARIA-States) wiedergegeben werden.
Mit Rich Internet Applications wird im Namen bereits auf komplexere Webkomponenten verwiesen, die mit Scripts realisiert werden müssen. Für sie ist die breite Palette an Attributen für Rollen und Zuständen konzipiert. Bei korrektem Einsatz von HTML5 kann auf ARIA vielfach verzichtet werden.
Der Einsatz von ARIA-Attributen muss kompetent erfolgen und gut dosiert werden. Was hilfreich oder notwendig sein kann, ist bei falschem Einsatz Quelle von Barrieren oder Nutzungsproblemen. So stoße ich in HTML-Formularen selten auf fehlende, sehr häufig jedoch auf falschen oder überbordenden Einsatz von ARIA.
JavaScripts für Formulare
Scripts sind für die Barrierefreiheit eines Formulars erlaubt und vielfach auch erforderlich. Allerdings sollten im Hinblick auf deren Barrierefreiheit und Gebrauchstauglichkeit Tests mit konkreten Menschen durchgeführt werden. Maschinelle Tests genügen nicht und Fachkräfte für Barrierefreiheit sollten in jedem Fall beigezogen werden.
Formularelemente
Kombiniertes Eingabefeld (Combobox)
- [Adam Silver] Building an accessible autocomplete control
- Eine detailreiche Anleitung zur Realisierung eines barrierefreien kombinierten Eingabefeldes. Quer über alle Webtechnoligien mündet dieser Artikel in ein funktionierendes Beispiel (Demo), das mich sehr überzeugt hat. (Stand Juni 2020)
Landmark Roles für Formularbereiche
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.
SEARCH (Landmark Role)
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 allgemein 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
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. |
email |
Eingabefeld für eine E-Mail Adresse. |
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. |
tel |
Eingabefeld für eine Telefonnummer. |
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).
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.
Links zu Elementtypen in Formularen
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.
Testdatei zur Anordnung des <label>-Elements
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>
beschriften
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.
Links zu <legend> im <fieldset>
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
oderLos!
sind etwa möglicherweise keine adäquaten Bezeichnungen für Schalter.Anmelden
,Suchen
,Absenden
oderWeiter
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 wenige Fälle, in denen eine sichtbare Formularbeschriftung nicht als unbedingt nötig angesehen wird. 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-Klassesr-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.
- Labeling Controls > Hiding label text
- Das W3C-Tutorial erlaubt eine vom Bildschirm versteckte Beschriftung bei Suchformularen, wenn der Zweck aus dem Kontext verständlich ist (assoziierter
Suchen
-Schalter)
Fazit
Um den Bedürfnissen von Mausbedienung, Screen Readern und Spracheingabe zu entsprechen, schlage ich folgende Schritte vor:
- Das Eingabefeld wird ganz klassisch mit einem
<label>
-Element beschriftet, damit Screen Reader zuverlässig eine Bezeichnung des Formularelements angeben. - Das
<label>
-Element wird mit CSS-Anweisungen zum Verbergen vom Bildschirm versehen, um das Eingabefeld für Sehende nicht zu überfrachten. - 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" />
Links zu Beschriftungen und Beschreibungen von Formularelementen
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.
Optionale Eingaben kennzeichnen
Alternativ kann überlegt werden, lediglich optionale Felder textuell zu kennzeichnen. Grundlage dafür sollten Techniken zur Optimierung der Nutzungsfreundlichkeit sein.
- Adam Silver | How to avoid optional form fields with branching questions
- Probleme der Kennzeichnung von Pflichtfeldern mit einem * (Stern) und Vorteile der Kennzeichnung lediglich von optionalen Feldern.
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; }
Useability Ü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.
Links zu Pflichtfeldern
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.
Selten, aber doch lassen sich Eingabefelder finden, in denen persönliche Daten von uns bereits ausgefüllt sind. Dahinter verbirgt sich keine Big Brother Überwachung, sondern vermutlich eine ausgeklügelte Technologie, die sogar in die WCAG 2.1 eingang gefunden hat.
Solche Funktionalitäten können den Eingabevorgang beschleunigen und der Fehlerprävention dienen.
Arten von automatischer Vervollständigung von Eingabefeldern
Ich würde je nach technischer Realisierung der Vorschläge folgende Arten von automatischer Vervollständigung unterscheiden:
- Statistische Auswertung des allgemeinen Verhaltens.
- Eingaben bei der Benützung eines speziellen Eingabeformulars werden statistisch so ausgewertet, dass nach der Eingabe der ersten Buchstaben schon Vorschläge dargestellt werden.
Stellen wir uns jemanden vor, der erstmals Google verwendet und mit der Eingabe eines Suchbegriffs beginnt. - Statistische Auswertung des individuellen Verhaltens.
- Häufig verwendete individuelle Eingaben werden statistisch ausgewertet und bevorzugt vorgeschlagen.
Denken wir an unser Smart Phone, das beim Eintippen die Eigennamen von häufig kontaktierten Personen oder Ausrücken bevorzugt vorschlägt. - Wiederverwendung exakt definierter Inhalte früherer Benutzereingaben.
- Standardisierte personenbezogene Daten des unmittelbaren Benutzers werden vom Browser gespeichert und bei Bedarf für adäquat gekennzeichnete Eingabefelder automatisch wiederverwendet.
Mein Name wird automatisch im Eingabefeld für den Namen vorgeschlagen.
Ich beginne mit den Möglichkeiten zur exakten Beschreibung von Inhalten, weil diese in den WCAG 2.1 in der Konformitätsstufe AA (Sollte sein) erscheinen.
Personenbezogene Eingaben wieder verwendbar machen
Bedeutung der Wiederverwendbarkeit personenbezogener Eingaben
Für das autocomplete
-Attribut wurden vom W3C eine Liste von Werten festgelegt, die personenbezogene Daten des jeweiligen Benutzers bzw. der Benutzerin technisch exakt identifizierbar machen. Wurde in einem entsprechend gekennzeichneten Eingabefeld einmal eine Eingabe vorgenommen, kann der Browser diese speichern und in einem anderen Formular automatisch vorschlagen, wenn das Eingabefeld über denselben Wert für das autocomplete
-Attribut verfügt.
Das Ausfüllen von Formularen mit Angaben zu meiner Person wird auf diese Weise teilautomatisiert. Ob auf diese Weise jedoch Probleme mit der Datensicherheit und dem Datenschutz entstehen könnten, kann ich nicht beurteilen. Jedenfalls werden mit diesem Verfahren selbst Passwörter und Kreditkartennummern erfasst.
Die WCAG 2.1 legen die Verwendung der personenbezogenen Werte jedenfalls nahe. Das neu hinzugekommene Erfolgskriterium 1.3.5 wurde in der WCAG Konformitätsstufe AA eingereiht und ist daher nach europäischen und nationalen Standards umzusetzen.
Technische Zuweisung von Werten für personenbezogene Eingaben
Aus einer wird in einem Eingabefeld das Liste von exakt definierten Wertenautocomplete
-Attribut mit dem entsprechenden Wert versehen. Das kann etwa folgendermaßen aussehen:
<label for="nn">Nachname:</label> <input id="nn" type="text" autocomplete="family-name" ... >
Die Liste der möglichen Attributwerte umfasst 53 Einträge. Ich fasse im Folgenden die wichtigsten zusammen.
Wert | Bedeutung | Beispiel |
---|---|---|
name |
Ganzer Name | Max Mustermann |
honorific-prefix |
Anrede bzw. Titel | Dr.in, Bgm, … |
given-name |
Vorname | Berta |
family-name |
Nachname | Mustermann |
honorific-suffix |
Nachgestellter Titel oder Namenszusatz | MA, SJ, junior, … |
username |
Benutzername | max.mustermann |
current-password |
Passwort des im username gewählten Accounts | ******** |
organization |
Firmenname oder Einrichtung | Amt der Tiroler Landesregierung |
address-level3 |
Straße Hausnummer | Velden 128 |
postal-code |
Postleitzahl | A-6094 |
address-level2 |
Stadt / Ort | Axams |
address-level1 |
Bundesland / Kanton | Tirol |
country-name |
Ländername | Österreich |
cc-number |
Kreditkartennummer | 1234567890 |
bday |
Geburtstag | 29.02.1981 |
url |
Adresse der Homepage | https://www.tirol.gv.at |
tel |
Telefonnummer mit Ländercode | +43(0)512/508-0 |
tel-national |
Telefonnummer ohne Ländercode | 0512/508-0 |
email |
E-Mail Adresse | max.mustermann@tirol.gv.at |
Adressangaben in den Werten
Die Beschreibung der Adresse wird gleich auf drei unterschiedliche Weisen angeboten:
- Als mehrzeilige Adressangabe.
- Mit Angaben zu den einzelnen Zeilen einer Adresse.
- Als fortschreitende Präzisierung vom Land über den Ort bis zur Straße und Hausnummer.
Die Varianten (B) und (C) stehen jedenfalls in Konkurrenz zueinander. Ich persönlich plädiere für die Verwendung der fortschreitenden geografischen Prüzisierung. Diese dürfte der Adressgestaltung im deutschsprachigen Raum am ehesten und am verständlichsten entgegenkommen. Der Code könnte hierzu etwa folgendermaßen aussehen:
<label for="org">Firma / Einrichtung:</label>
<input id="org"
type="text" autocomplete="organization">
<label for="name">Name:</label>
<input id="name" type="text" autocomplete="name">
<label for="street">Straße:</label>
<input id="street" type="text" autocomplete="address-level3">
<label for="plz">Postleitzaqhl:</label>
<input id="plz" type="text" autocomplete="postal-code">
<label for="city">Ort:</label>
<input id="city" type="text" autocomplete="address-level2">
Links zur technischen Verwendung personenbezogener Eingaben
- Erfolgskriterium 1.3.5 Bedeutung des Eingabefelds (Input purpose)
- [WCAG] Understanding Success Criterion 1.3.5: Identify Input Purpose
- [WCAG 2.1] Input Purposes for User Interface Components
- [WebAIM Diskussion] WCAG 2.1 SC 1.3.5 Identify Input Purpose - Testing Methodology
- [WCAG] Using HTML 5.2 autocomplete attributes
Ergänzungsvorschläge während der Eingabe
Bedeutung technischer Ergänzungsvorschläge
Automatische Ergänzungsvorschläge reduzieren im besten Fall Tastatureingaben oder Überlegungen zu Formulierungen, wenn in einem Suchformular nach wenigen Eingaben schon verfügbare oder häufig verwendete Suchausdrücke eingeblendet werden. Am Handy sind derartige Funktionalitäten für Nachrichtenformulare gebräuchlich.
Aus der Perspektive der WCAG stellen sie meines Wissens keine Notwendigkeit dar. Sie sind jedoch aus der Perspektive der Useability äußerst hilfreich.
Voraussetzungen zum Einsatz von Ergänzungsvorschlägen
- 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 Input Types des Eingabefeldes mit einem möglichst präzisen HTML
type
-Attribut vorgegeben werden.
HTML5 Attribut autocomplete
Bedauerlicherweise wurde das autocomplete
-Attribut auch für Funktionalitäten des automatischen Ausfüllens (autofill) herangezogen (). Dies hat auch bei mir erst zu einiger Verwirrung geführt. Personenbezogene Eingaben wieder verwendbar machen
Mit dem HTML Attribut autocomplete
kann nämlich vorerst festgelegt werden, ob eine automatische Ergänzung oder Eingabevorschläge zulässig sind. Die Syntax sieht folgendermaßen aus:
<input autocomplete="on|off">
aria-autocomplete
-Attribut
Mit dem aria-autocomplete
-Attribut kann für den Screen Reader angegeben werden, in welcher Form Ergänzungsvorschläge dargeboten werden.
Wert | Verwendung |
---|---|
inline |
Nach der ersten Eingabe kann im Eingabefeld ein Eingabevorschlag eingeblendet werden. Die vorgeschlagene Ergänzung befindet sich hinter 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. |
Links zu autocomplete
Platzhalter zur Beschreibung von Eingabefeldern (placeholder
-Attribut)
Bedeutung des Platzhalter-Attributs
Eingabefelder in Formularen können mittels placeholder
einen sichtbaren Hinweis für den Eingabezweck erhalten. Der Text des Platzhalters wird im Browser gräulich 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.
Links zu Platzhaltern
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 Useability-Ü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.
Weblinks zu Autofokus
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:
- Datepicker (Formularkomponente zur Auswahl eines Datums)
- Schieberegler (Slider – im englischen auch verwendet für bewegte Seitenbereiche, wie Karusselle)
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.
Links zur Fehlerbehandlung
- Auf Zweiter Blick WCAG Erfolgskriterium 3.3.1 Fehlererkennung (Level A)
- Usable and Accessible Form Validation and Error Recovery (Artikel auf WebAIM.org)
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
Links zum Referenzieren zu Fehlerhinweisen
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 Useability 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: