sprungmarker testet

[extern] Technikwürze – Formulare total 1+ 2

Sascha Postner und Daniel Jagszent formulieren es treffend: Auf jeder Webseite sind sie zu finden – Formulare. Und so ist eine richtige Technikwürze daraus geworden: In der ersten Sendung Formulare total 1 geht es vor allem um Usabililty und Design von Formularen, in der zweiten Sendung Formulare total 2 (Barrierefreie Formulare) haben wir uns die Formulare mal ausführlich aus der barrierefreien Perspektive angesehen.

Sascha Postner sprach mich vor einiger Zeit an, ob wir nicht eine Spezialsendung zu Formularen machen sollten. Daniel Jagszent hat sich spontan dazugesellt. Für mich diesmal – weil bald klar war, dass das Thema für eine Sendung zu umfangreich ist – recht intensive Vorarbeit für zwei Sendungen. Für Sendung 1 zur Usability von Formularen hatten wir uns vor allem auf die drei in den letzten zwei Jahren erschienen Bücher von Luke Wroblewski (Web Form Design), Jarrett und Gaffney (Forms that work) und Featherstone, Connell und Bolton (Fancy Form Design) konzentriert. Für Sendung 2 zur Barrierefreiheit von Formularen habe ich mir einen zugleich festen und offenen Rahmen vorgenommen: Es sollten die klassischen Standards für barrierefreie Formulare abgehandelt werden, aber auch – weil mir das immer wichtig ist, einen Schritt über meinen eigenen Tellerrand zu gehen – Aktuelles und Neues einzuarbeiten wie das WCAG 2, einen Ausblick auf HTML 5 und WAIARIA zu machen. Selbst für mich war das mitunter halb Neuland und halb Glaskugel. Um dem auditiven Medium gerecht zu werden und weil Beispiele ja unterstützen, habe ich einige Screenreader-Beispiele mit JAWS und NVDA erstellt.

Technikwürze Formulare total 1 (Formulardesign)

Jedes der drei Bücher hat seinen eigenen Schwerpunkt, auch wenn sich alle drei unter dem Aspekt Usability fassen lassen. Nach wie vor halte ich das Buch Web Form Design für das stärkste Buch in diesem Bereich, weil es sehr in die Tiefe geht und auf Usability– und Eyetracking-Studien basiert, Luke Wroblewskis Blog Functioning Form bietet ja immer wieder Updates zum Thema und Luke W kann schreiben. 🙂 Was Functioning Form so spannend macht ist die Genauigkeit etwa an die Position eines Label-Elements heranzugehen – ob nun über, links- oder rechtsbündig neben dem Inputfeld, immer unterfüttert mit Eyetracking-Ergebnissen.

Fancy Form Design ist schick gemacht, verliert sich in der zweiten Hälfte ein wenig zu sehr in der Praxis, wie man Formulare mit HTML, CSS und Usability im Blickwinkel umsetzt, hat jedoch eine spannende erste Hälfte und versucht darin, aktuelle Formulare zu klassifizieren. Formulare sind mittlerweile sehr ausdifferenziert, neben den klassischen Elmenten wie Inputfeld, Select oder Checkbox gibt es sogenannte enhanced elements wie:

  • Split Buttons: Für mich lange Zeit ein reines Button-Element, dass ich traditionell schlicht geklickt, aber immer übersehen habe, dass da noch ein kleiner Pfeil auf eine Auswahlmöglichkeit hinweist. Seit mir das bewusst wurde, hab ich dazugelernt, 😉
  • unterschiedliche Formen von Slidern in Formularen,
  • Toggle Switches: Schalter, mit denen Zustände verändert werden können wie an oder aus,
  • aber auch Begleiterscheinungen wie Kalender- und Farbauswahlen oder Drag & Drop-Möglichkeiten.

