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.

Tags: , , , ,

Stand: 06.09.2007, Autor: tc

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 auf die barrierefreie Nutzung durch Menschen mit Behinderungen weitestgehend unerforschtes Neuland ist.

Formular Lohnsteuer 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

Screenshot mit der im folgenden diskutierten Gestaltungsvariante

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

Screenshot mit linksbündig ausgerichteten Labels

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:

Gestreifte Label/Control-Paare

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.

Labels seitlich, rechtsbündig ausgerichtet

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:

Labels oben, rechtsbündig ausgerichtet

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:

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

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:

  1. input, textarea {
  2. background: #ddd;
  3. }

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:

  1. input:focus, textarea:focus {
  2. color: #000;
  3. background: #fff;
  4. outline: 1px solid red;
  5. }

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

Kennzeichnung der Pflichtfelder mit zusätzlicher Grafik und Alternativtext oder title-Attribut

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

Merke: 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" :

  1. <form action="foo">
  2. <fieldset>
  3. <legend>Beispielformular</legend>
  4. <label for="textfeld" class="left">Text:</label>
  5. <input type="text" id="textfeld" name="textfeld" size="12"><br>
  6. <label for="auswahl" class="left">Auswahl:</label>
  7. <select id="auswahl">
  8. <option value="auswahl1">Auswahl 1</option>
  9. <option value="auswahl2">Auswahl 2</option>
  10. </select><br>
  11. <input type="radio" id="radio1" name="radio" value="entweder" class="right">
  12. <label for="radio1">Entweder</label><br>
  13. <input type="radio" id="radio2" name="radio" value="oder" class="right">
  14. <label for="radio2">Oder</label><br>
  15. <input type="checkbox" id="check1" value="sowohl" class="right">
  16. <label for="check1">Sowohl</label><br>
  17. <input type="checkbox" id="check2" value="alsauch" class="right">
  18. <label for="check2">Als auch</label><br>
  19. <button type="submit" class="right">Bestellen</button>
  20. </fieldset>
  21. </form>

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

Formular in der Ansicht ohne CSS

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:

  1. .left {
  2. float: left;
  3. text-align: right;
  4. width: 40%;
  5. margin-right: 2%;
  6. }

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:

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

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:

Darstellung des formatierten Formulars in Safari / Mac OS X

Darstellung des formatierten Formulars in Internet Explorer / Windows

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:

  1. <fieldset>
  2. <legend>Bitte wählen Sie:</legend>
  3. <ol>
  4. <li>
  5. <button type="submit" name="karte" value="sued">
  6. <h3>Südkurve</h3>
  7. <p><strong>10 &euro;</strong></p>
  8. <p>(Stehplatz)</p>
  9. </button>
  10. </li>
  11. <li>
  12. <button type="submit" name="karte" value="nord">
  13. <h3>Nordkurve</h3>
  14. <p><strong>20 &euro;</strong></p>
  15. <p>(Sitzplatz)</p>
  16. </button>
  17. </li>
  18. <li>
  19. <button type="submit" name="karte" value="ost">
  20. <h3>Osttribüne</h3>
  21. <p><strong>30 &euro;</strong></p>
  22. <p>(Sitzplatz)</p>
  23. </button>
  24. </li>
  25. <li>
  26. <button type="submit" name="karte" value="west">
  27. <h3>Westtribüne</h3>
  28. <p><strong>50 &euro;</strong></p>
  29. <p>(VIP-Loge)</p>
  30. </button>
  31. </li>
  32. </ol>
  33. </fieldset>

Besipielcode in der unansehnlichen Darstellung ohne Formatierung

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

Beispielcode mit Formatierung per CSS

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:

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

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.