Grobkonzept: Usability und Barrierefreiheit im Kontext von Web-Formularen

/in , ,

Formulare sind ein Instrument der Mensch-Maschine-Interaktion, das heißt eine Schnittstelle zwischen einem Nutzer, der das Formular ausfüllt, und einer Software, die die Angaben entgegennimmt und auswertet oder verarbeitet. Damit stellen Formulare besondere Anforderungen an Usability und Barrierefreiheit. Dieser Artikel skizziert ein Grobkonzept für ein zweiseitiges Formular zur Registrierung von neuen Kunden bei einer Versicherung. Er basiert auf einem Fachkonzept, das ich für die itemis AG verfasst habe. Besonderes Augenmerk wird hierbei gelegt auf

  • eine optimale Aufteilung der Interaktionsschritte und Abfragen gemäß gängiger Konventionen, um die Selbstbeschreibungsfähigkeit und Erwartungskonformität der Anwendungen sicherzustellen;
  • den Aufbau einer technisch hochwertigen und zeitgemäßen HTML-Auszeichnung gemäß den Anforderungen der BITV 2.0 sowie den Vorgaben der aktuellen HTML5-Empfehlung des W3C;
  • den Einsatz assistiver Konzepte wie WAI-ARIA, um die Zugänglichkeit der Anwendungen zu verbessern, oder clientseitiger Validierungen, um die Selbstbeschreibungsfähigkeit, Lernförderlichkeit und Fehlertoleranz zu erhöhen;
  • den Aufbau einheitlicher Komponenten, um die Formulare einheitlich verwenden und besser warten zu können.

Usability und Barrierefreiheit

Für die Entwicklung von Formularen mit hoher Usability sind – neben den allgemein gültigen Anforderungen und Empfehlungen der DIN EN ISO 9241 – vor allem die Teile 110 und 143 von Belang.

  • DIN EN ISO 921, Teil 110: »Grundsätze der Dialoggestaltung«, beschreibt Grundsätze für die Gestaltung und Bewertung einer Schnittstelle zwischen Benutzer und System.
  • DIN EN ISO 9241, Teil 143: »Formulardialoge«, enthält Anforderungen an und Empfehlungen für die Gestaltung und Bewertung von Formulardialogen. Dabei geht es um Benutzer, die ein Formular bzw. eine Dialogbox mit beschrifteten Felder ausfüllen oder Eingabewerte für diese auswählen und deren Inhalte ändern.

Die Empfehlungen sind auf den gesamten Entwicklungsprozess anwendbar, zum Beispiel als Leitfaden für die Entwickler bei der Gestaltung, als Grundlage für die heuristische Bewertung sowie als Anleitung für die Prüfung der Usability.

Barrierefreiheit besitzt gerade im Kontext von Formularen eine besondere Bedeutung, denn viele Probleme, auf die Nutzer beim Umgang mit Formularen stoßen, sind für behinderte Nutzer unüberwindbare Hürden. Die »Barrierefreie-Informationstechnik-Verordnung – BITV 2.0« soll bewirken, dass die betreffenden Angebote der Informationstechnik behinderten Menschen im Sinne von § 3 BGG, denen ohne die Erfüllung zusätzlicher Bedingungen die Nutzung der Informationstechnik nur eingeschränkt möglich ist, den Zugang zu dieser zu eröffnen oder zu erleichtern.

Im Folgenden werden beispielhaft Vorgaben aus den Usability-Normen sowie der BITV 2.0 aufgegriffen und angewendet.

Strukturierung des Formulars

Durch das Formular sollen diverse Daten abgefragt werden. Diese Abfragen sind sinnvoll aufzuteilen und zu ergänzen sowie in eine natürliche, erwartungskonforme Reihenfolge zu bringen. Die Struktur ist in einem Feinkonzept zu erarbeiten, unterstützt durch Marktbeobachtungen oder Benutzerbeteiligung.

Die folgende Struktur basiert auf der Analyse vergleichbarer Formulare. Die Auswahl der geeigneten Steuerelemente für die jeweiligen Felder erfolgte nach der Maßgabe, den Nutzer möglichst wenig einzuschränken, ihn aber gleichzeitig weitmöglich zu unterstützen, etwa über Datumsauswahlassistenten. Wo möglich und sinnvoll, wurde auf einfache Textfelder gesetzt anstatt auf vorstrukturierte Erfassungsmasken, zum Beispiel bei der Telefonnummer, die keine Unterteilung in Ländervorwahl, Ortsvorwahl und Rufnummer vorsieht.

  • Erste Seite: Angaben zum Versicherungsnehmer
    • Abschnitt: Persönliche Angaben
      • Pflichtangabe: Anrede (Radiobuttons)
      • Titel (Textfeld)
      • Pflichtangabe: Vorname (Textfeld)
      • Pflichtangabe: Nachname (Textfeld)
      • Pflichtangabe: Geburtsdatum (Datumsfeld/Textfeld)
      • Sozialversicherungsnummer (Textfeld)
      • Steuer-Identifikationsnummer (Textfeld)
    • Abschnitt: Kontaktdaten
      • Pflichtangabe: Anschrift (Text- und Nummernfelder)
      • Telefon (Textfeld)
      • E-Mail (E-Mail-Feld)
    • Abschnitt: Aktueller Arbeitgeber
      • Pflichtangabe: Name des Arbeitgebers (Textfeld)
      • Pflichtangabe: Anschrift des Arbeitgebers (Textfeld)
      • Pflichtangabe: Monatliches Bruttoeinkommen (Textfeld)
  • Zweite Seite: Gewünschter Versicherungsschutz
    • Pflichtangabe: Versicherungsbeginn (Datumsfeld/Textfeld)
    • Abschnitt: Bestehendes Versicherungsverhältnis
      • Name der Versicherung (Textfeld)
      • Versicherungsnummer (Textfeld)
    • Abschnitt: Familiäre Angaben
      • Pflichtangabe: Familienversicherung (Checkbox)
      • Pflichtangabe: Kinder (Checkbox)
  • Dritte Seite: Angaben prüfen und Formular absenden

Auf der zweiten Seite kann bereits auf Eingaben auf der ersten Seite zurückgegriffen werden, etwa bei der Auswahl der angebotenen Zusatzversicherungen.

Die Gruppierung thematisch zusammengehöriger Formularinhalte erfolgt über das Element fieldset. Über das Element legend wird der Gruppe eine Legende verliehen, die die Funktion einer Überschrift erfüllt. Auf eine eindeutige Verschachtelung der Fieldsets ist Rücksicht zu nehmen; die Legende ist so kurz wie möglich zu halten. Die Struktur im folgenden Beispiel nimmt auf Beides Rücksicht.

Der Forderung nach einem zwei- bzw. mehrseitigen Formular kann auf verschiedene Weise nachgekommen werden. Im oberen Beispiel über das Attribut aria-expanded angedeutet, nicht ausimplementiert, ist eine clientseitige Auf- und Zuklapplösung, bei der das Formular auf einer Seite verbleibt, aber jeweils nur die für den aktuellen Bearbeitungsschritt relevanten Abschnitte sichtbar (aufgeklappt) sind. Bei der Navigation von einer Seite zur anderen müssen die bereits getätigten Eingaben gespeichert werden gemäß ISO-9241-110:

»Das interaktive System sollte verhindern, dass irgendeine Benutzerhandlung zu undefinierten Systemzuständen oder Systemabbrüchen führen kann.«

 Kennzeichnung von Pflichtfeldern