Fancy Form Design finde ich gerade in diesem Klassifikationsversuch stark, weil man einerseits seinen Blick auf Formulare erweitern kann – das hat nur noch wenig mit unseren klassischen Kontaktformularen zu tun – und andererseits man besser über Formulare sprechen kann, wenn man sich eines gemeinsamen Vokabulars bedient – ansonsten kann es zum Thema schnell sehr allgemein werden. Bei weitem habe ich das Vokabular in Sachen Formularen nicht komplett durchdrungen – dazu war die Vorbereitungszeit auch zu knapp, aber es war mal ein Anfang. 🙂

Forms that work ist für meine Lesebegriffe ein wenig zu allgemein unterwegs. Andererseits fand ich Themen wie Grids für Formulare und ein Konzept wie Personas sehr spannend, leider wurde es nur kurz angerissen. Insofern ist das Buch ein Einsteigerbuch in unterschiedlichste Usabillity-Aspekte, die das Vorfeld von Formularen betreffen, also bevor man mit HTML und CSS rangeht. Das Personas-Konzept formt den Nutzer vor als eine Art Archetyp, damit man sich unterschiedliche Nutzergruppen besser vorstellen kann beim Entwickeln eines Formulars. Spannendes Konzept, werde ich mir genauer ansehen.

Wie man vielleicht aus meinen Anmerkungen erkennen kann, eine sehr diverse Sendung, weil eben sehr umfangreich vom Thema, aber ein erster guter Einstieg.

Und jetzt weiter zur Technikwürze Formulare total 1 (Formulardesign)

Technikwürze Formulare total 2 (Barrierefreie Formulare)

Für eine Technikwürze versuche ich mich konzeptionell sehr streng vorzubereiten, weil man sich sonst sehr schnell inhaltlich verlieren kann. Daher habe ich einen relativ strengen Aufbau für die Sendung zu barrierefreien Formularen gewählt und Aufbau ist so streng gemeint, dass die Sendung auch inhaltlich aufeinander aufbaut: Zuerst sehen wir uns die klassischen barrierefreien Formulare an, wie wir sie täglich erstellen mit ihrem starken Konnex zu Webstandards. Anhand des Newsletter-Formulars des diesjährigen BIENE-Gold-Gewinners Manufactum gehen wir diese klassischen Elemente und Strukturen durch und hören uns das Formular im Screenreader JAWS an.

Von diesem klassischen Formular gehen wir aus und vergleichen es mit den aktuellen Vorgaben hinsichtlich Formularen im WCAG 2, machen dann einen Ausblick, was sich in HTML 5 mit Blick auf das klassische Formular verändern wird und schließlich bauen wir das klassische Formular mit WAI-ARIA Elementen und Attributen aus, was ja jederzeit und sofort von uns allen integriert werden kann und soll. Also ein fast klassischer Auf- und Ausbau, aber mir war wichtig, dass es eben praxisnah barrierefrei wird und möglichst jeder an seine Formulare nach der Sendung geht und zumindest das WAI-ARIA Attribut aria-required einbaut. 🙂

Klassische barrierefreie Formulare

Setzt man Webstandards ein, ist man in der barrierefreien Optimierung von Formularen schon sehr gut am Punkt: Der korrekte Einsatz von label mit for/id-Verknüpfung, fieldset und legend für abgrenzbare, inhaltliche Bereiche eines Formulars, die korrekte barrierefreie Optimierung von Buttons etwa für type="image", das Formular für die Tastaturnutzung mit Hilfe eines erkennbaren und nutzbaren Fokus optimieren und die sinnvolle und nachvollziehbare Fehlerkennzeichnung und -behandlung in Formularen sind schon ne ganze Menge und bereiten ein barrierefreies Formular so auf, dass unter anderem ein Screenreader-Nutzer damit gut arbeiten kann. Freilich hört man sich Einsatz und Ausgabe von WAI-ARIA in einem Formular mit einem Screenreader an, erkennt man schnell, wo die Optimierung mit WAI-ARIA ansetzt – das hört sich einfach besser an. Genau so soll es sein – ich wünschte mir das durchaus auch für alle Nutzer – das Arbeiten mit einem Formular soll ja auch Spaß machen. 🙂

