Navigation

Service-Menü

Sprachversionen



Inhalt

Infothek

Barrierefreie Webanwendungen
Die Strukturierung von Formularen

15.02.2011

In vielen Empfehlungen für die Formular-Gestaltung spielt die Barrierefreiheit keine besondere Rolle. Dieser Artikel beschäftigt deshalb damit, wie blinde und sehbehinderte Nutzer Formulare wahrnehmen und was sich daraus für Empfehlungen für die Strukturierung ableiten lassen.

Es geht hier also nicht grundlegende Fragen des Formular-Designs, etwa, wie Formulare am besten einen Prozess abbilden und strukturieren, etwa um die conversion rate zu erhöhen. Auch Fragen der visuellen Formulargestaltung und der Fehlerbehandlung lassen wir unberücksichtigt.

Unterschiedliche Arten der Orientierung in Formularen

Für Nutzer ohne Einschränkungen ist die Orientierung per Überblick leicht. Für sie spielt die korrekte semantische Strukturierung des Formulars, etwa durch Überschriften oder Fieldsets, eine untergeordnete Rolle.

Für sehbehinderte Nutzer von Vergrößerungssoftware, die sich das Formular durch die Verschiebung eines kleinen Ausschnitts erschließen, hängt die gute Nutzbarkeit daran, dass das Formular linear geordnet ist oder durch anspringbare Zwischenüberschriften erschlossen werden kann. Für blinde Nutzer muss diese Struktur auch akustisch, per Screenreader, verfügbar sein. In beiden Fällen ist eine gute semantische Strukturierung, die auch bei Screenreadern ankommt, sehr wichtig.

Lesemodus und Formularmodus, automatischer Modus

Für Screenreader-Nutzer gibt es dabei zwei verschiedene Modi: Sie können ein Formular zum Einen im normalen Lesemodus (Virtual PC Cursor in JAWS, Browse Mode in Window Eyes, Virtual Buffer in NVDA), zum Anderen im Formularmodus nutzen.

Der Standard-Lesemodus gibt alle Formularinhalte der Reihenfolge nach aus (und zwar auch die title-Attribute und über CSS versteckte Labels), das Ausfüllen von Eingabefeldern ist aber nicht möglich. Besonders noch unbekannte Formulare lesen Screenreader-Nutzer vor dem eigentlichen Ausfüllen erst mal im normalen Lesemodus durch, um deren Inhalt und Zweck zu verstehen und zu prüfen, ob sie alle notwendigen Unterlagen zur Hand haben. Denn viele Formulare enthalten wichtige Informationen als normalen Zwischentext. Auch die Struktur längerer Formulare erschließt sich oft erst nur durch Zwischenüberschriften.

Den Formularmodus brauchen Nutzer, um beim Ausfüllen von Eingabefeldern alle Buchstaben zur Verfügung zu haben, da einige Tasten im Lesemodus verschiedenen Kurzbefehlen (etwa "h" für das Springen zur nächsten Überschrift) zugeordnet sind. Beim Durchtabben im Formularmodus fällt auf, dass nur die Formularelemente selbst (bzw. deren verknüpfte label und title-Attribute) ausgegeben werden: erklärende Zwischentexte oder Überschriften werden übersprungen. Das ist oft sogar erwünscht, nämlich bei bereits wohlbekannten Formularen (etwa beim Online-Kauf): dann geht das Ausfüllen einfach schneller. Einige Formularelemente wie Radiobuttons, Checkboxen oder Abschicken-Elemente (submit oder button) lassen sich aber auch im normalen Lesemodus bedienen.

Neuere Screenreader (bei JAWS ab Version 10) verfügen häufig über einen automatischen Modus, der selbsttätig in den Formularmodus umschaltet, sobald ein Eingabefeld erreicht wird, und danach in den Lesemodus zurückschaltet. Nutzer älterer Screenreader haben diese Option nicht und müssen explizit hin und her schalten. Und auch wenn der automatische Modus vorhanden ist: Ob er tatsächlich genutzt wird, hängt sowohl mit dem Kenntnisstand und den individuellen Präferenzen der Nutzer zusammen.

Zahlreiche Unterscheide in der Ausgabe

