Reine Formsache

Barrierefreie Formulare mit HTML, CSS & JavaScript

Ausfüllen, abschicken, fertig: Diskussionen in Foren und Weblogs, Jobangebote und –gesuche in Stellenbörsen, Fahrplanauskünfte bei der Bahn oder Bestellungen und Bezahlung in Online-Shops funktionieren mit Formularen. Redaktionssysteme und Weblogs arbeiten in der Regel formularbasiert. Formulare sind oft der Kern interaktiver Angebote und Grundlage der Kommunikation zwischen Anbietern und Nutzern einer Webseite.

Die Grundfunktionen eines Formulars – ausfüllen und abschicken – müssen mit allen möglichen Mitteln der Bedienung und der Ausgabe gelingen. Der Anbieter einer Webseite sollte ein Interesse daran haben allen Nutzern, auch wenn sie assistive Werkzeuge wie z. B. Screenreader, Spracherkennung oder Spezialtastaturen einsetzen, das vollständige Ausfüllen und Abschicken seiner Formulare zu ermöglichen.

Gerade bei Formularen gilt das POUR-Prinzip der WCAG 2.0 in Reinform: Formulare müssen wahrnehmbar (perceivable), bedienbar (operable), verständlich (understandable) und robust (robust) sein. In den Richtlinien finden sich zwar nur wenige direkte Vorgaben zu Formularen, jedoch sind fast alle Punkte der WCAG bzw. BITV anwendbar – von HTML über CSS und Bilder bis zu JavaScript. Nur der vollständige Einsatz aller Möglichkeiten stellt sicher, dass Ihre Formulare mit allen denkbaren Zugangsformen verstanden und bedient werden können. Aber obwohl HTML seit Jahren viele Elemente für barrierefreie und damit bedienerfreundliche Formulare enthält, werden diese nur sehr sparsam eingesetzt.

Für öffentliche Anbieter, die den Vorgaben der BITV unterliegen, ist der Einsatz dieser Mittel klar geregelt: die Verordnung verlangt den Einsatz der korrekten HTML-Elemente und CSS für die Gestaltung; weitergehende Vorgaben zur Orientierung und geräteunabhängigen Bedienung treffen selbstredend auch auf Formulare zu.

Um die Markup-Grundlage von Formularen geht es in Teil 1 unserer Serie: »HTML-Elemente für Formulare«. In Teil 2 – »Formulardesign« – dreht sich alles um die Gestaltung und Usability und im dritten Teil der Serie geht es um Fehler und wie man mit ihnen umgeht: »Toleranz und Rücksicht«.

In Zeiten des Mitmach-Webs werden Formulare noch wichtiger, sie sind sozusagen das Bindeglied zwischen Web 1.0 und 2.0. Neben den für die Struktur benötigten HTML-Elementen und CSS für die Gestaltung kommt hier in der Regel noch JavaScript für das Verhalten der Formulare zum Einsatz. In der fest in der statischen Web 1.0-Welt verhafteten BITV ist Dynamik via JavaScript effektiv verboten, besonders wenn keine Alternativen ohne clientseitiges Scripting bereitgestellt werden. Viele Web-basierte Anwendungen sind jedoch ohne JavaScript kaum oder gar nicht nutzbar. Daher geht es in Teil 4 der Serie um »Dynamik in Formularen«.

In Teil 5 der Serie zeigen wir, wie Sie mit einigen einfachen Tests schon während der Entwicklung eine erste Qualitätssicherung vornehmen können und geben Tipps für Tests mit echten Nutzern: »Testen von Formularen und Web-basierten Anwendungen«. Zum Abschluss geht es um Dinge, die sie besser nicht oder nur nach reiflicher Überlegung in ihre Formulare einbauen sollten: »Strittige Punkte«.

HTML-Elemente für Formulare

Der Erfolg eines Formulars oder einer Formular-basierten Anwendung hängt stark vom ersten Eindruck ab: erschlagen Sie Ihre Nutzer mit einer Vielzahl unübersichtlicher, weil unstrukturierter Optionen, werden Sie diese Nutzer so schnell nicht wieder sehen. Ist Ihr Formular intuitiv zu bedienen und schneidet es bei den klassischen Usability-Meßgrößen Effektivität, Effizienz und Zufriedenheit gut ab, dann werden Ihre Formulare von einer höheren Anzahl Nutzer bewältigt werden.

Logische Blöcke

Wenn Sie ein komplexes Formular anbieten, das aus mehreren logischen Einheiten besteht, sollten Sie über den Einsatz des FIELDSET-Elementes nachdenken. Mit fieldset lassen sich Formulare in leichter überschaubare Blöcke unterteilen. Es werden genau die Bestandteile zusammengefasst, die eine logische Einheit ergeben. Diese können dann übersichtlicher gestaltet und vom Besucher nacheinander abgearbeitet werden. So können Sie unerfahrenen Benutzern die einzelnen Schritte häppchenweise präsentieren und diese mit erklärenden Texten (»Als nächstes geben Sie bitte Ihre persönlichen Daten ein…«) unterbrechen.

Gerade bei Formularen, in denen die Eingabe einer Vielzahl unterschiedlicher Daten verlangt wird, trägt diese Technik zur Übersichtlichkeit für den Anwender bei. Für Nutzer, bei denen die Hürden weitestgehend im kognitiven Bereich bestehen, können Sie so die Zahl der ›Abbrecher‹ reduzieren.

Durch den Einsatz von Legenden für die einzelnen Fieldsets können Sie Ihren Besuchern eine weitere Orientierungshilfe geben. Das Element LEGEND ist ein nicht-optionales, also beim Einsatz von FIELDSET zwingend vorgeschriebenes Unter-Element von FIELDSET, das von grafischen Browsern am Beginn des abgegrenzten Bereichs dargestellt wird. Per CSS und JavaScript lassen sich hier Strukturen schaffen, die zum Beispiel eine Präsentation in Form von Karteireitern und -karten ermöglichen:

Fieldsets können übrigens auch verschachtelt werden, d. h. innerhalb eines Fieldsets können weitere Fieldsets enthalten sein, um zum Beispiel zusammengehörige Gruppen von Kontrollelementen darzustellen:

<fieldset>
 <legend>Äussere Legende</legend>

  <label for="textinput1">Explizites Label:</label><br>
  <input type="text" name="textinput1" id="textinput1"><br>

  <label>Implizites Label:</label><br>
  <input type="text" name="textinput2" id="textinput2"></label><br>

  <fieldset>
   <legend>Innere Legende Eins</legend>

	<input type="radio" name="flavor1" id="toffee" value="toffee">
	<label for="toffee">Vanilla Toffee Crunch</label><br>

	<input type="radio" name="flavor1" id="chunky" value="chunky">
	<label for="chunky">Chunky Monkey</label><br>

	<input type="radio" name="flavor1" id="oatmeal" value="oatmeal">
	<label for="oatmeal">Oatmeal Cookie Chunk</label>
   </fieldset>

   <fieldset>
	<legend>Innere Legende Zwo</legend>

	 <input type="checkbox" name="flavor2" id="brownie" value="chocolate">
	 <label for="brownie">Chocolate Fudge Brownie</label><br>

	 <input type="checkbox" name="flavor2" id="cookie" value="cookie">
	 <label for="cookie">Chocolate Chip Cookie Dough</label><br>

	 <input type="checkbox" name="flavor2" id="fudge" value="fudge">
	 <label for="fudge">New York Super Fudge Chunk</label>
   </fieldset>

 <button type="submit">Yummie!</button>

</fieldset>

(Testseite als HTML-Datei)

In der grafischen Ausgabe sind diese dann deutlich voneinander getrennt; per CSS können Sie nun den inneren Fieldsets ein anderes Aussehen verpassen als dem Äußeren:

Diese Verschachtelungen können Sie sich zunutze machen und optionale Formularbereiche gruppieren, die vom Nutzer nicht zwingend ausgefüllt werden müssen. Der Nutzer kann diese so einfacher überspringen; per JavaScript können Sie den Nutzer diese optionalen Felder auch einfach ausblenden lassen. Mit FIELDSET haben Sie hier das semantisch naheliegendste Element gewählt statt eines bedeutungslosen generischen DIV.

Zu viel des Guten: Überlange oder unnötige Legenden

Verbreitete Screenreader lesen im Formularmodus den Inhalt einer Legende nicht zu Beginn des Fieldsets vor. Statt dessen wird der Text bei jedem einzelnem Kontrollelement bzw. dessen Label vorgelesen, das sich innerhalb des damit ausgezeichneten Fieldsets befindet. Dies kann, je nach Legendentext, sehr schnell dazu führen, dass Ihre Formulare im Screenreader kaum noch zu benutzen sind. Beim Nutzer werden Ermüdungserscheinungen hervorgerufen, wenn dieser gezwungen wird, sich den immer gleichen Zusatztext bei jeder einzelnen Checkbox und bei jedem einzelnem Radiobutton anzuhören (auch wenn dieses Verhalten in den Einstellungen abschaltbar ist).

Das Verhalten der Screenreader ist an sich nicht schlecht: so wird dem Nutzer jederzeit die Orientierung geboten, in welchem Bereich eines Formulars er sich befindet – was dem sehenden Nutzer durch optische Zusammenhänge klar wird, in der Sprachausgabe jedoch naturgemäß fehlt. Problematisch wird dieses Verhalten, wenn der Legendentext eine bestimmte Länge überschreitet oder im gesprochenen Zusammenhang mit dem Labeltext keinen Sinn mehr ergibt.

Wann Sie diese Grenze überschritten haben, ab der es zu viel wird, können Sie mit einem einfachen Test auch ganz ohne Screenreader feststellen: Lesen Sie den Textinhalt des Formulars laut vor und setzen die Legende erneut vor jedes Label. Wenn sich das dann so anhört:

»Ihre persönlichen Daten eingeben Ihr Vorname Ihre persönlichen Daten eingeben Ihr Nachname Ihre persönlichen Daten eingeben Ihre Adresse Ihre persönlichen Daten eingeben Ihre Postleitzahl Ihre persönlichen Daten eingeben Ihr Ort Ihre persönlichen Daten eingeben Abschicken«,

dann haben Sie klaren Bedarf zur Nachbesserung. Unter Umständen kann es angebracht sein, auf LEGEND ganz zu verzichten, besonders wenn die Kontrollelemente durch die verwendeten Labels ausreichend beschrieben sind. Leider geben einige Accessibility-Checker einen Fehler aus, wenn kein LEGEND im Code vorgefunden wird. Unsere kritische Haltung gegenüber diesen Prüfprogrammen ist hinreichend bekannt – im Ernstfall sollte man sich hier für den Nutzer entscheiden.

Sind Überschriften nicht manchmal besser?

Wenn Ihr Formular in einer ansonsten mit Überschriften strukturierten (Text-) Seite steht kann es durchaus sinnvoll sein, auf den Einsatz von Fieldset und Legend ganz zu verzichten und dem Formular stattdessen eine eigene Überschrift (H1-6) zu geben. Auch wenn Ihr Formular aus einem einzigen Kontrollelement besteht, ist die volle Packung aus FIELDSET, LEGEND usw. oftmals ein Code-Overkill, mit dem bestenfalls redundante Informationen mehrfach transportiert werden.

Welche Kontrollelemente gibt es?

Die Menge und Möglichkeiten der in HTML zur Verfügung stehenden Kontrollelemente in Formularen ist ausgesprochen begrenzt, gerade im Vergleich zu der Vielzahl der Möglichkeiten in den grafischen Betriebssystemen. Sie haben allerdings den Vorteil, dass ihr Zweck und ihre Funktionen eindeutig definiert sind und sie mit den üblichen Hilfsmitteln behinderter Nutzer in der Regel gut zu bedienen sind.

Im Einzelnen sind dies:

• Auswahllisten (SELECT und OPTION),
• der Sonderfall Auswahllisten mit Mehrfachauswahl (SELECT mit dem multiple-Attribut und OPTION)
• Radiobuttons zur Entweder/Oder-Auswahl (<input type="radio">)
• Checkboxen zur Sowohl/Als auch-Auswahl (<input type="checkbox">)
• einzeilige und mehrzeilige Textfelder zur Eingabe (INPUT mit dem Attribut type="text" sowie mit dem Attribut type="password" für Passwörter und TEXTAREA)
• Elemente für Datei-Uploads (INPUT mit dem Attribut type="file")

sowie die Schaltflächen-Elemente (Buttons) zum Übergeben bzw. Abbrechen von Formularen:

• input type="submit"
• input type="reset"
• input type="image"
• input type="button" sowie:
• button

Im Sinne der Barrierefreiheit sind alle diese Elemente neutral, d. h. ihr Einsatz stellt keine besonderen Hürden im Umgang mit Web-Formularen dar. Mit zwei Ausnahmen:

• Der Button zum Zurücksetzen eines Formulars auf den ursprünglichen, meist leeren Zustand (<input type="reset">) ist selten sinnvoll (wenn überhaupt). Der Schaden, den ein solcher Button anrichten kann, wird bei weitem von dessen Nutzen aufgewogen. Seine ganze fatale Wirkung entfaltet dieser Button, wenn »Abbrechen« vor der primären Aktion steht (also üblicherweise »Absenden« oder »Speichern«): je nach Browser leert ein unachtsamer Druck auf Enter das Formular und befördert alle Eingaben des Nutzers zuverlässig in den Datenhimmel.
• Die Eingangs der Auflistung erwähnten Elemente zur Mehrfachauswahl (<select size="10" multiple="multiple">). Bei diesen Feldern ist für den Benutzer nicht ohne weiteres erkennbar, dass hier tatsächlich mehrere Optionen ausgewählt werden können – damit hätten wir die erste kognitive Barriere. Zudem ist die Bedienung (Auswahl per Maus mit gedrückter STRG- bzw. Apfel-Taste) nicht unbedingt intuitiv bzw. kann nicht als gelernt vorausgesetzt werden – eine weitere Barriere. Zudem lässt sich dieses Element nur umständlich oder im Ernstfall gar nicht per Tastatur bedienen. Bevor Sie sich hier in langatmigen Hilfetexten verzetteln sollten Sie gleichwertige Checkboxen für Mehrfachauswahlen einsetzen.