Schon etwas älter ist die Artikelserie von Einfach für Alle Reine Formsache, aber es hat sich, was das klassische barrierefreie Formular betrifft, nicht sonderlich viel geändert. Interessanterweise wurden schon damals – 2007 – die strittigen Punkte für barrierefreie Formulare klar benannt, Punkte, die historisch gewachsen heute auch tatsächlich kaum mehr – aus den unterschiedlichsten Gründen – in Verwendung sind wie der Einsatz eines Tabindex oder von Accesskeys, der Vorbelegung von und der Einsatz des title-Attributs in Formularfeldern.

WCAG 2 und Formulare

Aus dem WCAG 2 habe ich mir nur einige interessante Themen rausgesucht, vor allem die Behandlung von Fehlern in Formularen ist spannend. Ganz klar ist, dass der Einsatz von label (for/id), fieldset bereits auf der ersten Stufe – Level A – zwingend ist. Wie auch sonst, schließlich ist das ja die Basis eines barrierefreien Formulars. Viele spannender finde ich den Versuch des WCAG 2, auf die aktuelle Praxis einzuschwenken:

  • So werden Standards erkannt wie ein gängiges Suchfeld auf Webseiten und es ist erlaubt, dafür kein Label zu setzen. Das kommt immer auf das konkrete Layout an, aber wie oft haben wir nur ein Suchfeld und einen Button vorliegen? Hier ist es dann hinreichend, im Suchfeld das title-Attribut zu nutzen. Das WCAG 2 ist jedoch kein Freibrief für Moden. 😉
  • Besonderes Augenmerk wird im WCAG2 auf die Fehlerbehandlung gelegt, so wird sogar auf die clientseitige Validierung Wert gelegt, weil sie den Nutzer sofort auf einen Fehler aufmerksam macht. Natürlich soll es als Fallback immer noch die serverseitige Validierung geben. Auch stark durch die Praxis beeinflusst ist der Wunsch, dass es eine direkte Fehlerfokussierung geben soll und eine Möglichkeit zwischen den Fehlern zu navigieren – wie man das auch immer in der Praxis dann umsetzt.
  • Das WCAG 2 unterscheidet die Fehlerbehandlung in drei Stufen: Auf Level A (Fehlererkennung) muss ein Fehler zumindest erkennbar sein mit Hilfe von Semantik, Text und / oder Farbe. Auf Level AA (Fehlererläuterung) sollen die Fehler nicht nur erkennbar, sondern auch mit Beispielen und Hilfen etwa nahe am Formularfeld erläutert werden. Auf Level AAA (Fehlerprävention) liegen dann erst jene Schritte und Bestätigungen, die für uns bei ausführlicheren Formularprozessen ohnehin längst gängige Praxis sind. Formulare, die in Schritten durchlaufen werden, müssen auch in Schritten erkennbar und benutzbar sein und Bestätigungsseiten anbieten, die dem Nutzer entweder noch einmal eine Möglichkeit geben, die Inhalte zu bestätigen, oder schlicht die Ergebnisse des Formulars noch einmal klar anzeigen. Folgerichtig wird hierbei der Level bei finanziellen und rechtlichen Transaktionen dann auf AA gehoben.

HTML 5 Formulare

HTML 5 bringt für Formulare viel neues, wenn es denn dann auch vom Browser interpretiert wird. Aber ich sag es mal so, das wird schon noch alles. 🙂 Interessant fand ich, wie unterschiedlich die Interpretation von Attributen und Elementen ist – also was geht schon in Safari und Opera. Wichtig ist, dass es schlicht endlich neue Typen gibt für Email, Datum oder Suchfeld. Schließlich hat in HTML 5 auch die Praxis endlich rückgewirkt, denn ein Email-Feld unterscheidet sich schlicht von einem herkömmlichen Formularfeld. Neue Attribute wie required, autofocus und placeholder (Vorbelegung eines Formularfeldes) werden sicherlich bald flächendeckend eingesetzt werden – vor allem required für ein pflichtiges Feld.