Soweit zum grundlegenden Unterscheid zwischen Lese- und Formularmodus. Es gibt jedoch leider noch eine ganze Reihe weiterer Faktoren, die mitentscheiden, was im konkreten Fall tatsächlich vom Screenreader ausgegeben wird:

  • Gewählte Konfiguration. Screenreader wie JAWS haben vielfältige Konfigurationseinstellungen, die in verschiedenen Kombinationen die Ausgabe auf verschiedene Art beeinflussen.
  • Unterschiede bei der Auswertung von fieldset > legend. Einige Screenreader (Window Eyes) lesen die Legende (legend) eines Fieldsets nur am Beginn und am Ende vor (wenigstens bei Nutzung im Internet Explorer), andere (JAWS, SUPERNOVA ) wiederholen sie im Formularmodus vor jedem Eingabeelement innerhalb des Fieldsets.
  • Browserabhängiges Verhalten der Screenreader. Screenreader haben öfters unterschiedliche Ausgaben abhängig vom genutzten Browser: so liest NVDA im Internet Explorer im Lesemodus legend vor, aber lässt sie im Formularmodus weg, im Firefox dagegen wird im Formularmodus legend zusammen mit dem title-Attribut ausgegeben.
  • Mögliche Verdoppelungen von Beschriftungen. Je nach Screenreader und Voreinstellungen werden redundante Auszeichnungen (etwa label, title, aria-describedby, oder Feld-Vorbelegungen) möglicherweise doppelt vorgelesen und stören dadurch.
  • Auswertung von angrenzenden Elementen. Manche Konstruktionen (etwa eine Sucheingabe bestehend aus einem label- und title-losen Eingabefeld und einem direkt anschließenden Button mit dem Inhalt „Suchen“) funktionieren nur in einzelnen Screenreadern. Diese abgespeckte Suche etwa funktioniert nur in NVDA: hier wird das nicht gesetzte Label für das Suchfeld aus dem value-Attribut des nachfolgenden button erschlossen. In JAWS dagegen wird lediglich "Eingabefeld" ausgegeben, und erst das Weitertabben zum "Suchen"-Button verrät, dass es sich hier um ein Suchfeld handelte. Erstaunlicherweise wird diese in den meisten Fällen schlecht zugängliche Konstruktion in der WCAG-Technik G176 "Using an adjacent button to label the purpose of a field" empfohlen.
  • Auswertung von WAI-ARIA Attributen. Zusätzliche Hinweise mittels WAI-ARIA (etwa über das Attribut aria-describedby) werden von manchen aktuellen Screenreadern ausgegeben, aber der Accessibility Support für WAI-ARIA lässt insgesamt noch zu wünschen übrig und ist deshalb allein nicht ausreichend (vergleiche unseren Artikel Die Zugänglichkeit von WAI-ARIA).

fieldset und legend oder Überschriften?

Gerade längere Formulare brauchen eine gute Gliederung, um Übersichtlichkeit zu gewährleisten. Je nach Fall sind dafür fieldset/legend oder Zwischenüberschriften geeigneter.

Bei längeren Formularen hilft eine gute Gliederung durch Zwischenüberschriften Screenreader-Nutzern, sich einen schnellen Überblick über Formularbereiche zu verschaffen. Dies ist besonders dann wichtig, wenn Nutzer das Ausfüllen längerer Formulare unterbrechen oder zuvor bereits gemachte Eingaben korrigieren wollen. Die Zwischenüberschriften helfen dann beim schnellen Wiederauffinden des gesuchten Formularbereichs.

Die Gliederung durch Fieldsets passt immer dann, wenn es Sinn macht, durch die wiederholte Ausgabe der Fieldset-Überschrift (legend) alle Eingabefelder klar einem bestimmten Fieldset zuzuordnen. Ein Beispiel: In einem Formular, das sowohl eine Rechnungsanschrift als auch eine Lieferanschrift enthält, würde es Sinn machen, die beiden Bereiche als verschieden Fieldsets mit den Legends „Rechnungsanschrift“ und „Lieferanschrift“ auszuzeichnen, um Verwechslungsmöglichkeiten bei Eingabefeldern wie „Straße“ zu minimieren. Dann würden beim Erreichen des Eingabefeldes Straße legend und label zusammen ausgegeben, also "Rechnungsanschrift: Straße".

