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.

Tags: ,

Autor: tc

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:

Drei Fieldsets in Form von Karteireitern

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:

  1. <fieldset>
  2. <legend>Äussere Legende</legend>
  3. <label for="textinput1">Explizites Label:</label><br>
  4. <input type="text" name="textinput1" id="textinput1"><br>
  5. <label>Implizites Label:<br>
  6. <input type="text" name="textinput2" id="textinput2"></label><br>
  7. <fieldset>
  8. <legend>Innere Legende Eins</legend>
  9. <input type="radio" name="flavor1" id="toffee" value="toffee">
  10. <label for="toffee">Vanilla Toffee Crunch</label><br>
  11. <input type="radio" name="flavor1" id="chunky" value="chunky">
  12. <label for="chunky">Chunky Monkey</label><br>
  13. <input type="radio" name="flavor1" id="oatmeal" value="oatmeal">
  14. <label for="oatmeal">Oatmeal Cookie Chunk</label>
  15. </fieldset>
  16. <fieldset>
  17. <legend>Innere Legende Zwo</legend>
  18. <input type="checkbox" name="flavor2" id="brownie" value="chocolate">
  19. <label for="brownie">Chocolate Fudge Brownie</label><br>
  20. <input type="checkbox" name="flavor2" id="cookie" value="cookie">
  21. <label for="cookie">Chocolate Chip Cookie Dough</label><br>
  22. <input type="checkbox" name="flavor2" id="fudge" value="fudge">
  23. <label for="fudge">New York Super Fudge Chunk</label>
  24. </fieldset>
  25. <button type="submit">Yummie!</button>
  26. </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:

Ineinander verschachtelte Fieldsets

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:

  1. <select name="Eissorte">
  2. <option disabled selected>Bitte auswählen:</option>
  3. <optgroup label="Schokoladig">
  4. <option>Chocolate Fudge Brownie</option>
  5. <option>New York Super Fudge Chunk</option>
  6. <option>Chocolate Therapy</option>
  7. <option>Chocolate Chip Cookie Dough</option>
  8. </optgroup>
  9. <optgroup label="Fruchtig">
  10. <option>Cherry Garcia</option>
  11. <option>Bohemian Raspberry</option>
  12. <option>Chunky Monkey</option>
  13. <option>Peace of Cake</option>
  14. </optgroup>
  15. </select>

Das Ergebnis sieht im Browser wie folgt aus:

Darstellung von Optgroup in Safari unter Mac OS X und im Internet Explorer unter Windows

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 () 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:

  1. <label for="textfeld1" class="left">Text:</label>
  2. <input id="textfeld1" type="text"><br>
  3. […]
  4. <input id="checkbox1" type="checkbox" value="ja" class="right">
  5. <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:

Formular mit zwei Label/Eingabe-Paaren nebeneinander

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

Layouttabelle mit Kennzeichnung der fehlerhaften Struktur für die linearisierte Ausgabe

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:

Screenshot aus einem CMS mit vermischten Tabellen- und Formularfunktionen

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.