Strukturen im Kleinen: Optgroup

Ein Element fristet leider ein Schattendasein und wird im Code von Formularen viel zu wenig eingesetzt: OPTGROUP. So wie Sie mit Fieldsets größere logische Einheiten von Formularelementen gruppieren können, so geht dies per <optgroup>-Tags auch innerhalb von Auswahlfeldern vom Typ SELECT. Innerhalb einer Optgroup können zum Beispiel Länder der jeweiligen Kontinente zusammengefasst werden oder Geschmacksrichtung bei der Auswahl von Eissorten, wie das folgende Markup-Beispiel zeigt:

<select name="Eissorte">

 <option disabled selected>Bitte auswählen:</option>

  <optgroup label="Schokoladig"> 
   <option>Chocolate Fudge Brownie</option>
   <option>New York Super Fudge Chunk</option>
   <option>Chocolate Therapy</option>
   <option>Chocolate Chip Cookie Dough</option>
  </optgroup>

  <optgroup label="Fruchtig">
   <option>Cherry Garcia</option>
   <option>Bohemian Raspberry</option>
   <option>Chunky Monkey</option>
   <option>Peace of Cake</option>
  </optgroup>

</select>

Das Ergebnis sieht im Browser wie folgt aus:

Durch das label-Attribut von Optgroup (nicht zu verwechseln mit dem LABEL-Element!) können nun den einzelnen Gruppen noch Kennzeichnungen vorangestellt werden, die selbst nicht auswählbar sind, sondern nur der Strukturierung dienen.

Welches Element ist das Richtige?

Bei der Festlegung der Kontrollelemente sollten Sie sich folgende Fragen stellen:

1. Was ist für den Nutzer naheliegender – das Eintippen eines freien Textes oder die Auswahl aus einer Liste von Optionen? Was fängt die möglichen Eingaben des Nutzers am besten ab? So kann man in einem Bestellvorgang die Anzahl der zu bestellenden Produkte als Textfeld oder als Auswahllisten (z. B. 1-10) hinterlegen. Im Zweifelsfall sollten Sie sich für größtmögliche Freiheiten für den Nutzer entscheiden.
   Bei ›Einfach für Alle‹ gab es früher eine Broschüre, die über ein Bestellformular angefordert werden konnte. In diesem Bestellformular war die Anzahl der Broschüren über ein Textfeld frei einzugeben; zur Verhinderung von Scherzbestellungen war dieses Textfeld per maxlength-Attribut auf zwei Ziffern begrenzt. Nun gab es aber tatsächlich Fälle, in denen jemand gleich einen ganzen Karton mit 100 Broschüren für eine Bildungseinrichtung bestellen wollte, was mit diesem Formular unmöglich war.
2. Mit welchem Element kann der Nutzer die wenigsten Fehler machen? Kann man sich einfach vertippen? Dann sollten Sie bei einer überschaubaren Anzahl von Optionen dem Nutzer die Arbeit abnehmen und diese als Auswahl präsentieren. Bei der Eingabe von freien Texten können Sie den Nutzer unterstützen, indem die Eingaben unmittelbar clientseitig validiert bzw. im Hintergrund an den Server geschickt werden, um die Plausibilität der Eingaben zu überprüfen.
3. Muss der Nutzer sämtliche Optionen lesen, um die Abfrage zu verstehen? Dann sollten Sie die beschreibenden Texte und Labels möglichst kurz und prägnant halten. Die Erfahrung hat gezeigt, dass Nutzer desto weniger Text lesen, je mehr in einem Formular steht. In Tests ist sogar oft zu beobachten, dass Nutzer noch während des Ladens der Seite anfangen, mit dem Formular zu interagieren, ohne sich vorher in Ruhe zu orientieren und eventuell bereitgestellte Hilfen zur Kenntnis zu nehmen.
4. Wieviele Optionen gibt es? Kann der Nutzer mehr als eine Option auswählen? Bei begrenzten Auswahlmöglichkeiten, oder wenn immer nur eine Option zulässig ist (wie die Angabe der Kreditkarte in einem Bezahlvorgang) fällt schon fast zwangsläufig die Wahl auf Radiobuttons. Bei Mehrfachauswahlen bieten sich Checkboxen an.
5. Wollen Sie Ihren Benutzern wirklich die Navigation in einer Auswahlliste mit mehreren hundert Einträgen zumuten? Schlechte Beispiele hierfür finden sich im Netz zuhauf bei den Länderauswahlen: viele Anbieter hinterlegen hier sämtliche Staaten dieser Erde, auch wenn sie ihre Waren nur in Deutschland und dem benachbarten Ausland ausliefern. Auch die Strukturierung nach Kontinenten per OPTGROUP ist nur dann wirklich sinnvoll, wenn Sie tatsächlich Kunden auf allen Kontinenten bedienen wollen. Die Beschränkung auf eine Anzahl realistischer Optionen erscheint hier oftmals sinnvoller.
6. Was entspricht den (Seh-) Gewohnheiten der Nutzer? Bei der Auswahl eines Datums (nach der Art TT MM JJJJ) werden immer wieder unbeabsichtigte Barrieren aufgebaut. Bei der freien Eingabe in ein Textfeld kann es zu Problemen mit der Internationalisierbarkeit (I18N) kommen, wenn Nutzer aus unterschiedlichen Ländern unterschiedlichen Konventionen in der Sortierung folgen. Für einen Europäer ist 01/04/07 der 1. April 2007, für Amerikaner wäre dies jedoch der 4. Januar 2007; in Ländern mit umgedrehter Leserichtung (von rechts nach links) könnte dies auch als der 7. April 2001 gelesen werden. Auch die Hinterlegung als getrennte Auswahl in Form von getrennten Auswahllisten für Tag, Monat und Jahr ist suboptimal, da nur umständlich zu bedienen. Das natürlichste Element mit dem geringsten Verwechslungspotenzial wäre hier ein Kalender, den man mit ein wenig JavaScript und einer Datentabelle ins Formular integrieren kann. Wie dies barrierefrei zu realisieren ist zeigt das folgende Beispiel: »Unobtrusive JavaScript date-picker widgit«.

Welche Kontrollelemente gibt es nicht?

Die meisten klassischen Formulare werden mit dem begrenzten Satz sicher gut zurechtkommen, den HTML zur Verfügung stellt. Bei Web-basierten Anwendungen stößt man jedoch sehr schnell an die Grenzen der Markup-Sprache, die eigentlich nie für solche Anwendungen gedacht war. Was im HTML-Standard bis heute fehlt sind Elemente, die jenseits des Web-Browsers gang und gäbe sind wie zum Beispiel:

• Schieberegler (Slider),
• Textfelder, in denen mit Pfeiltasten die Werte herauf- oder herabgesetzt werden können (Numeric Stepper),
• Comboboxen mit Mehrfachauswahl und eigenen Eingaben
• echte Warndialoge (Alerts)
• Fortschrittsbalken
• Farbauswahl
• Checkboxen mit drei Zuständen (Tri-State: Ja, Nein und Teilweise)
• u.v.m. …

Falls Ihre Anwendung diese Elemente bzw. deren Funktionalität benötigt, so kommen sie zurzeit nicht umhin, diese per JavaScript nachzubilden. Sie sollten aber auch hier die HTML-Elemente zu Grunde legen, die der Bedeutung und Funktion am Nächsten kommen. Besserung versprechen hier die Aktivitäten der WAI-ARIA-Arbeitsgruppe des W3C, mit deren Hilfe dynamische Webinhalte für Menschen mit Behinderungen und ihre Hilfsmittel zugänglicher werden sollen. Bis dies jedoch in der Praxis umsetzbar sein wird hilft nur Improvisation und Ausreizung der Möglichkeiten des Vorhandenen.

Etikettierung mit Label

Neben der Navigation sind Formulare die Elemente einer Webseite, mit denen die Nutzer am häufigsten interagieren. Daher ist gerade bei Formularen nicht nur die Unabhängigkeit von den Ausgabemedien, sondern auch von den Eingabemedien wichtig. Eine wirkliche Barrierefreiheit erreichen Sie erst, wenn die bereitgestellten Funktionen mit einer Vielzahl von Eingabe- und Zeigegeräten bedient werden können. Zum Glück bietet HTML hierfür Elemente, die eine Bedienung unabhängig von der Umgebung ermöglichen.

Sie kennen diese Techniken aus Ihrem Betriebssystem und anderen Anwendungen: in Dialogen mit Checkboxen und Radiobuttons lassen sich nicht nur die Kontrollelemente selbst betätigen; es reicht auch, wenn man den daneben stehenden Text anklickt und schon ist das Häkchen gesetzt. Der Hintergrund dafür ist eine einfache Regel: je größer das Ziel, desto höher die Trefferwahrscheinlichkeit (Fitts' Law).

Mit dem dafür nötigen kleinen Kunstgriff kommen nicht nur erfahrene Nutzer schneller zum Ziel, die diese Arbeitsweise aus Anwendungen gewohnt sind. Gerade Menschen mit motorischen Behinderungen, die Probleme mit der exakten Positionierung der Maus haben oder alternative Zeigegeräte benutzen, können nun auf den dazugehörigen Text des Formularfeldes, das sogenannte Label, klicken. Blinde oder stark sehbehinderte Nutzer von Screenreadern sind ebenfalls auf die Bedienung per Tastatur angewiesen. Erst durch die Verknüpfung des Kontrollelementes mit seiner Beschriftung wird in der Sprachausgabe Sinn und Zweck des jeweiligen Kontrollelementes klar.

Labels in HTML

HTML sieht hierfür seit der Version 4 das Element LABEL vor. Dieses Label können Sie mit dem dazu gehörigen Kontrollelement verknüpfen, indem Sie letzterem eine eindeutige ID (id="textfeld1") zuweisen. Diese id wird dann ebenso im for-Attribut des label-Tags benutzt und schon ist die Beschriftung mit dem jeweiligen Formularelement verknüpft und anklickbar:

<label for="textfeld1" class="left">Text:</label>
<input id="textfeld1" type="text"><br>
[…]
<input id="checkbox1" type="checkbox" value="ja" class="right">
<label for="checkbox1">Sowohl</label><br>

Diese Methode funktioniert bei allen Kontrollelementen, denen ein Label zugewiesen werden kann. Beachten Sie, dass einem Kontrollelement gemäß dem HTML-Standard sogar mehrere Labels zugeordnet werden können.

Folgenden Elementen können und sollten Labels zugewiesen werden:

• input type="text"
• input type="checkbox"
• input type="radio"
• input type="file"
• input type="password"
• textarea
• select

Labels können nicht für folgende Elemente verwendet werden, da hier die Informationen über das value-Attribut (z. B. für submit-Buttons), das alt-Attribut (für grafische Buttons vom Typ input type="image") oder den Inhalt des Elementes selbst transportiert werden:

• Submit und Reset-Buttons (input type="submit" bzw. input type="reset")
• Grafische Buttons (input type="image")
• Versteckte Eingabefelder (input type="hidden")
• Script-Buttons (button bzw. input type="button")

Warnhinweis: Implizite Labels

Nach den Spezifikationen ist es zulässig, das Label um das Kontrollelement herum zu legen, statt es ihm vor- oder nachzustellen. Hiermit könnte man sich als Webentwickler die Zuweisung über id="" und for="" sparen, da das Label nun durch diese Verschachtelung implizit zugeordnet ist:

<label>Text:<input type="text"></label>

Soweit die Theorie. Die Unterstützung für diese Variante ist jedoch selbst in aktuellen assistiven Programmen eher lückenhaft und daher nicht zu empfehlen. Die zum Zeitpunkt der Veröffentlichung aktuelle Version 7.1 des verbreiteten Screenreaders JAWS hat bis dato Probleme mit impliziten Labels, obwohl diese bereits seit 1997 Bestandteil der HTML 4-Empfehlung sind. So werden implizite Labels für Checkboxen und Radiobuttons sogar im Formularmodus nicht vorgelesen, bei Textfeldern ist dies nach Aussage von Nutzern »Glückssache«. Um maximale Kompatibilität zu garantieren, sollten Sie auf die zuerst beschriebene Form der expliziten Verknüpfung zurückgreifen.

Falls Sie aus irgendwelchen Gründen gezwungen sein sollten, implizite statt explizite Labels zu benutzen, so können Sie den Label-Text in einem title-Attribut des jeweiligen Kontrollelementes wiederholen. In diesem Fall lesen JAWS, Window Eyes & Co. den Text des title-Attributs, sobald das Kontrollelement den Fokus erhält.

Neu! Jetzt mit Knopf zum Selberdrücken!

Auch wenn Labels aus Sicht der Accessibility sicher ein wichtiges Element sind, ohne Abschicken- oder Speichern-Buttons geht gar nichts. Dafür kennt der HTML-Standard gleich zwei Methoden: die verbreitete per input type="submit" und das weithin unbeachtete, aber wesentlich flexiblere BUTTON-Element. Die Syntax für gleiche Funktionen ist bei beiden Methoden gleich – mit button type="submit" wird ein Formular bzw. dessen Inhalt ebenfalls zum Server geschickt.

Werte für Buttons

Bei Elementen ohne Label wie z. B. "Abschicken"-Buttons müssen die Informationen über die ausgelöste Aktion über den jeweiligen Wert des Kontrollelementes (value="Formular abschicken") hinterlegt werden. Wenn Sie diesen Wert nicht setzen, überlassen Sie es damit dem jeweiligen Browser, welcher Text auf dem Button erscheint. Ein einfaches:

<input type="submit">

ohne Angabe des Attributs value ergibt:

Dieser vom Browser nach Gutdünken vergebene Text muss nicht unbedingt dem Ergebnis der ausgelösten Aktion entsprechen. Der Internet Explorer macht z. B. aus dem obigen Code »Anfrage senden«, in Firefox heißt der Text »Anfrage abschicken«, bei Opera und Safari ist das Ergebnis ein einfaches »Senden«. Bei den englischen Programmversionen wird vom jeweiligen Browser ein englischer Text eingefügt (»Submit …«), was in den meisten Fällen wenig wünschenswert ist.

Wenn Sie grafische Buttons nach der Art von <input type="image" src="button.gif"> beziehungsweise <button><img src="button.gif"></button> verwenden, sollten Sie grundsätzlich ein alt-Attribut setzen, ansonsten wird der grafische Button von einer Sprachausgabe nicht vorgelesen und das Formular ist damit nicht mehr abschickbar. Im Interesse von Nutzern, die Ihre Formulare mit Spracherkennung bedienen, sollte das alt-Attribut den exakten Text des grafischen Buttons als Äquivalent enthalten. Die Spracherkennungs-Software orientiert sich am Quelltext und weiss nicht, was in Ihrem grafischen Button steht; der Nutzer wiederum liest den Text des grafischen Buttons. Wenn dieser nicht mit dem maschinenlesbaren Text übereinstimmt, wird die Aktion nicht ausgeführt.

Formulare mit und ohne Tabellen

Mangelnde Linearisierung: Warum Tabellen vollkommen ungeeignet für Formulare sind

Wie beim allgemeinen Layout von Seiten gilt auch für Formulare: Layout-Tabellen sind eine Technik aus dem vergangenen Jahrhundert. Mit Browsern der vierten Generation war eine durchgängige, also in allen damals vorhandenen Browsern vergleichbare Gestaltung und Funktionalität nur mit Layout-Tabellen erreichbar. Mittlerweile sind diese Browser aber den Gang alles Irdischen gegangen und tauchen in keiner Statistik mehr in Größenordnungen auf, die eine spezielle Berücksichtigung rechtfertigen.

Zudem sind die meisten im Netz zu findenden Formulare lediglich eine Abfolge von nacheinander abzuarbeitenden Funktionen, die meistens in keiner Beziehung zueinander stehen und somit auch keine tabellarischen Daten darstellen. Layout-Tabellen bringen eine Vielzahl von Problemen mit sich, insbesondere wenn sie nicht in einem der üblichen grafischen Browser ausgegeben werden. Das folgende Beispiel zeigt eine durchaus gängige Art für die Eingabe persönlicher Daten für den Benutzer in einer unsichtbaren Layout-Tabelle:

Zur Verdeutlichung hier nochmals die gleiche Tabelle, diesmal mit hervorgehobenen Rändern, um die Reihenfolge der Tabellenzellen zu verdeutlichen:

Werden die Inhalte dieser Tabelle nun in linearisierter Form dargestellt (d. h. in der Reihenfolge, in der sie im Quelltext erscheinen) so ergibt sich z. B. in einem Screenreader folgender Output:

Vorname Nachname Textfeld Textfeld

Wenn in einem Formular nun viele Daten auf die gleiche Art abgefragt werden, verliert ein Benutzer einer Sprachausgabe sehr schnell die Orientierung, da die eindeutige Zuordnung der Beschriftungen zu den Formularelementen nicht mehr gegeben ist. Zwar können Sie die Beschriftungen per Label den jeweiligen Textfeldern zumindest programmatisch zuordnen, die Reihenfolge im Quelltext bleibt jedoch nach wie vor die Falsche und wird unter Umständen auch genau so falsch vorgelesen. Auch eine Zuordnung der Tabellenzellen über die für Datentabellen gedachten Elemente wie TH, scope, axis etc. ist nicht zu empfehlen, da solche Strukturelemente vom Screenreader im Formularmodus ignoriert werden.

Es muss also eine Lösung gefunden werden, die in den gebräuchlichen grafischen Browsern ein adäquates Layout ermöglicht und trotzdem nicht die Bedienung der Formulare mit alternativen Zugangsmethoden verhindert.

Logische Verknüpfungen: Warum Tabellen wunderbar geeignet für Formulare sind

Anders gelagert ist der Fall unter Umständen bei Web-basierten Anwendungen. Tabellarische Übersichten in Content Management-Systemen sind natürlich mit Tabellen zu strukturieren, da es sich um tabellarische Daten handelt, wenn auch als Mischform mit Formularen z. B. für die eigentlichen Editierfunktionen. Eine ganz einfache Regel: wenn man die Inhalte anhand der Kriterien in den Spalten- oder Zeilenköpfen sortieren kann, dann ist eine Datentabelle angebracht:

Auch Browser-basierte Tabellenkalkulationen wie Google Spreadsheets oder jede andere Form der Eingabe und Manipulation komplexer Daten sind genau das: Tabellen. Hierfür sind die Tabellenelemente aus HTML nach wie vor hervorragend geeignet und somit die naheliegende Technik zu ihrer Umsetzung. Allerdings gilt auch hier ganz besonders der Zwang zur Linearisierbarkeit, wenn diese Tabellen- und Formulargemische auch in nicht-visuellen Ausgabeformen nutzbar bleiben sollen. Wenn Sie die Inhalte von ihrem Codegerüst befreien, dann müssen sie in genau dieser Reihenfolge immer noch einen Sinn ergeben, denn genau so kommen sie aus dem Lautsprecher.

Allerdings helfen hier die Elemente und Attribute zur Strukturierung, die zwar in Layout-Tabellen unerwünscht sind, in komplexen oder mehrdimensionalen Datentabellen jedoch eine effektive Nutzung erst ermöglichen. Wie diese einzusetzen sind können Sie in unserer BITV-Reloaded-Serie unter Anforderung 5 nachlesen.

Formulardesign

Gutes Design ist mehr als nur eine bunte Verpackung. Ein gutes Design nimmt sich selbst zurück und unterstützt den Nutzer in der Bewältigung der Aufgabe. Niemand käme auf die Idee, Formularen einen hohen Spaßfaktor zu bescheinigen, aber gerade weil niemand gerne Formulare ausfüllt ist ein gutes Design unumgänglich wenn sie benutzt werden sollen.

Wobei – ein Formular muss nicht aussehen wie eine Einkommenssteuererklärung oder beschränkte Funktionen haben wie ein Kontaktformular. Ohne Formulare gäbe es kein Mitmach-Web, denn Angebote wie flickr, Wikipedia oder Google Maps sind ohne die Funktionen von Formularelementen nicht denkbar. Wir wollen uns in dieser Serie jedoch auf die Umsetzung klassischer Formularanwendungen beschränken, zumal die Auswirkungen des Web 2.0 auf die barrierefreie Nutzung durch Menschen mit Behinderungen weitestgehend unerforschtes Neuland ist.

Auch bei herkömmlichen Formularen bestehen eine ganze Reihe Barrieren für Menschen mit Behinderungen: unnötige oder übermäßige Eingaben oder die mehrfache Abfrage von bereits vorliegenden Daten sind für Nutzer mit motorischer Behinderung nicht nur lästig, sondern eine echte Hürde. Wenn sich ein Kunde Ihnen gegenüber z. B. schon mit seiner Kundennummer identifiziert hat, dann ist die erneute Abfrage von persönlichen Daten für diese Nutzer sehr zeitraubend; verbunden mit der Gefahr, dass in der Zwischenzeit die Session abläuft und der Benutzer wieder ganz von vorne anfangen muss.

Ein anderes Beispiel von Abfragen, die deutliche verschlankt werden könnten, fanden wir in der Musik-Community last.fm: obwohl man in einem vorhergehenden Auswahlfeld bereits seine Zeitzone (also MESZ oder GMT) eingestellt hat, stehen in der darauf folgenden Länderauswahl noch Länder und Kontinente, die von dieser Zeitzone aus gesehen auf der anderen Seite des Planeten liegen. Nutzern, die auf die Tastaturbedienung angewiesen sind, aber dummerweise in einem Land wohnen, dessen Anfangsbuchstabe im letzten Drittel des Alphabets ist, steht nun eine Odyssee durch eine ellenlange Liste bevor. Auch wenn geübte Nutzer kurzerhand den Anfangsbuchstaben drücken: steht Deutschland unter Germany, Bundesrepublik Deutschland oder Deutschland?

Für sehbehinderte Nutzer ist die Orientierung in komplexen Formularen ebenfalls von enormer Wichtigkeit. Diese Nutzer sind oftmals mit sehr individuellen Einstellungen im Netz unterwegs. Die Erfahrung aus den BIENE-Tests der vergangenen Jahre hat gezeigt, dass von der Standardkonfiguration abweichende Einstellungen wie veränderte Schriftgröße, eigene Farbeinstellungen etc. scheinbar in vielen Designs nicht berücksichtigt werden.

Nutzern mit kognitiven Behinderungen können Sie entgegen kommen, indem nicht nur das Formular selbst auf das Nötigste reduziert wird, sondern auch der Rest der Seite, in die das Formular eingebettet ist. Sie können nicht erwarten, dass der Nutzer irgendetwas anderes als das Formular auf der Seite wahrnimmt – dann können Sie unnötiges Beiwerk auch gleich ganz weglassen und damit eine kognitive Überfrachtung Ihrer Seite oder Anwendung vermeiden. Klar erkennbare Abläufe minimieren den Lernaufwand und helfen allen Nutzern.

Vor den filigranen Details der Formulargestaltung stehen also einige grundsätzliche Fragen, mit denen Sie bereits in der Konzeptions- und frühen Designphase viele spätere Probleme Ihrer Nutzer verhindern können. Je eher Sie sich diese Fragen stellen, desto weniger unterbrechen Sie das Erlebnis Ihrer Nutzer und desto besser verhindern Sie eine hohe Abbrecherquote in Ihren Formularprozessen.

• Sind alle Abfragen wirklich nötig? Warum stellen Sie diese Fragen?
• Ist die Abfrage zum jetzigen Zeitpunkt überhaupt angebracht?
• Sind die abgefragten Daten nicht schon längst vorhanden? Gibt es andere Wege, um an die Daten zu kommen? Muss der Nutzer hier Ihre Arbeit machen?
• Können Sie optionale Fragen ausblendbar machen? Sind wirklich alle Abfragen zwingend notwendig oder kann man diese auch weglassen? Beispiel: Wenn Rechnungs- und Versandadresse gleich sind sollten sie den Nutzer nicht zwingen, beides auszufüllen.

Wenn Sie die Komplexität auf das Notwendige reduziert haben, geht es nun an die Oberfläche. Optische Gruppierungen sollten die strukturellen Gruppierungen unterstützen, die wir in Folge 1 dieser Serie besprochen haben. Mit Überschriften bzw. Legenden, Farben und Formen können Sie Bereiche des Formulars gruppieren, die dann vom Besucher nacheinander abgearbeitet werden. So können Sie unerfahrenen Benutzern die einzelnen Schritte nacheinander präsentieren und diese mit erklärenden Texten unterbrechen.

Wohin mit den Labels?

Schon solche scheinbar nebensächlichen Dinge wie die Positionierung der Labels genannten Beschriftungen der Kontroll- und Eingabeelemente hat große Auswirkungen auf die Gebrauchstauglichkeit (neudeutsch: Usability) ihres Angebotes. Für welche Anordnung Sie sich letztendlich entscheiden sollten hängt von vielen Faktoren ab, die so einmalig und individuell für jedes Web-Angebot sind, dass wir hier beim besten Willen keine eindeutige Empfehlung geben können. Im Folgenden finden Sie aber eine Reihe von Pros und Contras, die Sie mit in Ihre Entscheidungsfindung einfließen lassen können.

Sie sollten bei der Platzierung der Labels jedoch die ›Human Interface Guidelines‹ der verbreiteten Betriebssysteme berücksichtigen, die sich bei allen Differenzen in diesen Punkten einig sind:

• Labels von Textfeldern und Auswahlfeldern stehen grundsätzlich links neben oder über dem Feld
• Labels von Radiobuttons und Checkboxen stehen grundsätzlich rechts neben den Kontrollelementen

Variante 1: Labels seitlich, linksbündig ausgerichtet

• Die Texte der Labels sind hier wegen der linksbündigen Ausrichtung einfach zu erfassen, die Gestaltung wirkt jedoch wegen der zusätzlichen Achse unruhiger.
• Diese Variante ist am besten geeignet für Formulare, wo die einzugebenden Daten ungewohnt sind und die Nutzer quasi gezwungen werden sollen, sich mit den Labels zu beschäftigen.
• Für diese Form des Formular-Layouts brauchen Sie eine extrem stabile CSS-float-Umgebung wie z. B. YAML oder YUI Grids. Durch die zahlreichen Bugs bei der CSS-Positionierung per float in den verbreiteten Browsern ist diese Methode am schwierigsten umzusetzen
• Ein weiterer Nachteil ist die schlechte Internationalisierbarkeit (i18n). Bei längeren Labels und/oder vergrößertem Text kommt es schnell zu unerwünschten Umbrüchen und dadurch zu Verschiebungen sämtlicher Elemente.
• Ein Vorteil: diese Variante benötigt weniger vertikalen Platz und kommt dem Trend entgegen, dass Monitore immer breiter werden (16:9 statt 3:4).
• Nachteil: Wegen der bei kurzen Label-Texten entstehenden großen Lücken kommt es zu einer schlechteren visuellen Assoziation der Labels mit ihren Feldern, wie im folgenden Bild zu sehen ist:

Im nächsten Bild sehen Sie ein Designbeispiel mit gestreiften Label/Control-Paaren, das diese Assoziation zwar wieder herstellt, durch die enormen Abstände jedoch weiterhin sehr ermüdend für das Auge des Nutzers ist:

Variante 2: Labels seitlich, rechtsbündig ausgerichtet

• Diese Variante bringt eine klare Verknüpfung von Label und dazugehörigem Feld durch die Nähe zueinander. Dadurch entsteht ein relativ geringer Zeitaufwand zur Orientierung und zum Ausfüllen.
• Sie benötigt weniger vertikalen, dafür mehr horizontalen Platz – problematisch wird dies bei mehrspaltigen Formularen (fieldset neben fieldset).
• Wie schon in Beispiel 1 ist dies die bei weitem schwierigste Form der Umsetzung in CSS.
• Die Label-Texte sind schwieriger zu scannen weil sie links ›flattern‹. Durch die Orientierung an der Mittelachse gibt es keinen einheitlichen Zeilenanfang, Optik und Umbrüche sind hier ebenso wenig kontrollierbar.
• Problematisch im Sinne der Barrierefreiheit ist diese Variante für stark sehbehinderte Nutzer mit einem brauchbaren Sehrest, die sich mittels Lupenprogrammen visuell orientieren. Bei den teils enormen Vergrößerungsfaktoren kann es in diesem Beispiel dazu kommen, dass der Nutzer unter der Legende (hier: »Überschrift«) lediglich einen großen weißen Bereich wahrnimmt und Schwierigkeiten haben wird, das erste Formularfeld zu finden.

Variante 3: Labels oben, linksbündig ausgerichtet

• Diese Variante bringt eine klare und eindeutige Verknüpfung von Label und Feld. Sie eignet sich nach unserer Erfahrung besonders für Abfragen mit geringer Komplexität, wenn die erhobenen Daten dem Nutzer vertraut sind. Die sind zum Beispiel einfache Formulare mit der üblichen Kombination aus Vorname, Nachname, E-Mail, PLZ, Ort, etc.
• In sämtlichen uns bekannten Untersuchungen schneidet diese Version am besten ab, wenn es um den minimalen Zeitaufwand zum Ausfüllen geht.
• Sie benötigt allerdings mehr vertikalen Platz
• Ausreichende Abstände und Kontraste sind hier besonders wichtig, um ein effizientes Scannen der Label-Texte zu ermöglichen.
• Diese Variante ist die flexibelste Lösung für Internationalisierungen und variierende Anordnungen, da sie den Labels sehr viel horizontalen Platz lässt und somit auch längere Text möglich sind:

Klick mich, ich bin ein Label

Mit ein wenig CSS können und sollten Sie Ihre Besucher informieren, dass man die Labels auch tatsächlich anklicken kann. Dies kann z. B. durch eine grafische Hervorhebung geschehen und durch eine Veränderung des Cursors beim Überfahren mit der Maus. Durch das folgende Beispiel verwandelt sich der Mauszeiger beim Überfahren des Labels in eine Hand mit Zeigefinger:

label, select, input[type=checkbox], input[type=radio], 
input[type=button], input[type=submit] {
 cursor: pointer;
}

Falls Sie ein IE-spezifisches Style Sheet benutzen sollten Sie an dieser Stelle noch die Angabe cursor:hand deklarieren, da der Internet Explorer die W3C-konforme Variante nicht versteht.

Eingabefelder vom Typ Text (<input type="text"> bzw. <textarea>) benötigen hingegen keine Sonderbehandlung im CSS, obwohl dies mit dem Selektor input[type=text] möglich wäre – sämtliche uns bekannten Browser stellen hier von ganz alleine eine Einfügemarke als Cursor dar.

Tipp: Wenn sie in Ihren Formularen Buttons vom Typ input type="submit" benutzen, dann sollten Sie im CSS nie ausschließlich den Selektor input stylen, sonst sehen Ihre Absenden-Buttons nachher aus wie Textfelder. Stattdessen sollten Sie Selektoren wie input[type=text] verwenden (die allerdings der Internet Explorer nicht versteht) oder den Eingabeelementen Klassen zuweisen und diese per CSS formatieren. Die eleganteste Lösung ist jedoch, das BUTTON-Element zu benutzen.

Die Labels und die Kontroll- bzw. Eingabefelder werden in den gängigen Browsern durch eine Outline hervorgehoben, sobald sie mit der Tabulatortaste erreicht werden. Begehen Sie jedoch nicht den Fehler und nehmen diesen Fokus per JavaScript wieder weg, wie viele Standard-Installationen des Open-Source-CMS Typo3 dies tun. Solche Formulare sind leider per Tastatur oder mit anderen alternativen Zeige- und Eingabegeräten nicht mehr zu bearbeiten.

Deutlicher Fokus bei Maus- und Tastaturnavigation

Mit CSS lässt sich die Gestaltung der Formularelemente auch ohne den Einsatz von JavaScript (onblur bzw. onfocus) verändern. So können Sie zum Beispiel die Hintergrund- oder Rahmenfarbe von Textfeldern ändern, sobald diese aktiviert sind. Damit teilen Sie Ihrem Benutzer deutlich mit, in welchem Abschnitt des Formulars er sich zur Zeit befindet und welche Eingabe als nächstes erwartet wird. Hierzu müssen Sie zunächst die Hintergrundfarbe der Textfelder definieren:

input, textarea {
 background: #ddd;
}

Als nächstes werden die Textfelder beim Erreichen des Fokus (d. h. durch das Setzen der Einfügemarke per Tabulator oder Maus oder durch Anklicken des verknüpften Labels) farblich hervorgehoben:

input:focus, textarea:focus {
 color: #000;
 background: #fff;
 outline: 1px solid red;
}

In Formularen wird generell, also auch von Nutzern ohne motorische Behinderung oder Sehbehinderung, öfter per Tastatur navigiert, weil der Nutzer in der Regel schon beide Hände auf der Tastatur hat und der Griff zur Maus eine Unterbrechung darstellen würde. Daher ist hier die geräteunabhängige Bedienbarkeit noch wichtiger als bei reinen Textseiten ohne Formulare. Problematisch ist dies besonders bei mehrspaltigen Formularen: hier sollten Sie unbedingt auf eine Abfolge der Felder und Fieldsets im Quelltext achten, die dem optischen Ablauf des Formulars unter allen Umständen entsprechen muss.

Konventionen für Labels

Die meisten modernen Web-Browser bieten mittlerweile die Funktion, immer wiederkehrende Eingaben wie Vor- und Nachname, Adresse etc. zu speichern oder greifen auf das lokale Adressbuch des Nutzers zu. So kann der Nutzer dann per Knopfdruck entsprechende Felder automatisch ausfüllen lassen und erspart sich damit immer wiederkehrende Eingaben – für Nutzer mit motorischer Behinderung eine große Hilfe.

Das ganze funktioniert aber nur dann, wenn sich das Formular, bzw. ganz konkret die Label-Texte an bestimmte Konventionen halten. Daher sollten Sie die Labels so texten, wie die entsprechenden Adressbüchern wie z. B. Outlook und ähnliche heissen. Bewährt hat sich bei Adressen die Aufteilung in Vorname, Nachname, Firma, Straße, Hausnummer, Postleitzahl (bzw. PLZ), Ort (bzw. Stadt) und Land. Wenn Sie statt E-Mail email oder Elektropost als Labeltext benutzen, dann mag das vielleicht witzig sein, aber kein Browser wird dieses Feld korrekt ausfüllen können.

Für die Schreibweisen und die Reihenfolge von Adressangaben gibt es sogar eine DIN-Norm (DIN 5008) – so kommt die Postleitzahl grundsätzlich vor dem Ort. Gerade eingedeutschte Anwendungen aus dem englischen oder amerikanischen Raum entsprechen oftmals nicht den Konventionen und damit der Erwartungshaltung der Nutzer und platzieren diese hinter dem Ort.

Konventionen für Pflichtfelder

Die Frage, ob optionale Felder oder Pflichtfelder gekennzeichnet werden sollten, lässt sich mit einer einfachen Regel beantworten: immer die mit der geringsten Anzahl. Wenn Sie überwiegend Pflichtfelder haben, sollten Sie die wenigen optionalen Felder kennzeichnen. Umgekehrt gilt das gleiche: bei einer Vielzahl von Feldern oder bei komplexen Formularen, in denen aber nur wenige Pflichtfelder sind, ist eine Kennzeichnung der Pflichtfelder vorzuziehen. So verhindern Sie visuellem Lärm, überfrachten Ihr Formular nicht mit vielen einzelnen Informationen, und die Inhalte werden dadurch für den Nutzer einfacher zu scannen.

Keine der Varianten ist sinnvoll, wenn alle Felder Pflichtfelder sind. Dies sollten Sie zu Beginn des Formulars erwähnen; auf keinen Fall erst am Ende des Formulars oder sogar nach dem Submit. Einen umgekehrten Fall gibt es hier nicht – zumindest ist uns bisher noch kein Formular untergekommen, in dem sämtliche Felder optional sind.

Zur Erklärung, dass Pflichtfelder enthalten sind, die zwingend ausgefüllt werden müssen, gehört die Erklärung, wie diese gekennzeichnet sind. Die hierfür häufig verwendeten Asterisken (*) haben das Problem, dass diese im Screenreader je nach Einstellungen des Nutzers als Interpunktionszeichen behandelt und nicht vorgelesen werden. Um auf der sicheren Seite zu sein benutzen wir hier bei Einfach für Alle Grafiken mit einem Sternchen, in denen der alt-Text "Pflichtfeld" hinterlegt ist. Alternativ können Sie das Sternchen auch mit einem title-Attribut ausstatten:

Die Kennzeichnung der Pflichtfelder sollte auf jeden Fall mit den Labels verknüpft sein bzw. innerhalb des label-Tags stehen.

Konventionen für Buttons

Auch für Buttons gibt es gewisse Konventionen, an denen sich Ihr Formulardesign orientieren sollte. Die wichtigste: die primäre Aktion, also in den meisten Fällen wohl »Speichern« oder »Abschicken« steht immer als erstes – sie sind direkt verantwortlich für die Fertigstellung des Vorgangs und die Präsentation sollte ihrer Wichtigkeit entsprechen. Sekundäre Aktionen wie »Abbrechen«, »Löschen« und »Zurück« sind nur selten sinnvoll – wenn Sie diese einsetzten, dann sollte die optische Gewichtung ihrer Funktion entsprechen, wie dies generell in Anwendungen jenseits des Browsers der Fall ist:

Formularlayout mit CSS - Alles im Fluss

Viele große Websites, die in letzter Zeit neu und ohne Layout-Tabellen gestaltet wurden, bedienen sich der float-Eigenschaften des Box-Modells von CSS 2. Bekannte CSS-Frameworks wie YAML bauen ebenfalls auf diesen Methoden auf und erreichen damit höchst flexible Layouts. Das Box-Modell beschreibt die Eigenschaften von CSS, beliebige Inhalts-»Behälter« (Boxen) einer HTML-Seite zu formatieren. Hiermit können Sie Inhaltsblöcke, die im rohen HTML nacheinander stehen würden, in der grafischen Darstellung nebeneinander positionieren. So lassen sich mit nur wenigen Zeilen Code komplexe mehrspaltige Layouts umsetzen, wie Sie an den ›Einfach für Alle‹-Seiten sehen können.

Eine detailliertere, dafür aber auch sehr technische Beschreibung der Box- und Float-Modelle finden Sie in der CSS 2.1-Spezifikation des W3C, daher hier nur soviel: wenn Sie eine Box per float: positionieren, so wird diese aus dem »Fluss« des Dokumentes herausgenommen und kann nun durch die Angabe float: right; oder float: left; beliebig rechts oder links neben einer darauf folgenden Box positioniert werden. Die Nachbar-Boxen umfließen nun diese Box.

Genau diese Eigenschaften können Sie ausnutzen, um in Formularen die Labels vollkommen tabellenfrei neben den dazu gehörigen Kontrollelementen zu positionieren. Die einzige Schwierigkeit besteht nur darin, dass die Labels einiger Kontrollelemente wie Textfelder oder Auswahlmenüs üblicherweise vor dem Element (also links daneben oder darüber) stehen; bei anderen Kontrollelementen wie Radiobuttons und Checkboxen stehen diese nach dem Element (d. h. rechts daneben). Sie sollten sich in Ihren Formularen unbedingt an diese Konvention halten, da dies die erwartete Position ist, die den Gewohnheiten des Nutzers in allen Betriebssystemen entspricht.

Ein Beispielformular

Erst mal das HTML

Das folgende Formular enthält die gängigen Elemente zur Eingabe von Text und zur Auswahl von Optionen. Als Vorbereitung auf die Formatierung per CSS wurden bereits einige Klassenangaben eingefügt. Alle Elemente, bei denen das Label links vom Kontrollelement steht, bekommen die Klasse "left", alle Elemente, bei denen das Label rechts daneben steht, bekommen die Klasse "right" :

<form action="foo">
 <fieldset>
 <legend>Beispielformular</legend>

 <label for="textfeld" class="left">Text:</label>
 <input type="text" id="textfeld" name="textfeld" size="12"><br>

 <label for="auswahl" class="left">Auswahl:</label>
 <select id="auswahl">
 <option value="auswahl1">Auswahl 1</option>
 <option value="auswahl2">Auswahl 2</option>
 </select><br>

 <input type="radio" id="radio1" name="radio" value="entweder" class="right">
 <label for="radio1">Entweder</label><br>

 <input type="radio" id="radio2" name="radio" value="oder" class="right">
 <label for="radio2">Oder</label><br>

 <input type="checkbox" id="check1" value="sowohl" class="right">
 <label for="check1">Sowohl</label><br>

 <input type="checkbox" id="check2" value="alsauch" class="right">
 <label for="check2">Als auch</label><br>

 <button type="submit" class="right">Bestellen</button>

 </fieldset>
</form>

Das gerenderte Ergebnis zeigt ein Formular ohne jegliche Formatierung, aber in einer für nicht-grafische Darstellungsformen optimal verarbeitbaren Form:

Dann das CSS

Im nächsten Schritt wird das Style Sheet erstellt, um die Labels und Kontrollelemente zu positionieren. Zunächst werden die Labels mit der Klasse "left" mit einer Breite versehen und rechtsbündig an eine imaginäre Mittelachse gebracht. Über margin-right wird der Abstand der Labels zu den daneben stehenden Kontrollelementen definiert:

.left {
 float: left;
 text-align: right;
 width: 40%;
 margin-right: 2%;
}

Dann kommen die Radiobuttons und Checkboxen an die Reihe, die im HTML bereits mit der Klasse "right" versehen wurden. Der Abstand ergibt sich hier aus der Breite der Textlabels für die vorhergehenden Textfelder (40%) plus dem Abstand dieser Labels zu ihren Kontrollelementen (2%). Hieraus ergibt sich für die folgenden Kontrollelemente inklusive des »Absenden«-Buttons ein linker Abstand von 40%+2%=42%, um sich an besagter Mittelachse auszurichten:

.right, button {
 margin-left : 42%;
}

Das war's auch schon – mit ein paar Zeilen Code haben sie nun potentiell sämtliche Formulare Ihrer Website formatiert. Das Ergebnis sehen Sie in den folgenden Screenshots:

Luxuriöse Buttons

In den vorherigen Beispielen haben wir zum Absenden des Formulars <button>-Tags benutzt. In der unformatierten Variante sind diese relativ hässlich und erinnern auch in modernen Browsern stark an die Zeiten von Windows 3.11. Vielleicht ist dies der Grund, warum Designer und Coder oftmals Buttons vom Typ <input type="submit"> benutzen, sich dann über dessen mangelhafte Anpassbarkeit ärgern und letztendlich doch wieder auf <input type="image"> zurückgreifen.

Wesentlich flexibler ist man mit dem BUTTON-Element, da dieses nicht nur sehr individuell gestaltbar ist, sondern auch noch so gut wie alle anderen HTML-Elemente enthalten darf. Die Buttons selbst können zum Beispiel in einer Auflistung stehen, und selbst auch Block-Level-Elemente wie H1-H6 oder P und selbstverständlich auch Inline-Elemente oder Grafiken mit Alternativtext enthalten:

<fieldset>
 <legend>Bitte wählen Sie:</legend>
  <ol>
   <li>
	<button type="submit" name="karte" value="sued">
	 <h3>Südkurve</h3>
	 <p><strong>10 &euro;</strong></p>
	 <p>(Stehplatz)</p>
	</button>
   </li>
   <li>
	<button type="submit" name="karte" value="nord">
	 <h3>Nordkurve</h3>
	 <p><strong>20 &euro;</strong></p>
	 <p>(Sitzplatz)</p>
	</button>
   </li>
   <li>
	<button type="submit" name="karte" value="ost">
	 <h3>Osttribüne</h3>
	 <p><strong>30 &euro;</strong></p>
	 <p>(Sitzplatz)</p>
	 </button>
	</li>
	<li>
	 <button type="submit" name="karte" value="west">
	 <h3>Westtribüne</h3>
	 <p><strong>50 &euro;</strong></p>
	 <p>(VIP-Loge)</p>
	 </button>
	</li>
   </ol>
</fieldset>

Mit ein wenig CSS können Sie aus diesen gänzlich unattraktiven Buttons nun das Folgende zaubern:

Gestalterische Hilfen für sehbehinderte Nutzer

Viele sehbehinderte Nutzer sind mit sehr individuellen Einstellungen ihres Rechners und des Browsers im Netz unterwegs. Dazu gehören stark vergrößerte, aber auch verkleinerte Schriften und individuelle Farbeinstellungen, um die bei einigen Formen der Sehbehinderung auftretenden Blendeffekte zu mildern.

Hierfür bieten sämtliche Betriebssysteme eigene Einstellungsmöglichkeiten. Bei Linux-Desktops und unter Windows werden eine ganze Reihe sogenannter Kontrastschemata mitgeliefert, die radikal den gesamten Bildschirminhalt verändern. Verbreitet ist die invertierte Darstellung z. B. mit gelbem Text auf schwarzem Hintergrund (unter Windows zu finden in den Systemeinstellungen als »Kontrast #1«). Unter Mac OS X hingegen kann entweder der gesamte Bildschirm in Graustufen oder invertiert (vergleichbar einem Foto-Negativ) dargestellt werden; der Bildschirm-Kontrast kann zudem systemweit mit einem Schieberegler sehr genau an die jeweiligen Bedürfnisse angepasst werden.

Problematisch werden solche Einstellungen für den Nutzer dann, wenn wie im Falle der Windows-Kontrastschemata sämtliche optischen Hilfen verschwinden, die der Designer eingebaut hat. Das System bzw. der Browser ignorieren in diesem Fall sämtliche Hintergrundfarben (im konkreten Anwendungsfall also zum Beispiel in Fieldsets oder die in unseren Designbeispielen zu sehenden gestreiften Hintergründe) und stellen stattdessen überall die vom Nutzer eingestellte Hintergrundfarbe dar. Ihre mühsam gestalteten optischen Hilfen sind für diese Nutzer also unsichtbar.

Aber es gibt einen Ausweg: Windows entfernt zwar alle Hintergrund-Farben (in CSS: background-color), nicht jedoch die Ränder (wie z. B. border: 2px solid #000;). Diese Tatsache kann man nutzen und seinen Farbflächen einen kleinen Rand in der gleichen Farbe geben – diese Ränder können dann für sehbehinderte Nutzer eine wertvolle Orientierungshilfe geben und fallen dem normalsichtigen Nutzer nicht weiter auf.

Weitere Informationen zu diesem Thema finden Sie im Artikel »Image Replacement-Techniken nicht zugänglich für Sehbehinderte« und in der BITV Reloaded-Serie bei Anforderung 2 »Verständlichkeit ohne Farbe«.

Formulare zum Ausdrucken

Ein leider viel zu wenig beachtetes Anwendungsszenario von Web-basierten Formulare ist der Ausdruck. Nutzer wollen vielleicht ihre gemachten Eingaben ausdrucken und archivieren, oder das leere Formular von Hand ausfüllen. Mit ein wenige CSS können Sie Ihr Formular so aufbereiten, dass es auch im Ausdruck eine gute Figur macht, ohne dass Sie dafür den HTML-Code anfassen müssen.

Dazu müssen Sie nur Ihr Print-Style-Sheet (Sie haben doch ein Print-Style-Sheet, oder?) um ein paar Dinge erweitern. Hier sollten Sie den Kontrollelementen ein Aussehen mitgeben, das für den Ausdruck geeigneter ist als die gewohnten Kontroll-, Eingabe- und Auswahlelemente im Web-Browser. Bei Textfeldern ist dies ausgesprochen simpel: statt der üblichen Pseudo-3D-Border definiert man im CSS kurzerhand:

textarea, input[type=text] {
 border:none;
 border-bottom: 2px #000 dashed;
}

Im Ausdruck ergibt dies:

Label: _____________________________________

Bei anderen Formularelementen wie Radiobuttons oder Checkboxen ist dies nicht ganz so einfach, alleine schon weil man in CSS keine runden Formen definieren kann, die für Radiobutton nötig wären. Sie können diese allerdings simulieren, indem Sie die Kontrollelemente per Image Replacement durch eine entsprechende Grafik ersetzen. Ein weiterer Ansatz wäre, die Elemente per CSS auszublenden und per Generated Content durch Sonderzeichen wie zum Beispiel das Ballot Box-Zeichen aus Zapf Dingbats (Beispiele: ⊗ ⊠ ❏ ☐ ☒ – ⊗ ⊠ ❏ ☐ ☒) zu ersetzen. Diese werden zwar, wie viele Unicode-Zeichen auch, im Screenreader nicht vorgelesen – allerdings ist es auch ausgesprochen unwahrscheinlich, dass sich ein vollblinder Screenreader-Nutzer ein für den Ausdruck vorgesehenes Formular vorlesen lässt.

Fehlertoleranz in Formularen

Gerade bei Formularen oder Web-basierten Anwendungen gilt das alte Netz-Mantra, dass man strikt in dem sein sollte, was man ausliefert, und tolerant bei dem, was man akzeptiert. Diese Fehlertoleranz gegenüber dem Nutzer ist leider viel zu selten zu beobachten. Dabei würden einige kurze Tests mit echten Nutzern aufzeigen, was diese falsch machen können und Hinweise geben, wie man diese Fehler als Anbieter am besten abfängt.

Ein Beispiel für mangelnde Fehlertoleranz ist der Zwang, Eingaben so zu tätigen, wie es der Anbieter gerne hätte. Die dahinter stehenden Anforderungen oder Konventionen müssen dem Nutzer jedoch nicht unbedingt bekannt sein. So sollten Sie bei Eingabefeldern für Telefonnummern lediglich ein Feld anbieten und in diesem alle Schreibweisen akzeptieren, statt es auf zwei (Vorwahl/Durchwahl) oder sogar drei (mit Ländervorwahl) aufzuteilen. Unterschiedliche Eingaben (+49 - 12 34 - 56 78 90 oder 01234567890) können Sie auch serverseitig auflösen. Gleiches gilt für alle anderen Zahlen- oder Textfelder, in die der Nutzer freie Eingaben machen kann, wie Kreditkartennummern, Datumsangaben etc. Auch hier sollten Sie Eingaben mit und ohne Leerschritte oder Zeichen wie / für die Trennung in Telefonnummern akzeptieren.

Eine Aufteilung in mehrere Felder ist in der Regel nicht barrierefrei zu nutzen, da z. B. ein Label immer nur für ein einziges Formularelement definiert werden kann und somit eine logische Verknüpfung mit weiteren Feldern nicht möglich ist. Besonders für blinde Nutzer ist dies ein Problem – sie werden versuchen, die kompletten Daten im ersten Feld einzugeben und regelmäßig an dieser Stelle scheitern. Bei kalendarischen Daten hat sich mittlerweile durchgesetzt, zusätzlich zu den Eingabe- oder Auswahlfelder für Tag/Monat/Jahr auch noch einen echten Kalender in Form einer Tabelle anzubieten. Dies hat den Vorteil, dass hiermit in einem einzigen Kontrollelement umfassendere Daten (Kalendertage, Kalenderwochen, Wochenenden etc.) angezeigt werden können, womit man dem Nutzer eine Menge Denkarbeit abnimmt.

Sie sollten dem Nutzer bereits vor der Eingabe erklären, was zulässige Eingaben sind und diese Eingaben natürlich in einem zweiten Schritt validieren. Bei einer natürlichen, in der Art der Sache liegenden Begrenzung der Eingabe (z. B. maximal 160 Zeichen bei einem Online-SMS-Versand) können und sollten Sie sogar einen Zähler anbieten, der die verbleibenden Anschläge anzeigt. Generell gilt die Regel bei solchen Begrenzungen: was im maxlength-Attribut steht sollte auch nochmal im Klartext daneben stehen (idealerweise im Label des betreffenden Feldes).

Wenn Sie die Länge von Eingaben begrenzen, dann sollten sich Ihr HTML-Code auch daran halten und nicht stattdessen Fehler provozieren. Uns sind schon einige Passwort-Felder untergekommen bei denen zwar daneben stand, dass ein Passwort nur 16 Zeichen lang sein darf, die dann aber zunächst doch die Eingabe von mehr als 16 Zeichen zuließen, nur um danach eine entsprechende Fehlermeldung auszugeben.

Um beim obigen Kalender-Beispiel zu bleiben: hier kann es sinnvoll sein, nicht mehr wählbare (weil z. B. in der Vergangenheit liegende) Daten kurzerhand nicht mehr anzuzeigen oder zumindest optisch und technisch zu deaktivieren. Wenn in einem Produkt-Konfigurator bestimmte Optionen nicht miteinander kombinierbar sind, dann sollten Sie den Nutzer nicht dahin führen, diese »Fehl«-Konfiguration zu tätigen, nur um ihm hinterher eine Fehlermeldung zu präsentieren. Was nicht geht hat im Formular oder in der Anwendung nichts zu suchen.

Nicht so eilig!

Für Nutzer mit kognitiven Behinderungen stellen Zeitbegrenzungen und ablaufende Sessions ein echte Hürde dar; diese Nutzer haben oftmals nicht die nötige Ausdauer, um komplizierte Abläufe an einem Stück abzuarbeiten. Bei komplexen oder mehrstufigen Formularen sollten Sie daher dem Nutzer die Möglichkeit geben, den Prozess zu unterbrechen, Zwischenstände zu speichern und zu einem späteren Zeitpunkt wieder aufzunehmen. Da es sich bei diesen typischerweise um Anwendungen handelt, bei denen der Nutzer einen Account hat und somit identifizierbar ist, sollte eine Nachverfolgung kein Problem darstellen.

Zum Abschluss sollten Sie dem Nutzer die Möglichkeit geben, seine Eingaben zu kontrollieren. Insbesondere bei Vorgängen mit erheblicher Tragweite sollte erst danach die eigentliche Übernahme der Formulardaten auf den Server geschehen, um den Vorgang abzuschliessen. Bei Änderungen an vorhandenen Datensätzen sollten Sie die nun manipulierte Ursprungsseite nochmals anzeigen, evtl. mit optischen Indikatoren und/oder einer textlichen Zusammenfassung der Änderungen.

Fehlerbehandlung in Formularen

Dass Sie Ihre Nutzer über Fehler informieren sollten versteht sich von selbst. Wie Sie Ihre Nutzer über Fehler informieren ist hingegen eine Frage der Philosophie und des Kontextes innerhalb der Anwendung. Die einzige Regel, die immer und überall gilt: wenn etwas schief geht, dann sollten Sie den Nutzer möglichst schnell und möglichst »laut« benachrichtigen.

Wann und in welcher Intensität dies geschieht ist Gegenstand langer Debatten unter Webdesignern und spiegelt die unterschiedlichen Ansätze der verschiedenen Betriebssysteme wieder. Typische Windows-Anwendungen konfrontieren den Nutzer eher mit zu vielen Meldungen (»Es ist nichts passiert. Bitte drücken Sie OK, um keine Änderungen zu bestätigen«), unixoide Betriebssysteme hingegen sagen nichts, wenn nichts passiert ist (geben also in der Regel auch keine Bestätigungen, wenn ein Vorgang ohne Fehler abgelaufen ist).

Die beste Lösung ist wohl, wie so oft, der goldene Mittelweg zwischen »Zu viel« und »Zu wenig« – wo dieser liegt müssen Sie im Kontext Ihrer Anwendung selbst herausfinden und durch Nutzertests verifizieren. Ein typisches Beispiel von »Zu viel«, das leider viel zu oft im Netz zu finden ist sehen Sie im folgenden Screenshot:

Das Problem bei dieser Fehlermeldung ist, dass der Nutzer den Alert nur per OK wegklicken kann, dann aber nicht zu den fehlerhaften Stellen geführt wird. Wenn Ihr Formular nur aus einer geringen Anzahl Felder besteht und somit die Fehleingaben überschaubar sind, sollten Sie den Nutzer besser einzeln auf die Fehler hinweisen, wie der folgende Screenshot zeigt:

Per JavaScript (z. B. document.forms["bestellung"].name.select();) wird dann beim Bestätigen des Alerts per OK-Button der Fokus direkt auf das jeweilige Eingabefeld gesetzt.

Allerdings hat auch diese Methode ihre Grenzen: ab einer gewissen Anzahl Felder (und damit potenzieller Fehler) erscheint es sinnvoller, diese dem Nutzer nicht als endlose Folge von einzelnen Alerts zu präsentieren, sondern sie als Auflistung im Formular selbst anzuzeigen:

<form id="bestellung">
[…]

<h4>Fehler!</h4>
<p>Folgende Felder müssen ausgefüllt werden, um Ihre Bestellung abzuschließen:</p>
<ol>
 <li><a href="#label-vorname">Bitte geben Sie Ihren Vornamen ein</a></li>
 <li><a href="#label-nachname">Bitte geben Sie Ihren Nachnamen ein</a></li>
 <li><a href="#label-strasse">Bitte geben Sie Ihre Straße ein</a></li>
</ol>
[…]

<label for="vorname" id="label-vorname">Vorname:</label>
<input type="text" id="vorname">
[…]

Bei einem statischen Reload der Fehlerseite sollten Sie zusätzlich noch den TITLE der Seite sowie deren primäre Überschrift ändern. Bereits hier sollte der klare Hinweis stehen, dass es sich um eine geänderte Seite mit Hinweisen auf Fehler und nicht um die Bestätigungsseite handelt, da der Titel im Screenreader immer zuerst vorgelesen wird.

Hilfen in Formularen

Wahrnehmbare Hilfen

Selbst wenn Sie in ihren Formularen deutlich darauf hingewiesen haben, welche Felder Pflichtfelder sind, kann und wird es passieren, dass diese Hinweise übersehen werden. In diesem Fall sollten Ihre clientseitige und insbesondere auch die serverseitige Programmierung in der Lage sein, das Formular entsprechend verändert zurückzugeben und nur die fehlenden Eingaben erneut abzufragen.

Dazu gehört auch ein deutlicher Hinweis, welches die fehlerhaften Felder sind. Das kann in Form einer Hervorhebung durch Text, Form und Farbe geschehen. Sie sollten jedoch bedenken, dass ein einfaches Umfärben des Textes z. B. in die Signalfarbe Rot nicht ausreicht, da 8-10% aller Männer auf dieser Welt farbfehlsichtig sind und daher mit diesen vermeintlichen Hilfen nichts anfangen können.

Ebenso problematisch ist die Tatsache, dass verbreitete Screenreader nicht unbedingt immer alles vorlesen, was in einem Formular steht. Um die für die Bearbeitung von Formularen benötigten Tastaturkürzel bereitzustellen kennen manche Screenreader einen sogenannten Formularmodus. Dieser unterscheidet sich vom herkömmlichen Vorlesemodus dadurch, dass in Formularen nur noch die Inhalte der Formularelemente, ihrer Beschriftungen (<Label>) und Links (<a href="…) vorgelesen werden. Sämtliche anderen Inhalte wie P oder H4 werden ignoriert. Eine elegante Lösung für dieses »Problem«: wenn Ihr Formular ohne diese Texte Gefahr läuft, nicht verstanden zu werden, dann setzen Sie die benötigten Texte in Links und verknüpfen Sie diese mit der id des Labels.

Von diesem Verhalten sind tatsächlich sämtliche Inhalte betroffen, die nicht Formularelemente sind. Eine falsche Strukturierung kann dazu führen, dass vermeintliche Hilfen oder auch konkrete Fragen in einem Formular nicht wahrgenommen werden. So würde ein Screenreader-Programm im folgenden Beispiel lediglich die Label »Ja« und »Nein vorlesen – die eigentliche Frage bliebe dem Nutzer verborgen:

<form>
[…]

<p>Möchten Sie Sardellen auf Ihrer Pizza?</p>

<input type="radio" name="belag" id="ja" value="anchovis-ja" checked="checked"> 
<label for="ja">Ja</label>

<input type="radio" name="belag" id="nein" value="anchovis-nein"> 
<label for="nein">Nein</label>

Die Lösung, hier ein separates Fieldset einzuführen und die Frage als Legende zu hinterlegen würde ein mehr an Code und damit ein Mehr an Komplexität bedeuten, die an dieser Stelle unnötig ist. Die sinnvollere Lösung wäre, die Antwort auf die Frage nicht als Radiobuttons, sondern als Checkbox und die Frage als deren Label. Eine Checkbox erfüllt hier aufgrund des binären Charakters der Antwort (Haken = Ja, kein Haken = Nein) den selben Zweck wie zwei Radiobuttons.

Barrieren können auch durch die mangelhafte Kennzeichnung der Fehleingaben entstehen. Die Hinweise werden oftmals nicht in unmittelbaren Zusammenhang mit dem betreffenden Kontrollelement gezeigt, sondern weit entfernt davon und sind nicht sinnvoll verknüpft. Gerade bei nicht-grafischen Zugangsarten wird so eine Zuordnung schwierig und oft ist es einfacher die gesamte Prozedur von vorne zu beginnen, wenn die Fehlermeldungen nicht sinnvoll mit dem Ort des Fehlers verknüpft sind und diesen so anspringbar machen.

Verständliche Hilfen

Bei Formularen und insbesondere bei Anleitungen und Fehlermeldungen greifen die Regeln der BITV zum allgemeinen Verständnis und zur einfachen Sprache. Demnach sollten Fehlermeldungen wie die folgende eigentlich der Vergangenheit angehören:

Bedienbare Hilfen

Während die Vorgaben zur Verständlichkeit uneingeschränkt anwendbar sind, können Sie andere Regeln der BITV ruhig etwas liberaler auslegen: so darf man den Sinn des generellen Verbots von Pop-Ups in Web-Angeboten mit Anwendungscharakter gerne hinterfragen. Nach strikter Lesart würden hierunter auch Alerts fallen, die jedoch bei korrekter Umsetzung auch in assistiven Programmen gut nutzbar sind und geeignet sind, den Nutzer vor groben Fehlern zu bewahren. Ähnliches gilt für Hilfe-Funktionen innerhalb einer Anwendung oder eines komplexen Ablaufs. Hier kann es durchaus sinnvoll sein, diese in einem separaten (Pop-Up-) Fenster zu öffnen, damit der Nutzer im Bedarfsfall beides im direkten Zugriff hat. Auch diese stellen keine Barriere dar, sondern helfen dabei, welche zu beseitigen.

Dynamik in Formularen

Dynamische Inhalte, d. h. Inhalte, die sich mit oder ohne Einwirkung des Nutzers verändern, sind für viele Computer-Hilfsmittel ein echtes Problem. Bereits durch ein wenig mit Skripten angereicherten herkömmlichen Webseiten kommen Screenreader oder Lupenprogramme häufig aus dem Tritt, wenn sich Dinge innerhalb einer Seite ändern und diese Änderung nicht im unmittelbaren Fokus des Nutzers bzw. seiner Anwendung ist.

Diese Schwierigkeiten sind jedoch im Kern nicht auf die Änderung per Skript zurückzuführen: diese Anwendungen haben vergleichbare Probleme, wenn die Änderungen statisch, d. h. durch das Neuladen der Seite zustande gekommen sind. Das Problem ist also nicht die Dynamik im speziellen, sondern die Änderung im allgemeinen.

Bei Desktop-Anwendungen können sich Nutzer behelfen, indem sie Ihre Hilfsmittel sehr genau auf das Verhalten der häufig benutzten Anwendungen einstellen. Der verbreitete Screenreader JAWS bietet zum Beispiel die Möglichkeit, Anwendungen mit sogenannten JAWS Scripts zugänglich zu machen. Mittlerweile ist um dieses Prinzip herum ein ganzes Biotop von Anbietern entstanden, die solche Scripts für alle möglichen Anwendungen, von Office-Paketen bis zu Skype und iTunes, entwickeln und kostengünstig oder gratis ins Netz stellen.

Für Anwendungen, die im Webbrowser laufen gibt es diese Möglichkeiten (bisher) kaum. Hilfsmittel wie Screenreader, Lupenprogramme usw. sind in den letzten Jahren zwar stark verbessert worden und kommen eher mit Dynamik in Webseiten zurecht, als dies noch vor einigen Jahren der Fall war. Allerdings beziehen sich solche Aussagen immer nur auf die neuesten Versionen der Programme – man kann alleine wegen der teilweise erheblichen Kosten für Updates nicht davon ausgehen, dass mit dem Tag der Veröffentlichung einer neuen Version alle Nutzer sofort umsteigen und damit alle Probleme gelöst sind.

Daher gilt nach wie vor die dringende Empfehlung, zuerst eine vollkommen statische Variante zu entwickeln, bei der die gesamte Logik zunächst nur auf dem Server läuft und die nicht auf clientseitiges JavaScript zwingend angewiesen ist. Dieses kommt erst im zweiten Schritt zum Zuge.

JavaScript: vom Pfui-Wort zum Modetrend

Nachdem JavaScript lange Zeit verpönt war, hat diese clientseitige Skriptsprache in der letzten Zeit eine wahre Renaissance erlebt. Und zu Recht: richtig angewendet kann JavaScript gerade in komplexen Formularen oder Web-basierten Anwendungen den Nutzer unterstützen, Fehlbedienungen verhindern und ihm eine Menge Arbeit und Wartezeit abnehmen.

Mit JavaScript können Sie zum Beispiel Eingaben des Benutzers überprüfen, noch bevor dieser das Formular absendet und auf eine Antwort des Servers warten muss, von dem ein komplett neue Seite geladen wird. Mögliche Anwendungszwecke sind Trefferlisten oder Rechtschreibkorrekturen in Suchmaschinen und bei der Eingabe von Texten, Hinweise, dass bestimmte Kombinationen von Eingaben nicht möglich sind oder die sofortige Validierung von Eingaben mit hoher Fehlerquote. Bei einer Nutzerregistrierung können Sie Ihre Kunden schon während der Eingabe darauf hinweisen, dass ein gewünschter Benutzername bereits vergeben oder das gewählte Passwort zu unsicher ist und Vorschläge zur Korrektur machen.

All dies ist zwar auch ohne aktives Scripting möglich, dies bedeutet jedoch für den Nutzer eine längere Wartezeit und eine weniger unmittelbare Interaktion mit der Anwendung. Mit JavaScript können Sie hingegen Ihr Formular mit Komfortmerkmalen und unterstützenden Funktionen anreichern und so auf die Bedürfnisse von Nutzern mit kognitiven oder Lernbehinderungen reagieren.

Solche Skripte funktionieren jedoch nur, wenn mit der Zugangsart des Benutzers JavaScript tatsächlich ausführt werden kann. Für Fälle, in denen JavaScript ausgeschaltet ist oder nur unzureichend unterstützt wird hilft nur ein sogenanntes »Fallback« auf den Server, der identische Funktion übernimmt. Eine Verlagerung von Logik und Rechenleistung auf den Client sollten Sie daher immer erst dann vornehmen, wenn diese auch auf dem Server bereitgestellt wird.

Vom Schichtenmodell zur Wiener Melange

In den guten alten Zeiten des Webdesigns waren die Fronten klar und die Zuständigkeiten ordentlich verteilt: auf dem Server lief die Geschäftslogik, HTML sorgte für strukturierte Inhalte und Funktionen, CSS lieferte die Oberfläche und obendrauf konnte man mit JavaScript noch ein wenig optionalen Komfort mitgeben. Wenn man in diesem Schichtenmodell die Verhaltensschicht wegnimmt, hat man nach wie vor eine ansehnliche und funktionale Seite; nimmt man auch noch CSS weg, so bleibt das reine HTML der Seite – nicht mehr ganz so hübsch, aber funktionabel.

In Zeiten wo Web-basierte Applikationen Aufgaben übernehmen, die früher reinen Desktop-Anwendungen vorbehalten waren, lässt sich diese strikte Trennung nicht mehr länger durchsetzen. Während Angebote wie Google Mail noch eine statische Alternative bieten können, die (auf Kosten der Interaktivität) vollkommen ohne JavaScript auskommt, so ist dies bei der Browser-basierten Tabellenkalkulation (in Deutschland: Google Text & Tabellen) prinzipiell nicht mehr möglich.

Wie viele der sogenannten Web 2.0-Angebote beruhen auch diese auf Funktionalitäten, die sich nicht mehr serverseitig nachbilden lassen bzw. ohne JavaScript-Unterstützung nur derart umständlich zu bedienen wären, dass sie niemand nutzen könnte. Der Erfolg solcher Angebote hängt also unmittelbar davon ab, dass die Browser der Anwender sämtliche Web-Standards korrekt unterstützen – was im vorliegenden Fall ausdrücklich JavaScript mit einschließt.

So sollte man nicht mehr JavaScript pauschal für unzugänglich erklären; stattdessen ist die spannende Aufgabe nun herauszufinden, wie aktive und dynamische Inhalte mit den besonderen Bedürfnissen von Menschen mit Behinderung und den Fähigkeiten der Computer-Hilfsmittel in Einklang zu bringen sind. Auch hier hilft, so komisch das klingen mag, der Blick in die BITV – viele dieser Bedürfnisse erschliessen sich, wenn man die Hintergründe für die einzelnen Anforderungen und Bedingungen kennt.

Gängige Funktionen und typische Probleme

Betrachten wir mal einige typische Funktionen von Web-basierten Anwendungen:

• Inhalte werden dynamisch verändert, mit oder ohne Zutun des Nutzers und ohne dass die Seite bzw. Anwendung komplett neu vom Server geladen wird. Für Nutzer assistiver Programme wie Screenreader und Lupensoftware besteht hier das Problem, dass die Programme Änderungen im Browser unter Umständen nicht bemerken und den Nutzer weder informieren noch zu den Änderungen hinführen können.
  Auch für normalsichtige Nutzer können bei solchen Funktionen eines Web-Angebots Hürden entstehen. Zunächst müssen die geänderten Konzepte im Web2.0 verstanden werden – im Gegensatz zu statischen (Text-) Seiten verlangen Web-basierte Applikationen wesentlich umfassendere Fertigkeiten im Umgang mit Inhalten und Funktionen – für Nutzer mit Lernbehinderungen definitiv eine Barriere. Allerdings: eine statische Alternative scheidet oftmals aus grundsätzlichen Überlegungen aus – ein Börsenticker, der sich nicht selbsttätig aktualisiert ist ein Muster ohne Wert.
• Statische Inhalte werden erst durch Interaktion zu dynamischen Elementen. Ein Beispiel für diese Technik findet sich in der Foto-Community flickr: hochgeladene Bilder werden zunächst mit den Bezeichnungen abgelegt, mit denen die Digitalkamera die Bilder benannt hat (DSC_1234.jpg); flickr verwendet diese für die korrekt als Überschriften (<h2>) ausgezeichneten Titel der Bilder. Klickt man diese Überschriften mit der Maus an, so werden diese per Skript in ein Formular verändert. Hier kann man nun den Titel des Bildes ändern und diese Änderung speichern oder verwerfen:
  
  
  Das Problem bei dieser Form der Interaktion beginnt bereits mit der Tatsache, dass diese Überschriften in den weitaus meisten Browsern nicht per Tastatur erreichbar sind, es sei denn man verwendet das für Überschriften (H1-6) eigentlich nicht erlaubte tabindex-Attribut und riskiert so, dass der Code nicht mehr validiert.
• Anwendungen bilden Funktionen nach, die in HTML (bisher) nicht vorgesehen sind. Für einfache Zwecke reicht der begrenzte Satz von Formularelementen, den HTML bietet, in der Regel vollkommen aus. In Web-basierten Anwendungen stößt man jedoch schnell an die Grenzen dieser Markup-Sprache, die bekanntlich nie für so etwas gedacht war, und sehnt sich nach einer schnelleren Standardisierung von HTML5 oder XForms. So lange bleibt dem Webentwickler nichts anderes übrig, als Funktionen bzw. Elemente wie Fortschrittsbalken, Schieberegler, Tri-State-Checkboxen u.v.m. mit den vorhandenen Mitteln nachzubilden.
  Und genau hier beginnt das Problem für viele Nutzungsszenarien, die für Menschen mit Behinderungen typisch sind: Viele dieser Elemente sind zum Beispiel nicht per Tastatur zu bedienen, da es sich nicht um echte Interface-Elemente handelt, sondern beispielsweise nur um leere DIV und SPAN, die per Maus und JavaScript manipuliert werden.
  Hilfsmittel sind darauf angewiesen, dass es in der jeweiligen Accessibility-API des Betriebssystems ein entsprechendes Pendant zu den Formular- und Kontrollelementen gibt, um die Bedienbarkeit zu gewährleisten. So wird z. B. ein Fortschrittsbalken in echten Desktop-Anwendungen (wenn's bei Uploads, komplexen Abfragen oder Berechnungen mal wieder etwas länger dauert) im Screenreader erkannt; die Werte werden in Intervallen wiedergegeben (20%, 30%, 40%, …). Bildet man diese Funktion (zumindest optisch) mit den Bordmitteln von HTML , CSS & JavaScript nach, so mag dies zwar wie ein Fortschrittsbalken aussehen, für einen Screenreader ist dies jedoch eine Ansammlung sinnbefreiter leerer Elemente.

Ein Blick in die Zukunft: WAI-ARIA

Alle verbreiteten Betriebssysteme bzw. grafischen Benutzeroberflächen (GUI) verfügen mittlerweile über sogenannte Accessibility APIs (Application Programming Interfaces). Über diese Schnittstellen werden Hilfsmittel wie Braillezeilen, Lupenprogramme und Screenreader, aber auch alternative Eingabeformen mit den nötigen Informationen darüber versorgt, was gerade auf dem Bildschirm geschieht und wie Funktionen zu bedienen sind.

Für Windows ist dies die Microsoft Active Accessibility-Schnittstelle (MSAA), unter Linux gibt es das Gnome Accessibility Toolkit (ATK), bei Apple ist es das Accessibility-API for Cocoa und auch Sun hat mit dem Java Accessibility-API eine entsprechende Schnittstelle. Um über diese Schnittstellen kommunizieren zu können und dem Nutzer den Zugriff zu gewährleisten brauchen Ihre Elemente klar festgelegte Rollen und Zustände (Roles = Was ist dieses Element und was kann ich damit machen? bzw. States = In welchem Zustand befindet sich das Element?)

Im Falle statischer HTML-Seiten mit Strukturelementen, Links und einfachen Formularelementen sind die Rollenverteilungen und Zustände klar verteilt und sollten somit kein Problem für die assistiven Hilfsmittel darstellen. Der Browser teilt die Informationen über die jeweiligen Elemente und ihre Zustände (gedrückt, angekreuzt, besucht) über das Accessibility-API mit.

Wenn nun jedoch per HTML , CSS & JavaScript Bedienelemente nachgebildet werden, die über den begrenzten Satz von HTML hinausgehen, eröffnet sich das Problem, dass diese »Nachbauten« vom Accessibility-API nicht verstanden werden und somit auch nicht an ein Hilfsmittel weitergereicht werden können.

Die WAI-ARIA-Roadmap (sperriger Name: »World Wide Web Consortium Web Accessibility Initiative Accessible Rich Internet Applications Roadmap«) zeigt einen Ausweg auf, wie dies in Zukunft zu vermeiden ist. Die in der Entwicklung befindliche Spezifikation wird zum Zeitpunkt dieser Veröffentlichung bereits von den aktuellen Versionen der Screenreader Window Eyes und JAWS sowie von Firefox ab v.1.5 unterstützt, weitere Hilfsmittel und Browser werden in Zukunft sicher folgen. Bis dahin haben diese Techniken jedoch nur experimentellen Charakter – darauf verlassen können Sie sich nur in kontrollierten Umgebungen, wo Sie als Anbieter einen Einfluss auf die verwendeten User Agents haben, wie z. B. in Intranets.

Was haben wir gelernt?

Anders als bei klassischen Webseiten, die sich an der statischen Dokumenten-Metapher orientieren, lassen sich Barrieren in Web-basierten Anwendungen nur schwer vorhersagen und somit kaum in ein abstraktes Regelwerk für systematische Tests einsortieren. Selbst wenn Sie für Ihre Anwendung eine JavaScript-Library wie Dojo verwenden, bei der die Accessibility eine wichtige Rolle spielt, ist noch lange nicht garantiert, dass das Ergebnis auch tatsächlich barrierefrei zu nutzen ist. Um dies sicherzustellen kommen Sie nicht um Tests mit echten Nutzern herum. Daher dreht sich in der nächsten Folge alles um das »Testen von Formularen und Web-basierten Anwendungen«.

Testen von Formularen und Web-basierten Anwendungen

Klassische Webseiten, also Web-basierte Text-Dokumente, sind relativ einfach zu testen. Was man machen darf und was nicht ist genau beschrieben, mögliche Fehler sind vorhersehbar und somit vermeidbar. Die Vermeidung von technischen Barrieren gehört mittlerweile zum Handwerkszeug eines guten Frontend-Entwicklers; Konzepter und Grafiker orientieren sich an Bedürfnissen und Gewohnheiten der Kunden; jeder gute Redakteur ist daran interessiert, seine Leserschaft nicht mit seinen Texten zu überfordern. Eine ganze Reihe der Kriterien zur Barrierefreiheit sind sogar vollständig maschinell testbar oder zumindest halbautomatisch durch geschulte Tester zu verifizieren.

Bereits bei einfachen Formularen oder Mischformen aus Dokumenten- und Formular- bzw. Anwendungstypen stimmt diese Aussage jedoch nicht mehr: hier ist man noch stärker auf die Beobachtung echter Nutzer angewiesen. Technische Hürden lassen sich zwar auch im Web 2.0 mit maschineller Unterstützung testen; so bietet die YUI Library sogar ein eigenes Test-Framework, das JavaScript-basierte Web-Anwendungen gegen die Implementierungen in allen halbwegs standardkonformen Browsern testet. Solche Tests können jedoch nur verhindern, dass man per JavaScript den Browser des Nutzers »abschiesst« – was dann tatsächlich in Screenreader & Co. ankommt können Sie nur gemeinsam mit Nutzern solcher Programme herausfinden.

Dabei kann man nur dringend davon abraten, als Entwickler selbst mit einem Screenreader zu testen. Zum Einen läuft man so Gefahr, das Thema Accessibility einzig und allein auf den fast schon sprichwörtlichen »blinden Nutzer mit JAWS« zu reduzieren; zum Anderen sind solche Hilfsmittel schon fast Expertensysteme, bei denen man wochenlange Einarbeitung braucht, um zumindest die nötigsten Tastaturbefehle verinnerlicht zu haben. Ein salopper Test bringt daher im Zweifelsfall kaum brauchbare oder im Ernstfall sogar falsch positive Ergebnisse.

Testen, testen, testen und immer an den Nutzer denken …

Diese Warnhinweise bedeuten natürlich nicht, dass Sie Ihre Webanwendung gar nicht mehr testen sollten, im Gegenteil! Die Tests, die Sie bereits während der Entwicklung eines Angebots selber durchführen können sind sogar recht simpel und brauchen nicht mehr als ein paar Browser und verschiedene Firefox-Erweiterungen.

In unserer »BITV-Reloaded«-Serie hatten wir für die dort beschriebenen Tests die »Web Developer Toolbar« empfohlen; bei diesen Tests können Sie sich hingegen von der »Firefox Accessibility Extension« der University of Illinois unterstützen lassen. Die neueste Version dieser Erweiterung unterstützt bereits den zurzeit noch in der Entwicklung befindlichen WAI-ARIA-Standard (Accessible Rich Internet Applications) und ist somit gerade für das Testen von Web-basierten Anwendungen interessant. Neben den auch in anderen Toolbars zu findenden Optionen zum an- und abschalten bestimmter Dinge lassen sich mit dieser Erweiterung auch selektiv bestimmte JavaScript-Events unterdrücken. Zudem erfährt man eine Menge über verwendete Events und, sofern vorhanden, über Roles and States von Elementen, also Rollen und Zustände von Bedienelementen und DHTML-Widgets im Sinne der WAI-ARIA.

Der Minimaltest

Für eine detaillierte Beschreibung von Barrieren und wie man sie aufspürt legen wir Ihnen nochmals unsere »BITV-Reloaded«-Serie nahe. An dieser Stelle nun einige Tipps, wie Sie Ihre Formulare mit ein paar kurzen Tests überprüfen können:

Sind alle Inhalte und Funktionen per Tastatur erreichbar und bedienbar?

Legen Sie die Maus beiseite und bewegen Sie sich ausschließlich per Tastatur durch Ihr Angebot. Im Gegensatz zu reinen Textseiten, wo die Navigation per Tastatur je nach Browser nur mit einem begrenzten Satz von Tasten funktioniert und Formularelemente automatisch auch per Tastendruck zugänglich sind, können in Web-basierten Applikationen weitere Tasten wie Leertaste, Escape, Control, Alt und Command mit Funktionen belegt sein. Achten Sie bei Ihren Tests auch darauf, dass diese nicht nur funktionieren, sondern auch irgendwo erklärt sind!

Sind alle Label korrekt verknüpft?

Für diesen Test dürfen Sie die Maus nun wieder zur Hand nehmen: klicken Sie auf sämtliche Labels Ihrer Formulare. Achten Sie besonders bei Radiobuttons und Checkboxen, dass die jeweils korrekten Elemente markiert werden und nicht irgendwelche anderen – dann haben Sie id- oder for-Attribute falsch gesetzt und müssen diese korrigieren. Ein Nutzer, der auf Tastaturbedienung angewiesen ist hat keine Chance, ein nicht korrekt zugeordnetes Element über sein Label zu bedienen – ein Fehler, den kein Validator bemerken kann und den Sie nur durch tatsächliches Ausprobieren finden können.

Werden durch Navigationsbewegungen Formulare ungewollt verändert oder sogar abgeschickt?

Ein häufiger Fehler ist, Formularelemente mit JavaScript per onchange oder onblur zu prüfen. Diese Art der Überprüfung ist zwar direkt und schnell und damit scheinbar hilfreich, kann aber das Ausfüllen eines Formulars per Tastatur oder Spracherkennung schlichtweg unmöglich machen. Eine detailliertere Diskussion dieser Barrieren finden Sie in unserer »BITV Reloaded«-Serie bei Anforderung 9, Bedingung 9.3.

Die wohl am meisten verbreitete Anwendung dieser Technik sind Drop-down-Menüs, die gerne genommen werden um Platz zu sparen und die Navigation bzw. die Anzahl der Optionen weniger komplex erscheinen zu lassen. In den weitaus meisten Fällen wäre hier ein klassischer Hyperlink das semantisch korrektere Element, da es sich streng genommen ja um Hyperlinks handelt. Diese hätten zudem den Vorteil, dass Hyperlinks nur einen Klick bzw. Tastendruck benötigen. Eine Liste von Hyperlinks ist zudem einfacher zu erfassen. Drop-down-Menüs bedeuten für den Nutzer jedoch mehr Lernaufwand und Mühe in der Bedienung: ein Drop-down-Menü muss man ansteuern und aufklappen, um alle Optionen zu sehen. Selbst dann sieht man je nach Anzahl der Optionen oder je nach Browser nicht alle Optionen auf einen Blick und muss die Liste herunterscrollen.

Bei Ihren Tests sollten Sie also darauf achten, dass Funktionen, die letztendlich nichts anderes als Hyperlinks sind, auch als Hyperlinks umgesetzt wurden.

Ist alles auch ohne Farbe erkennbar?

Achten Sie insbesondere bei Fehlermeldungen etc. drauf, dass diese nicht alleine durch farbliche Markierungen gekennzeichnet sind. Wenn Sie beim Testen auf Fehlermeldungen stoßen (z. B. durch den unvollständigen Versand eines Formulars), dann benötigen diese zusätzliche Struktur- und Gestaltungselemente jenseits von roter Hintergrundfarbe, um wirklich in allen Ausgabeformen wahrnehmbar und damit nutzbar zu sein. Gleiches gilt sinngemäß nicht nur für die Meldung, sondern auch für die Markierung des Ortes des Fehlers.

Für manche Formen der Sehbehinderung bietet das Windows-Betriebssystem sogenannte Kontrastmodi. Typischerweise wird durch diese der Bildschirminhalt invertiert bzw. mit benutzerdefinierten Farben dargestellt, also zum Beispiel beiger Text auf schwarzem Hintergrund, um eine Blendwirkung zu vermindern. Diese Kontrastmodi haben aus Designer-Sicht eine unangenehme Eigenschaft: während alle CSS-Positionierungen beibehalten werden, verschwinden sämtliche Hintergrundfarben und vor allem auch Hintergrundbilder! Wenn Sie also Warnhinweise per CSS (z. B. .fehler {background-image: warnung.gif;}) realisiert haben, so sind diese für viele sehbehinderte Nutzer nicht mehr wahrnehmbar, weil schlichtweg nicht vorhanden. Zur Vermeidung sollten Sie daher Ihre gesamte Anwendung unbedingt einmal vollständig im Windows-Kontrastmodus durchtesten.

Strittige Punkte

Es gibt einige Punkte, bei denen selbst unter Experten und Betroffenen keine Einigkeit herrscht, ob sie sinnvoll sind, oder ob man diese Techniken auslassen kann und trotzdem noch ein barrierefreies Angebot hat. Ein übermäßiger Einsatz aller in HTML vorgesehenen Hilfen zur Orientierung und Navigation kann sogar für manche Nutzergruppen dazu führen, dass eine Seite weniger benutzbar wird. Das ist insbesondere dann der Fall, wenn die eingesetzte Technik einen übermäßigen Lernaufwand erfordert, der die Vorteile der Technik aufwiegt oder sogar übersteigt. Ein solcher Kandidat sind die von den gängigen Vorgaben für Barrierefreie Internetauftritte verlangten Tastaturkürzel zur Navigation, die sogenannten Accesskeys.

Accesskeys – Ja oder Nein?

Die Idee hinter dem accesskey-Attribut in HTML ist eigentlich bestechend einfach: Wie in den gewohnten Desktop-Anwendungen kann man auch in HTML-Seiten Tastaturkürzel definieren, durch die bestimmte Aktionen ausgelöst werden. In HTML können diese Attribute einer Vielzahl von Elementen zugewiesen werden und somit unterschiedlichste Aktionen auslösen. Wie alle Attribute hat auch dieses einen Wert, der in Form von einzelnen Buchstaben oder Zahlen angegeben wird. Dieses Zeichen entspricht der Taste, die der Benutzer zusammen mit einer oder mehreren weiteren Tasten drücken muss, um die gewünschte Aktion auszulösen. Und genau da beginnt das Problem:

Unter den Browserherstellern herrscht keine Einigkeit, welche Tasten zusätzlich neben dem im accesskey angegebenen Zeichen zu drücken sind. Unter Windows sind dies im Internet Explorer die Alt-Taste + Accesskey + Enter, im Mozilla Alt-Taste + Accesskey ohne Enter, in Opera sind es Shift + Esc + Accesskey (ohne Enter). Auf anderen Plattformen wie dem Apple Macintosh sind es statt der Alt-Taste die Ctrl-Taste (auch ohne Enter), Opera macht hier wieder die Ausnahme mit Shift + Esc und so weiter – sie sehen die Unmöglichkeit, einen erklärenden Hilfe-Text für eine Website zu verfassen. Zudem sind Accesskeys gerade für Menschen mit motorischen Behinderungen, für die sie auch gedacht waren, durch die Notwendigkeit zum gleichzeitigen Drücken mehrerer Tasten kaum zu gebrauchen.

Erschwerend kommt hinzu, dass die meisten Tasten, die man definieren kann, schon in anderen Programmen vergeben sind. Wenn man die gängigsten Browser untersucht und verbreitete assistive Werkzeuge wie Screenreader und Sprach-Browser hinzunimmt, wird man sehr schnell feststellen, dass fast alle Zeichen auf der Tastatur schon von einem Programm benutzt werden.

Ein noch entscheidenderer Fehler ist die Möglichkeit, dass jeder Web-Entwickler entscheiden kann, wie er diese Tasten vergibt. Für die Vergabe der Accesskeys gibt es keine einheitliche Vorgabe, so dass der Benutzer auf jeder Website, die er neu ansurft, zunächst einmal die Accesskeys erlernen müsste. Diese nicht kontrollierbaren Folgen sind einer der Gründe, warum die kanadische Bundesregierung die Verwendung von Accesskeys wieder aus ihrem Style Guide gestrichen hat.

Ausnahme:

Wenn Sie eine Web-basierte Anwendung mit vielen ähnlichen Formularen für ein Extra- oder Intranet entwickeln, können Sie natürlich genauere Vorhersagen darüber treffen, welche Accesskeys in Ihrer Umgebung funktionieren. In diesem Fall haben Sie ja die volle Kontrolle über die zu verwendende Zugangssoftware. Bei einem solchen System kann die Definition von Accesskeys für immer wiederkehrende Funktionen (also z. B. immer das erste Eingabefeld oder unterschiedliche logische Blöcke) sinnvoll und lohnenswert sein. In diesem Fall reden wir aber von Webinhalten, die keinen Dokumenten-Charakter haben, sondern eindeutig Anwendungs-Charakter. Bei Webseiten, die lediglich aus strukturierten Texten, der dazugehörigen Navigation und gelegentlichen simplen Formularen bestehen, lohnt sich der Einsatz generell nicht.

Tabindex – Ja oder Nein?

Ein enger Verwandter des accesskey-Attributes ist der tabindex. Mit diesem Attribut können Sie die Reihenfolge festlegen, in der sich ein Anwender per Tabulator-Taste durch eine Seite bewegen kann. Dies geschieht jedoch nicht in willkürlicher Form wie bei den Accesskeys, sondern in der Reihenfolge die Sie bei der Erstellung des Formulars definieren:

<input type="text" id="suche" tabindex="1">

Da die meisten Browser und assistiven Programme von sich aus die Navigation per Tabulator-Taste unterstützen, brauchen Sie nicht jedes Element einer Seite mit einem Tabindex zu dekorieren. Dies wäre kontraproduktiv, da Sie nicht vorhersagen können, in welcher Reihenfolge der Benutzer durch die Seite navigieren möchte oder an welcher Stelle der Benutzer mit der Navigation beginnt. Zudem entspricht die Tabreihenfolge grundsätzlich dem Ablauf des Quellcodes – wenn sie hier für eine vernünftige und nachvollziehbare Abfolge sorgen, dann ist das tabindex-Attribut eigentlich nicht mehr nötig.

Sinnvoll erscheint der Einsatz des tabindex-Attributes in Formularen, wenn die Reihenfolge, in der Kontrollelemente bedient oder Texteingaben gemacht werden sollten, nicht der Reihenfolge dieser Elemente im Quelltext entspricht. Dies kann zum Beispiel bei der Eingabe von Postleitzahl und Ort in zwei unterschiedliche Felder der Fall sein. Diese werden vom Benutzer in genau dieser Reihenfolge erwartet, müssen aber im Quelltext nicht unmittelbar aufeinander folgen und können unter Umständen nicht nacheinander von der Tabulator-Taste angesprungen werden.

Wenn Sie in Ihren Formularen tabindex setzen wollen, sollten Sie diese für das <label>-Tag und nicht für das eigentliche Kontrollelement (Textfeld, Checkbox usw.) definieren. So stellen Sie sicher, dass diese Beschriftungen von einer Sprachausgabe zugeordnet und vorgelesen werden.

Tipp:

Wenn Sie in mehreren Bereichen einer Seite Werte für tabindex vergeben, können Sie dies auch in 10er-Schritten machen. Mit diesem kleinen Kniff brauchen Sie bei Erweiterungen mitten in einer Seite nicht alle folgenden Elemente mit tabindex-Attribut neu zu nummerieren. Uns ist bisher noch kein Browser begegnet, der dieses Attribut zwar versteht, aber nicht von tabindex="14" nach tabindex="20" springen kann, wenn die Werte dazwischen nicht vergeben sind.

Vorbelegung von Formularfeldern

Ein weiterer Punkt, an dem sich die Geister scheiden: die Vorbelegung von Formularelementen wie z. B. Textfeldern durch einen Text, der im jeweiligen Feld angezeigt wird. Die Wurzeln der entsprechenden Vorgaben in den WCAG und damit auch der BITV10.4 stammen noch aus einer Zeit, als angeblich manche Screenreader leere Textfelder nicht erkannten und darüber hinweg lasen. Uns ist jedoch kein einziges Hilfsmittel bekannt, das nach wie vor diesen Fehler aufweist, somit lässt sich diese Forderung der BITV nicht weiter aufrecht erhalten.

Übermäßiger Einsatz von title-Attributen

Nicht nur in Navigationsleisten, auch in Formularen und Web-Anwendungen findet man häufig Inhalte und Funktionen, deren Sinn und Zweck sich erst erschließt, wenn man mit der Maus ein Tooltip auslöst. In diesen per title-Attribut realisierten kleinen Fähnchen stehen dann oftmals erläuternde Hinweise dazu, was sich hinter der jeweiligen Funktion verbirgt, da die Funktion selbst nicht verständlich beschriftet ist. Wenn Ihre Funktionen ohne diese Tooltips nicht verständlich sind – sollten Sie dann nicht lieber den Aufwand für die technische Umsetzung und Betextung dieser title-Attribute in verständlichere Icons, Buttons und Links stecken? Zumal diese title-Attribute nur bei Mausbedienung erscheinen, für Tastaturnutzer bleiben sie in sämtlichen grafischen Browsern verborgen.