Über barrierefreie Formulare ist soweit alles gesagt worden, so z.B. von Tomas Caspers: Barrierefreie Formulare (2011) oder Roger Hudson: Accessible Forms using WCAG 2.0  (2008). Über barrierefreie Formularvalidierung mit HTML 5 und WAI-ARIA gibt es interessante Artikel mit Beispielen von Paul J. Adam: Accessible Client Side Form Validation (2012) oder Ian Oxley: HTML5 Form Validation (2013). Für Detailfragen sind die Techniken für WCAG 2.0 des W3C ein guter Anhaltspunkt.

Infos zu HTML5 und WAI-ARIA in aller Ausführlichkeit liefert ebenso der W3C – www.w3.org/TR/wai-aria-practices, www.w3.org/TR/aria-in-html. Die Techniques for WCAG 2.0 sind 2014 um einige ARIA Techniken ergänzt worden.

Joshue O Connor: Pro HTML5 Accessibility, Apress 2012 ist ein empfehlenswertes Fachbuch zum Thema.

Eine sehr ansprechende Präsentation von HTML5 Formularfeatures findet sich bei Dive into HTML5 (laufend aktualisiert), basierend auf dem Buch von Mark Pilgrim, HTML5: Up & Running (2010).
Das HTML 5 Handbuch von Stefan Münz und Clemens Gull (2013) ist auch online verfügbar und gibt umfassende Information zu Formularen auf deutsch, allerdings wie Dive into HTML 5 ohne Accessibility Fokus [ergänzt 3.6.2014].

Hier finden Sie nun einige Anmerkungen zum grundsätzlichen Verständnis barrierefreier Formulargestaltung und zum Stand der Dinge bezüglich HTML5 und WAI-ARIA. Genaueres lesen Sie in den obengenannten Fachartikeln. Diese Liste soll als Gedächtnisauffrischung dienen, um sich zu vergewissern, dass man bei der Erstellung der barrierefreien HTML Formulare nichts übersehen hat.

Diese Liste wird aktualisiert, wenn es sich ergibt, zuletzt: 3.6. 2014.

Generelle Anmerkungen

WebnutzerInnen mit Sinnesbehinderungen bedienen Formulare unter erschwerten Bedingungen. Sie haben nicht das gesamte Formular vor sich, z.B. bei linearem Lesen mit einem Screenreader oder bei Verwendung von Zoomsoftware, die nur einen Bildschirmausschnitt zeigt. Sie übersehen möglicherweise wichtige Information und vertippen sich leichter.

1. Usabilitykriterien wie Steuerbarkeit, Kontrollmöglichkeit, Erwartungskonformität, Ausfüllhilfen, gutes Anwenderfeedback und generelle Fehlertoleranz sind besonders wichtig.
2. Information über vorgegebene Datenformate ist nötig (z.B. bei Datumseingabe DDMMJJJJ). Das HTML5 pattern Attribut (Beispiele unter html5pattern.com) unterstützt bei der Validierung, Information in Textform muss trotzdem gegeben werden.
3. Kontrolle vor dem Absenden muss möglich sein. Bei sensiblen Daten ist eine Zusammenfassung der zu sendenden Daten vor dem Submit für alle BenutzerInnen selbstverständlich. Die Kontrollmöglichkeit für jede Art von Formulardaten ist ein WCAG 2.0 Triple-A Kriterium.
4. Professionelles Fehlerhandling bereits clientseitig zu machen unterstützt die Accessibility, weil die Seite nicht neu geladen werden muss.
5. Fehlermeldungen müssen aber zugänglich gestaltet werden, d.h. so, dass sie auch wahrgenommen werden, wenn sie sich nicht im gerade sichtbaren vergrößerten Bildschirmausschnitt oder in der Lesereihenfolge beim momentanen Fokuspunkt befindet. WAI-ARIA Markup (bevorzugt) oder Veränderung des Fokus ist also nötig.
6. WCAG Konformität hängt nicht davon ab, ob Formulare ohne JavaScript funktionstüchtig sind. JavaScript muss so verwendet werden, dass es die Accessibility unterstützt.
7. Durch JavaScript eingefügte Informationen sollten aber generell auch bei deaktiviertem JavaScript zur Verfügung stehen. Formulare sollten sich bei deaktiviertem JavaScript absenden lassen. Formularvalidierung sollte auch serverseitig erfolgen. Dies sind generelle Webstandardkriterien, keine Accessibilityvorgaben.
8. Interessante clientseitige Formular Validierungslösungen mit jQuery und Accessibilityanspruch gibt es z.B. von Jörn Zaefferer: jqueryvalidation.org, Felix Nagel: jQuery Accessible RIA (aktualisiert 2013), oder von Peter Minarik: WIENFLUSS Form Framework (2011).
9. NutzerInnen von Assistiven Technologien am Desktop verwenden häufig noch ältere Browser (derzeit noch IE8 und IE9) und nicht nur ältere Hilfsprogramme. Rückwärtskompatibilität ist also nötig.

Optimierung für User mit Seheinschränkungen

Seheinschränkung ist ein vager Begriff, der unterschiedliche Stufen von unscharfem, verschwommenem Sehen durch hohe Dioptrinzahl und diverse Augenkrankheiten ebenso umfasst wie Blendempfindlichkeit oder Farbfehlsichtigkeiten bis zu Farbblindheit.

1. Größere Schrift, großzügigere Gestaltung und höhere Kontrastwerte machen Formulare natürlich besser lesbar. Schrift und Eingabefelder sollten ausreichend groß und vergrößerbar sein, zumindestens im Zoommodus von Browsern.
2. Ausreichende Kontraste sind nicht nur für Text, sondern auch für Formularfelder nötig. Auch Borders von Eingabefeldern sollten ein Kontrastverhältnis (Luminosity Contrast Ratio) von 4.5:1 erreichen (bzw. 3:1, wenn sie sehr groß sind).
3. Farbänderungen bei fokussierten Eingabefeldern und Buttons helfen bei der Orientierung.
4. Farbe darf nicht das einzige Markierungsmerkmal für Fehlermeldungen sein, sie sollten fett gedruckt, eingerahmt oder mit einem Icon versehen werden, um sich vom normalen Label- und Fließtext zu unterscheiden. Fehlerhafte Felder sollen deutlich markiert werden, mit farbiger Unterlegung und farbigem Rahmen oder einem Icon.
5. Labels sollten sich nahe dem zugehörigen Formularfeld befinden, z.B. darüber oder rechtsbündig davor, um auch bei Bildschirmvergrößerung, wenn nur ein Ausschnitt des Bildschirms gesehen wird, eine klare Zuordnung zu gewährleisten.
6. Semantisch zugeordnete Labels liefern eine große Klickfläche. Das zugeordnete Formularfeld erhält bei Klick auf das Label den Fokus.
7. Ein Transition / Fading Effekt bei Statusmeldungen lenkt den Blick dorthin. Bei Verwendung von Screenvergrößerungsprogrammen wird die Statusmeldung, die sich außerhalb des gerade sichtbaren Bildschirmausschnitts befindet, allerdings nur wahrgenommen, wenn der Fokus dorthin gelegt wird, bzw. wenn die Sprachausgabe eine alert Meldung vorliest. Eine Sprachausgabe von Zoomprogrammen liefert in etwa den gleichen Output wie die Sprachausgabe eines Screenreaders und gibt damit die gleichen Accessibilitykriterien vor.
8. Das Formularstyling sollte in ein CSS File ausgelagert werden, das gegebenenfalls weggeschalten oder durch ein eigenes User Stylesheet überschrieben werden kann. Auch JavaScript sollte Styling nicht direkt beeinflussen, sondern nur CSS classes ändern oder einfügen.
9. Layouttabellen zur Positionierung von Formularelementen sind nicht verboten, aber nicht state of the art. Sie bedeuten eine Einschränkung bei der individuellen Anpassbarkeit und auch für die Ausgabe in mobilen Geräten.

Screenreader Optimierung

ScreenreadernutzerInnen sind eine sehr kleine Zielgruppe, die bei Accessibilityfragen immer sehr im Vordergrund zu stehen scheint. Das mag  daran liegen, dass es auch für die technikaffine Webgemeinde faszinierend ist, dass man Computer und das Internet blind verstehen und bedienen kann. Es liegt auch daran, dass es um viele programmiertechnische Detailfragen geht, wo sich professionelle von weniger professioneller Programmierung unterscheidet.