Aus diesem Verhalten ergibt sich auch, dass sich legend nicht als Container für gliedernde Zwischenüberschriften eignet. Denn das wiederholte Vorlesen von längeren und nicht auf alle Eingabeelemente gleichermaßen passenden legend-Inhalten ist störend. Designer sollten also beim Einsatz von Fieldsets immer legend zusammen mit dem Label (bzw. title) der Eingabefelder vorlesen und prüfen, ob das zusammen Sinn macht.

fieldset auch ohne legend nutzen?

Kann man fieldset auch einfach als grafische Gruppierung nutzen und legend weglassen? Das Fehlen von legend führt in den uns bekannten Validatoren nicht zu einem Validierungsfehler.

Laut UAAG 1.0 sollte fieldset allerdings immer mit legend eingesetzt werden (auch wenn die Nutzung von legend in der HTML 4.01 Spezifikation nicht ausdrücklich vorgeschrieben ist) . Eine gliedernde Funktion hat fieldset ohne legend nur für sehende Nutzer; die strukturelle Gliederung muss dann, wenn nötig, durch Überschriften erreicht werden. Das Reparaturverhalten von JAWS, bei fehlendem legend-Element einfach die vorangehende Überschrift als Legende zu nehmen, fanden wir in der aktuellen Version nicht mehr vor.

Zwischentexte als Link auszeichnen?

Die Formular-Serie bei "Einfach für alle" nennt die Möglichkeit, erklärende Zwischentexte zu Links zu machen (mit Sprunglink auf das relevante Formularelement), damit sie auch im Formularmodus vorgelesen werden. Das klappt auch in JAWS und Window Eyes. Die Frage ist allerdings, ob das wirklich eine gute Idee ist:

  • Sehen Zwischentexte wie Links aus, vermutet man am ehesten einen zusätzlichen Hilfetext dahinter, nicht einen Sprunglink zum Eingabeelement.
  • Versteckt man die Links mittels CSS, verwirrt das sehende Tastaturnutzer, wenn die (nicht wie Links aussehenden) Links plötzlich beim Durchtabben den Fokus erhalten. Und für sehbehinderte Nutzer mit benutzerdefinierten Farben, benutzerdefinierten Stylesheets oder ausgeschalteter CSS-Unterstützung sehen diese Links eben doch wie Links aus.
  • Auch für Screenreader-Nutzer dürfte es verwirrend sein, wenn erklärende Texte als Link vorgelesen werden.

Beschriftungen von Formularelementen

Klar ist natürlich, dass Labels aussagekräftig, korrekt verknüpft und richtig platziert sein sollten (bei Text-Input-Feldern vor, bei Checkboxes und Radio-Buttons nach dem Eingabeelement – bei letzteren werden Labels vom Screenreader vor dem Eingabeelement vorgelesen). Darüber hinaus gibt es folgende speziellere Empfehlungen:

  • Wenn ein Label eine Gruppe von kombinierten Eingabeelementen beschreibt (etwa bei einer Datumseingabe mit drei select-Elementen), sollten die einzelnen Elemente mit einem title-Attribut ausgezeichnet sein (das erste Element sollte dennoch mit dem label verküpft sein).
  • Eine Identifizierung von Eingabefeldern lediglich über eine Textvorbelegung ist nicht ausreichend, da diese nach einer Nutzereingabe nicht mehr verfügbar ist.
  • In manchen Fällen (etwa im Fall einer Suche, die ein Eingabefeld und einen nachfolgenden Suchen-Button kombiniert) kann das Label entfallen und durch title und gegebenenfalls eine Suchfeldvorbelegung ersetzt werden. Denn in Fällen wie einer Sucheingabe ist der Zweck für sehende Nutzer durch die Nachbarschaft des Sucheingabefeldes und des „Suchen“-Buttons ausreichend klar, title erledigt die akustische Ausgabe.
  • Die in der WCAG 2.0-Technik G167 vorgeschlagene Nutzung nachfolgender Buttons als 'erschlossenes' Label für Eingabefelder ohne title und label (und ohne Vorbelegung) wird unter den von uns getesteten Screenreadern nur von NVDA (als Reparaturverhalten) unterstützt und sollte vermieden werden.

Kommentierte Quellen

Es gibt auch eine englische Version dieses Artikels.