Im Sinne der Selbstbeschreibungsfähigkeit und Fehlertoleranz sind Pflichtfelder als solche erkennbar zu machen. Häufig werden Pflichtfelder mit einem Asterisk (*) gekennzeichnet, der jedoch in vielen Screenreadern – je nach Einstellung – als Interpunktionszeichen behandelt und daher nicht vorgelesen wird. Das folgende Beispiel zeigt einen anderen Ansatz.

  • Labels von Pflichtfeldern werden mit dem Hinweis »Erforderliche Angabe« eingeleitet, der per CSS versteckt und damit visuell ausgeblendet wird; vorgelesen wird er dennoch.
  • Der Asterisk steht Labels von Pflichtfeldern zur visuellen Markierung nach.
  • Die WAI-ARIA- bzw. HTML-Attribute aria-required="true" und required kennzeichnen das Feld semantisch als Pflichtfeld.

Fehlerbehandlung

HTML5 bringt Mechanismen für die Validierung ohne Neuladen der Seite direkt im Browser mit, darunter Prüfungen

  • ob Pflichtfelder (Attribut required) befüllt wurden;
  • ob E-Mail-Felder tatsächlich eine E-Mail enthalten (je nach Browser im Wesentlichen, ob das @ vorhanden ist);
  • ob Nummerfelder tatsächlich nur Nummern enthalten.

Diese Validierungen funktionieren allerdings nicht browserübergreifend, sind nicht konsistent implementiert und oftmals unzureichend. Eine selbst implementierte Validierung ist zu empfehlen. Dabei ist im Feinkonzept zu klären, ob die Validierung direkt (z.B. in JavaScript) erfolgen oder ein Server-Zugriff stattfinden soll und wo die genaue Abgrenzung zu fachlichen Validierungen ist. Unabhängig von der gewählten Implementierung zeigt das folgende Beispiel, worauf bei der Anzeige von Fehlern im Formular zu achten ist.

  • Setzen des novalidate-Attributs an das form-Element, um die clientseitige »HTML-Validierung« abzustellen;
  • Ändern des Seitentitels (title-Element), falls die Seite neu geladen wird, um direkt anzuzeigen, dass Fehler aufgetreten sind;
  • Auflisten aller Fehler mit Hinweisen zur Behebung in prägnanter und klarer Form zu Beginn des Formulars mit Sprungankern zu den entsprechenden Fehlern gemäß ISO 9241-110:

    »Art und Länge von Rückmeldungen oder Erläuterungen sollten den Benutzerbelangen entsprechen.«

    »Wenn sich ein Fehler ereignet, sollte dem Benutzer eine Erläuterung zur Verfügung gestellt werden, um die Beseitigung des Fehlers zu erleichtern.«

  • Kennzeichnung der fehlerhaften Felder über Fehlermeldungen direkt am Feld mit zusätzlicher farblicher Hervorhebung gemäß ISO 9241-110:

    »Aktive Unterstützung zur Fehlerbeseitigung sollte dort, wo typischerweise Fehler auftreten, zur Verfügung stehen.«

    Sowie gemäß BITV 2.0:

    »Farbe ist nicht als einziges Mittel zu verwenden, um Informationen zu übermitteln, eine Aktion anzuzeigen, eine Reaktion zu veranlassen oder ein visuelles Element zu kennzeichnen.«

Barrierefreie Hilfetexte und Anleitungen

Der Dialog sollte dem Benutzer solche Informationen anzeigen, die im Zusammenhang mit der erfolgreichen Erledigung der Arbeitsaufgabe stehen. Art und Länge von Rückmeldungen oder Erläuterungen sollten den Benutzerbelangen entsprechen (vgl. ISO 9241-110).

Verbreitete Screenreader schalten zur Abarbeitung von Formularen in einen bestimmten Modus um, in dem sie sich auf das Vorlesen von Formular- und Interaktionselemente beschränken und Nutzern erweiterte Tastaturkürzel zur Verfügung stellen. Aus diesem Grund ist besonders darauf zu achten, wie Erläuterungen und Hilfetexte in das Formular integriert werden.

  • Die Formatvorgabe steht innerhalb des Labels, das sich auf das entsprechende Feld bezieht, gemäß ISO 921-110:

    »Wenn eine Eingabe verlangt wird, sollte das interaktive System dem Benutzer Informationen über die erwartete Eingabe bereitstellen.«

  • Der Hilfetext steht vor dem Eingabefeld in einem a-Element (Link) und ist mit dem entsprechenden Feld verknüpft. Zudem ist das Eingabefeld über das Attribut aria-describedby mit dem Hilfetext verknüpft.

Darstellung des Formulars

Im Rahmen dieses Konzept wird nicht auf Aspekte des visuellen Stylings von Formularen eingegangen (die Beispiele bleiben weitgehend ungestylt), sondern mehr auf die Anwendung von CSS im Kontext »Responsive Webdesign«, also dem Auslesen von und der Reaktion auf Geräte- und Browsereigenschaften.

Responsive Webdesign und Mobile First

Beim Responsive Webdesign handelt es sich um ein gestalterisches und technisches Paradigma zur Erstellung von Websites, sodass diese auf Eigenschaften des jeweils benutzten Endgeräts, z.B. Smartphones oder Tablets, reagieren können. Betrachtet man bei der Konzeption und Entwicklung zunächst (mobile) Geräte mit eher kleinen Displays und erst nachrangig (stationäre) Geräte mit größeren Displays, spricht man von Mobile First.

Beide Konzepte finden beispielsweise Anwendung beim Formularlayout. Auf Smartphone werden alle Formularlemente und -felder linear untereinander dargestellt (Standarddarstellung). Auf größeren Displays steht mehr Raum zu Verfügung, sodass die Darstellung aufgelockert werden kann und Labels zur besseren Übersicht neben das entsprechende Feld gesetzt werden können. Alle Beispiele zeigen das Konzept (dazu die Listings über »Edit on Codepen« direkt aufrufen). Die Forderung der BITV 2.0 nach veränderbarer Textgröße wird eingehalten:

»Der Text lässt sich ohne assistive Technologie bis auf 200 % vergrößern, ohne dass es zu einem Verlust von Inhalt oder Funktionalität kommt.«

Visuelle Unterstützung für Menschen mit Behinderung

Um die Zugänglichkeit von Formularen auch, aber nicht nur für behinderte Nutzer zu erhöhen, sind Interaktionen und Interaktionsmöglichkeiten besonders hervorzuheben. Alle Beispiele zeigen einige Ansätze.

  • Deutlich erkennbare Kennzeichnung des aktuell fokussierten Feldes gemäß ISO 9241-110 sowie BITV 2.0:

    »Auf Handlungen des Benutzers sollte eine unmittelbare und passende Rückmeldung folgen, soweit dies den Erwartungen des Benutzers entspricht.«

    »Bei Tastaturbedienung ist immer ein Tastaturfokus sichtbar.«

  • Hervorhebung der Label beim Berühren mit der Maus;
  • Veränderung des Mauszeigers zu »Pointer« für klickbare Formularelemente.

Assistenten

Mit »Assistenten« sind hier Hilfsfunktionen gemeint, die Nutzern das Ausfüllen des Formulars erleichtern. Solche Assistenten bietet der Feldtyp Datumsfeld (input type="date"):

  • Im Feld steht ein Hinweis zum gewünschten oder erwarteten Format;
  • Beim Überfahren des Feldes mit dem Mauszeiger werden Pfeile zum Hoch- und Runtersetzen des Tages, Monats oder Jahres angeboten;
  • Beim Überfahren des Feldes mit dem Mauszeiger wird ganz rechts ein Pfeil angeboten, über den ein Datumsauswahlassistent angezeigt wird, in dem der Nutzer zum gewünschten Datum navigieren und es selektieren kann.

Nicht jeder moderne Browser unterstützt jedoch den Feldtyp Datumsfeld; andere Browser zeigen lediglich ein Textfeld an. Aus diesem Grund ist die native Browserlösung bei aktiviertem JavaScript durch eine selbst implementierte Lösung zu ersetzen. Das Beispiel verwendet das jQueryUI-Datepicker-Widget. Aus dem Datumsfeld wird ein Standard-Texteingabefeld; der Aufruf des Datumsauswahlassistenten erfolgt bei Klick in das Feld oder die Schaltfläche »Datum auswählen«. Dieses Widget ist jedoch nicht vollständig barrierefrei und dementsprechend anzupassen, da es nicht ohne weiteres mit der Tastatur zu bedienen ist, vgl. BITV 2.0:

»Die gesamte Funktionalität des Inhalts muss über eine Tastaturschnittstelle bedient werden können, ohne dass bestimmte Zeitvorgaben für die einzelnen Tastenanschläge einzuhalten sind.«

Testen

Nicht nur die Qualität der technischen Implementierung ist zu testen, sondern zudem das gesamte Formular hinsichtlich Usability und Barrierefreiheit.

Um zu überprüfen, ob ein Formular technisch korrekt implementiert ist, kommt der W3C Markup Validation Service des World Wide Web Consortiums (W3C) zum Einsatz, freie Services, über die HTML- sowie CSS-Code bezüglich ihrer Konformität zu den W3C-Empfehlungen und anderen Standards überprüft werden können.

Zur Prüfung der technischen Funktionsfähigkeit des Formulars empfiehlt sich der Einsatz eines automatisierten Cross-Browser-Testings-Werkzeugs wie etwa DalekJS. Dabei handelt es sich um ein in JavaScript geschriebenes Open-Source-Werkzeug, das automatisch einen Browser aufruft, ein Formular ausfüllt, absendet und testet und auch in der Lage ist, Screenshots aufzunehmen. Eine Alternative zu DalekJS bietet Selenium, ein weiteres quelloffenes Testwerkzeug für automatisierte Tests von Webanwendungen.

Die Usability wird – abhängig vom geplanten Aufwand – im Rahmen von Experten-Evaluationen geprüft oder durch Benutzungstests sichergestellt.

Das Ziel einer Experten-Evaluation ist es, mit möglichst geringem Aufwand möglichst viele Usability-Probleme eines Systems aufzudecken und zu kategorisieren. Der Usability-Experte führt Testläufe am Formular durch und erfasst mögliche Unregelmäßigkeiten, Probleme und Inkonsistenzen. In einem zweiten Durchgang, dem »Heuristic Walkthrough«, wird die Einhaltung etablierter Regeln und Standards überprüft.

Bei Usability-Tests werden Benutzer beobachtet, während sie Aufgaben mit dem zu testenden System ausführen. Aus der Art ihrer Interaktion, ihrem Verhalten und ihren Aussagen lassen sich wichtige Rückschlüsse zum Grad der Usability des Systems und Ansätze zur Verbesserung ableiten.

Die Barrierefreiheit wird über den BITV-Test sichergestellt, einem »Prüfverfahren für die umfassende und zuverlässige Prüfung der Barrierefreiheit von informationsorientierten Webangeboten«. Darüber hinaus empfiehlt es sich natürlich, im Rahmen der Benutzungstests auch behinderte Nutzer einzubeziehen.

Michael Jendryschik
Letzte Artikel von Michael Jendryschik (Alle anzeigen)
0 Kommentare

Hinterlasse einen Kommentar

An der Diskussion beteiligen?
Hinterlassen Sie mir einen Kommentar!

Ihre Kommentareingaben werden zwecks Anti-Spam-Prüfung an den Dienst Akismet gesendet. Darüber hinaus nutze ich die eingegebene E-Mail-Adresse zum Bezug von Profilbildern bei dem Dienst Gravatar. Weitere Informationen und Hinweise zum Widerrufsrecht finden sich in der Datenschutzerklärung.

Schreibe einen Kommentar

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