1. Accessibilityvorgaben für blinde NutzerInnen betreffen vor allem die korrekte semantische Struktur von Formularen und zugängliches Anwenderfeedback (Fehlerhandling, Statusmeldungen).
2. Screenreader haben einen Lesemodus, in dem mit Pfeiltasten, TAB Taste und Shortcuts durch eine Webseite navigiert werden kann, und einen Formularmodus, in dem nur fokussierbare Elemente (mit der TAB Taste) erreichbar sind und Formulare bedient und ausgefüllt werden können. Z.B. kann man im Lesemodus mit der Taste H zur nächsten Überschrift, mit F zum nächsten Formularfeld, mit Pfeil hinunter in die nächste Zeile springen. Im Formularmodus geht das nicht, hier kann man sich nur von Formularfeld zu Formularfeld bewegen, die Taste H schreibt hier ein H ins fokussierte Inputfeld.
3. Moderne Screenreader schalten automatisch in den Formularmodus, wenn sie ein Formularfeld erreichen und wieder in den Lesemodus, wenn sie ein Formular verlassen.
4. Mit Shortcuts kann man zwischen Formular- und Lesemodus umschalten, z.B. im NVDA mit NVDA-Taste (Einfügen oder Dauergroßschreibtaste) + Leertaste bzw. ESCAPE zum Verlassen des Formularmodus.
5. Im Formularmodus werden nur Formularelemente, Links und den Formularfeldern semantisch zugeordnete Texte automatisch gelesen, d.h. nur korrekt ausgezeichnete Labels, ev. title Attribute und Legends innerhalb von Fieldsets.
6. Fieldsets strukturieren komplexe Formulare. Ihre Legends werden bei jedem Formularfeld innerhalb des Fieldsets wieder vorgelesen. Das kann gut oder auch störend und kontraproduktiv sein. Legends sollen auf jeden Fall kurz gehalten sein. Überschriften sind ein von manchen ScreenreadernutzerInnen bevorzugter Ersatz zur Strukturierung komplexer Formulare.
7. Überschriften oder Erklärungstexte innerhalb von Formularen werden im Formularmodus aber nicht vorgelesen, man muss in den Lesemodus wechseln, um sie zu erreichen. Es kann deshalb passieren, dass diese Inhalte von ScreenreadernutzerInnen „übersehen“ werden. Man kann sie mit dem aria-describedby Attribut semantisch zuordnen, damit sie auch im Formularmodus vorgelesen werden.
8. Gruppen von Radiobuttons oder Checkboxen benötigen, wenn der übergeordnete Text zum Verständnis wichtig ist, unbedingt eine übergeordnete Legend oder ein aria-labelledby Attribut bei jedem einzelnen Element, zusätzlich zu den einzelnen Labels.
9. Labels benötigen ein FOR Attribut mit dem ID-Inhalt des zugehörigen Formularfelds. Das Formularfeld benötigt eine ID.
10. Wenn das Label das Formularfeld miteinschließt, ist eine explizite for/id Zuordnung nicht mehr notwendig für aktuelle Screenreader. Die sicherste Methode für alle Browser / Screenreader Kombinationen ist aber ein explizites Label mit for, das das Formularfeld nicht miteinschließt. Eine Testreihe zu Labels, Legends und dem arialabelledby Attribut hat Steve Faulkner durchgeführt: Testing form control labelling support in popular browsers and screen readers, Erläuterungen finden sich im Blogbeitrag dazu.
11. Wenn Labels optisch stören, kann man sie verstecken (aus dem Viewport schieben oder mit clip beschneiden) oder ersatzweise nur ein title-Attribut beim Inputfeld anführen. Man kann statt einem HTML Label auch das Attribut aria-labelledby verwenden. Damit können z.B. in einer Tabelle mit Formularelementen mehrere Tableheader-Zellen semantisch klar zugeordnet werden.
12. Hintergrundbilder eignen sich nicht als Labelinhalt bzw. wird zusätzlich eine (gegebenenfalls optisch versteckte) Textinformation benötigt.
13. Links (z.B. zu Hilfetexten) sollten außerhalb des Labels positioniert werden, wenn sie nicht direkter Bestandteil des Labeltextes sind. Sie dürfen die Klickbarkeit des Labels nicht stören. Man kann sie mit aria-describedby zuordnen.
14. Das HTML5 placeholder Attribut ist nicht als Labelersatz gedacht.
15. Ein Asterics * zur Markierung von Pflichtfeldern wird nicht von jedem Screenreader zuverlässig vorgelesen. Sonderzeichen und typographische Zeichen werden von Screenreadern unterschiedlich gehandhabt. Möglicherweise ist der * also nur mit Braillezeile lesbar und wird von der Sprachausgabe ignoriert.
16. Pflichtfelder können durch das Attribut aria-required gekennzeichnet werden. Das aria-required Attribut liefert per se keine optische Fehleranzeige wie das HTML5 Attribut required und keine Validierung, sondern informiert nur Screenreader NutzerInnen, dass das Feld erforderlich ist. Es wird auch von älteren Screenreadern interpretiert.
17. Weitere HTML5 und ARIA Attribute zur Formularauszeichnung und Fehlervalidierung finden Sie in den W3C Dokumenten aufgelistet: z.B. Using WAI-ARIA in HTML.
18. Die Unterstützung von HTML5 Formularattributen und Eingabetypen ist noch nicht durchgängig gegeben: caniuse.com/#feat=forms, www.html5accessibility.com.
    Fallbacklösungen für IE8 und IE9 sind derzeit in jedem Fall noch nötig.
19. JavaScript muss zugänglich programmiert sein, d.h. in erster Linie auch tastaturbedienbar. Beispiele von WCAG 2.0 konformem JavaScript finden sich bei den Techniken für WCAG 2.0 des W3C.
20. Autosuggest /Autocomplete Listen müssen fokussierbar / tastaturbedienbar sein. Auch hier gibt es ARIA Auszeichnungsmöglichkeiten, um sie verständlich zu machen. Der Fokus muss jeweils am Anfang der eingeblendeten Autosuggestbegriffe stehen, damit ein Screenreader sie dem Lesefluss folgend lesen kann.
21. Formularinfos (z.B. Hilfetexte), die in Lightboxen präsentiert werden, müssen ebenfalls tastaturbedienbar sein. Der Fokus muss in die Lightbox gesetzt werden, idealerweise zum Schließenbutton, der sich am Anfang befinden sollte und damit auch das erste fokussierbare Element ist.
22. Statusänderungen im Formular sollen nur durch Nutzeraktion erfolgen.
23. Automatisches Form-Submit (z.B. mit onChange oder onFocus) soll man vermeiden. Formulare sollten einen Submit Button haben.
24. Fehlermeldungen können gesammelt am Anfang des Formulars stehen, verlinkt zum jeweiligen fehlerhaften Feld. Dieses kann mit dem aria-invalid Attribut für Screenreader als fehlerhaft markiert werden.
25. Fehlermeldungen, die direkt beim fehlerhaften Inputfeld platziert werden, sollten Teil des Labels oder mit ARIA Markup semantisch zugeordnet sein. Das HTML5 autofocus Attribut könnte verwendet werden, um den Fokus zum fehlerhaften Feld zu setzen.
26. Statusmeldungen, die nicht direkt im Lesefluss folgen, sollten die WAI-ARIA role alert erhalten. Der Fokus muss dann nicht dort hingesetzt werden, um Screenreader Nutzern die Information zugänglich zu machen. Die spätere Einfügung von alert Meldungen in den DOM wird noch nicht durchgängig und von Browsern unterschiedlich unterstützt, Informationen dazu von Steve Faulkner im Blog der Paciellogroup.
27. Die Lesereihenfolge sollte möglichst nicht verändert werden (durch unnötige Setzung von tabindex), Fokusänderungen durch JavaScript müssen mit Vorsicht eingesetzt und genau getestet werden.
28. Nach dem Submit Button darf keine wichtige Information mehr folgen. Das HTML5 form Attribut würde die Platzierung von Formularelementen sogar außerhalb eines Formulars ermöglichen, wird aber vom Internet Explorer nicht unterstützt.

Tastaturbedienbarkeit von Formularen

1. Native Formularelemente sind tastaturbedienbar.
2. JavaScript Eventhandler müssen tastaturbedienbar sein, vgl. den Artikel zu JavaScript Eventhandlers bei WebAIM.
3. Der onChange Eventhandler in Selectboxen kann in Internet Explorer und Chrome zu Problemen führen, da eine Auswahl (z.b. ein Seitenwechsel) getriggert wird, bevor alle Auswahlmöglichkeiten durchgesehen werden können. Vgl. den diesbezüglichen Blogartikel zu Problemen mit onChange von Paul Adam.