Bruce Lawson hat in seinem Artikel The accessibility of HTML 5 autofocus bereits mit dem Attribut autofocus zu kämpfen. Mit diesem Attribut setzt man nach dem Laden der Seite den Fokus direkt auf das Feld. Mag das bei Formularen direkt am Anfang der Seite oder speziellen Formularbereichen wie etwa einer Fahrplanauskunft durchaus sinnvoll sein, kann das bei Seiten, die einen erklärenden Text vor dem Formular haben, zum Problem werden. Beim Fokus auf ein Formularfeld geht etwa ein Screenreader in den Formularmodus und der vorherige Inhalt wird dann nicht vorgelesen, enthält womöglich aber wichtige Vorinformation.

Ein Manko derzeit ist, dass assistive Technologien wie Screenreader die neuen Attribute wie ein required noch nicht auslesen. Irgendwo hab ich gelesen, die präferieren derzeit einfach den Einsatz und die Ausgabe von WAI-ARIA. Klingt zwingend. Aber – warum sollte man nicht ein Attribut wie required schlicht so ausgeben wie eben sein WAI-ARIA-Pendant? Vor allem weil so ein Attribut wie required dann eben in einem Standard ohnehin implementiert ist und man sich mit WAI-ARIA dann an zusätzlichen Ausgaben und Features erfreuen kann?

WAI-ARIA und Formulare

WAI-Aria hat mich wirklich überrascht, wie Screenreader – etwa JAWS und NVDA – da wirklich eine Serviceleistung in Formularen anbieten. Man muss einfach sagen, so macht es Spaß, mit einem Formular zu arbeiten. Wie schon gesagt, ich würde mir das durchaus für alle Nutzer wünschen, grade Formulare sind ja nicht so mit einem Spaßfaktor belegt. 😉 Vor allem die Kombination von Attributen kann dann wirklich einen Wow-Effekt erzeugen. 🙂 Aber, da stimme ich Alexander Farkas, der derzeit in der Reihe WAI-ARIA – Epic Fail aufzeigt, was kann man alles mit WAI-ARIA machen, aber was kann dann auch zuviel oder gar kontraproduktiv sein, zu, wir müssen uns der Servicequalität von WAI-ARIA immer bewusst sein und testen, testen und testen. 🙂 Vor allem in Kombination mit HTML 5 wird WAI-ARIA dann durchaus noch zu einer Herausforderung an die Standarisierung. WAI-ARIA und HTML 5 haben mitunter gleiche Attribute erarbeitet wie aria-required (WAI-ARIA) und required (HTML 5) für pflichtige Felder, aber WAI-ARIA hat auch wichtige Attribute erarbeitet, die zusätzlichen Hilfestellungen und Informationen anbieten und uns in der Praxis auch Arbeit abnehmen können wie die Attribute aria-describedby oder aria-labelledby.

So lässt sich ein beliebiges Element oder Inhalt als Label eindeutig zu einem Formularfeld zuordnen mit aria-labelledby. Das soll nicht heissen, dass wir jetzt auf ein Label und die eindeutige Verdrahtung mit for/id verzichten. Es meint nur, dass man in komplexen Formularstrukturen schlicht noch eine weitere Möglichkeit hat, die Semantik zu verdrahten und die Ausgabe etwa an einen Screenreader noch anzureichern. Hier gilt also auch wieder, sich das Ergebnis genau anzusehen und durchzutesten.

Das Attribut aria-describedby liest den Inhalt eines anderen Elements ein im Formularfeld. Das können zusätzliche Informationen oder Hilfestellungen sein. Verdrahtet wird das durch eine eindeutige id im Element. Vor allem für Tooltip-Strukturen und Fehlermeldungen interessant. Ein weiteres interessantes Attribut aria-label kann als Alternative in Standards wie Suchfeldern verwendet werden, wenn man auf ein Label verzichtet. Als Einstieg für das Anreichern bestehender Auftritte mit WAI-ARIA empfehle ich die Easy ARIA Tips von Marco Zehe. Die lassen sich immer recht flott und einfach integrieren.

Und jetzt weiter zur Technikwürze Formulare total 2 (Barrierefreie Formulare)

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert