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.
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.
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.
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:
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.legend vor, aber lässt sie im Formularmodus weg, im Firefox dagegen wird im Formularmodus legend zusammen mit dem title-Attribut ausgegeben.label, title, aria-describedby, oder Feld-Vorbelegungen) möglicherweise doppelt vorgelesen und stören dadurch. 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.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.
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:
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:
select-Elementen), sollten die einzelnen Elemente mit einem title-Attribut ausgezeichnet sein (das erste Element sollte dennoch mit dem label verküpft sein).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.title und label (und ohne Vorbelegung) wird unter den von uns getesteten Screenreadern nur von NVDA (als Reparaturverhalten) unterstützt und sollte vermieden werden.legend eines Fieldsets für (viele) Screenreader zusammen mit label Sinn ergeben muss. Hat eine interessante Diskussion mit unterschiedlichen Positionen ausgelöst.Es gibt auch eine englische Version dieses Artikels.