2. Juni 2006 in Journal » Usability/Accessibility

Vorsicht bei CSS-Gestaltung von Formularen

Wer im Sinne der Webstandards mit CSS seine Website gestaltet und dabei Wert auf Usability und Accessibility legt, sollte die Anzeige von Formularen nur minimal ändern. Eine ausführliche Argumentation dafür und eventl. Gründe dagegen führe ich hier aus.

Die Betriebssysteme und ihre Skins/Themes

Die drei großen Betriebssysteme Windows, Mac OS und Linux sind die Bekanntesten mit grafischer Benutzeroberfläche. Dass heisst, sie unterstützen Informationen und Inhalte mit visuellen Hilfsmitteln, wie z.B. Fenster, Dialoge, Symbole/Icons und Leisten/Docks.

Mit unter den visuellen Hilfmitteln sind auch gestaltete interaktive Kommunikationsmittel - Formulare. Sie bieten dem Nutzer die Möglichkeit, Eingaben und Einstellungen vorzunehmen.

Interfaces und Benutzererfahrungen

Grundsätzlich geht man davon aus, dass ein Benutzer eine Benutzeroberfläche verwendet. Er gewöhnt sich an das Betriebssystem und dessen Look & Feel. Heutzutage bieten die meisten Betriebssysteme Möglichkeiten zur Anpassung der visuellen Gestaltung der Oberfläche an - die Skins oder Themes.

Bei computer-unerfahrenen Menschen ist eine Abweichung des Skins/Themes schon eine schwerwiegende Komplikation. Bei der Umstellung auf ein anderes Betriebssystem (OS) kommen noch mehr Probleme auf. Bestes Beispiel: Setzt man einen einen Windows-Benutzer vor einem Apple-Rechner mit dem Betriebssystem Mac OS X, ist dieser anfangs total verwirrt und sucht vergebens am unteren Bildschirmrand die Taskleiste mit dem Start-Button. Kurzum: Die Interface-Philosophien von Apple und Microsoft unterscheiden sich sehr, bei Linux-Distributionen mit Gnome oder KDE ist es nicht anders.

Formulare im Internet

Im Grunde sind Formulare im Internet nichts anderes als Formulare vom Betriebssystem oder installierten Anwendungen. Sie bieten dem Benutzer die Möglichkeit, mit der Website zu interagieren. Jedoch sollten Formulare auf Websites als solche erkannt werden. Genau da liegt das Problem. Der Einsatz von CSS bei Eingabefeldern (input), Textbereichen (textarea) und dem Rest der Formularelemente verändert sozusagen die grafische Oberfläche des Benutzers ohne dessen Zustimmung. Der Benutzer hat sich im Normalfall an die Gestaltung der Formulare, die durch den aktuellen Skin/Theme (ob Standard oder abstrakt) bestimmt wird, gewöhnt.

Warum sollte man ihn dazu zwingen sich für eine Interaktion mit einer Website umzustellen? Eigentlich unbegründet, jedoch sprechen für einige Gründe dafür und es wird in etwa soargumentiert:

  • Ästhetik

    Ein Argument für die Gestaltung von Formularen wäre die Ästhetik. Es gibt unendlich viele Möglichkeiten, ein Formular einfach schön zu gestalten und so von der Masse hervorzuheben.

  • Gestaltungslinie

    Man kann sich einfach nicht vorstellen, dass jedes Aussehen eines Formulars in die Gestaltung vom Rest der Website passt. Man möchte eine möglichst gerade Gestaltungslinie auf der gesamten Website umsetzen.

  • CSS im Allgemeinen

    CSS als solches gibt dem Webdesigner die Möglichkeit jedes Element beliebig zu positionieren, zu skalieren und einzufärben. Es gibt nicht wirklich Gründe sich dieser Vielfalt von Möglichkeiten zu versperren.

Was ist erlaubt?

In der Einleitung dieses Artikels habe ich angedeutet, dass minimale Änderungen - meiner Meinung nach - erlaubt sind. Einige Optionen der Gestaltung können getrost genutzt werden, ohne dabei die Usability oder Accessibility einzuschränken. Vielleicht sind sie auch ein Pluspunkt für diese Eigenschaften einer Website. Nun, die folgenden Optionen entsprechen meiner Vorstellung für Optionen der CSS-Gestaltung von Formularen:

  • Abstände: margin und padding

    CRAP greift hier wohl als Stichwort. Das label eines Eingabefeldes (input) oder Textbereiches (textarea) sollte nahe bei ihm stehen, verschiedene label - input Paare sollten etwas von einander getrennt werden. Dabei können margin und padding am besten eingesetzt werden.

    Durch gut gewählte Werte können auch label und input/textarea nebeneinander stehen. So kann eine bessere Übersichtlichkeit und deutlichere Zugehörigkeit erreicht werden.

  • Maße: Höhe und Breite

    Für bessere Lesbarkeit und leichtere Fokussierung der Eingabeelemente können eine optimale Höhe und Breite der Elemente angegeben werden.

Verbesserte Übersichtlichkeit durch Einsatz von CSS

Dazu können beitragen: zusätzliche Elemente, wie fieldset und legend. fieldset kann dabei helfen, ein Formular als Einheit darzustellen. Ein Rahmen (border) oder ein besonderer Hintergrund (background) lassen das Formular als Ganzes zusammenfassen. legend kann den Benutzer aufklären, wofür das Formular da ist. Es kann wie eine Art Überschrift gestaltet werden.

Bei umfangreichen Formularen kann die Verwendung von inhaltlichen Trennungen durch das Element hr in Betracht gezogen werden. Diese Trennung kann als leichte Linie oder als großer Abstand angezeigt werden.

Fazit

Dieser Artikel spiegelt nur meine Meinung zu diesem Thema wieder und kann also nicht als Richtlinie betrachtet werden. Redlounge (der jetzige Look dieser Website) erfüllt noch nicht meine Ratschläge, ich weiß. Trotzdem rate ich zum vorsichtigen und sparsamen Einsatz von CSS, wenn es um echte Formular-Elemente geht. Dazu gehören:

  • Diverse Eingabefelder: input (checkbox, text, radio, submit oder password)
  • Textbereiche: textarea

Nicht wirkliche Bestandteile von Formularen, also Elemente die getrost mit CSS-Regeln versehen werden können wären zum Beispiel:

  • Bezeichnungen: label oder legend
  • Zusammenfassungen bzw. inhaltliche Trennungen: fieldset, div, hr

8 Kommentare

Discogalaxy am 2. Juni 2006 #

Das sind gute Hinweise. Aber für mein Empfinden muss man nicht unbedingt sparsam damit sein.

Hier zb. finde ich alle Felder als solche auf den ersten Blick zu erkennen.
Solange man das ganze nicht auf den Kopf stellt und absolut unkenntlich macht finde ich künstlerische Freiheit vollkommen in Ordnung.
Benutzer die sich schwer tun bei der kleinsten Änderung des Look & Feel bei einem OS finden sich gewohnheitsgemäss auch nicht in Blogs zurecht, bzw hinterlassen Kommentare

Martin Labuschin am 2. Juni 2006 #

Ein gutes Beispiel für schöne Formualre, die auch als solche erknnbar sind: http://www.smileycat.com/miaow/archives/comment-form-showcase.html Jedoch sind auch Aunahmen dabei, wie z.B. die Postkarte oder die Formulare, wo Submit Buttons so aussehen wie normale Eingabefelder.

boris am 2. Juni 2006 #

Dass Formulare als Bestandteil des Betriebssystems erkannt werden, wie es manche behaupten, halte ich für eine Behauptung. Ja. Nicht aber für nachvollziehbar. Die User, die man damit zu meinen vorgibt, differenzieren diesen Zusammenhang nicht. Und das ist nicht einmal ein Problem. Auch wir erfahrene User tun das nicht.


Niemand ist so unbedarft, nur einen Windows-Button als Button zu erkennen. Er wäre niemals imstande, von Windows auf einen Mac umzusteigen, weil er diesen "Designsprung" niemals mitgehen könnte.

Das Argument könnte man gleichermaßen übertragen auf Navigationsmenüs einer Website. Die würden erkannt als Menüleiste des Betriebssystems usw.

Ich finde, da haben einige Designer mal wieder eine merkwürdige Diskussion losgetreten. Bzw. vom falschen Ende her aufgezogen.


Ich sehe es vielmehr so:

Formulare sollten unmittelbar als solche erkennbar sein. Das ist allerdings richtig. Und sie sollten so angelegt und dimensioniert sein, dass man sich motiviert fühlt, sie auszufüllen. Denn dafür sind sie da.

Und auf einem deutschen Submitbutton darf nicht "Submit" stehen (analog für den Reset-Button), denn das verstehen allerdings viele Leute nicht. Es lebt immer noch mindestens eine Generation, die in großen Teilen kein Englisch kann.

Und eine Textarea sollte auch wie eine aussehen, nicht wie ein kleines Eingabeloch, in das mal eben fünf Wörter passen.


Die Formularfelder sollten per "tabindex" in einer Reihenfolge, die ihrer optischen Anordnung UND den Wahrnehmungsgewohnheiten entspricht, per Tabulator erreichbar sein.

Das sind eklatante Mängel an Usability, die mir praktisch täglich auf meinen Webtouren begegnen.

Vielleicht sollte man mal eine Galerie des "Don't do it this way!" zusammenstellen...

Lothar B. Baier am 2. Juni 2006 #

Ich stimme Boris bei. Ich denke aber, es fehlt noch was.
Aus dem normalen (nicht-Internet-) Leben sind die Menschen eine bestimmte Reihenfolge des Handelns gewöhnt. Wenn ich jemand einen Brief schicke (ja, das soll es tatsächlich noch geben), dann schreibe ich gewöhnlich erst den Brief, dann stecke ich ihn in den Umschlag und beschrifte diesen.
Bei Webformularen ist es meistens umgekehrt (siehe dieses Kontaktformular). Erst beschriftet man den Umschlag, dann schreibt man seinen Brief(Kommentar).
Ich finde es andersherum richtiger.

Wolfgang Bartelme am 2. Juni 2006 #

Gestylte, einfache inputtext Elemente sind meiner Meinung nach unproblematisch - viel wichtiger ist die Gestaltung der Buttons.


Am Beginn der CSS-Ära haben viele Designer Buttons mittels des border-Attributes flach dargestellt. Dadurch fügten die Buttons sich zwar besser in das Gesamterscheinungsbild der Seite ein, sie wurden jedoch von vielen Usern nicht als solche bzw. überhaupt als klickbare Elemente identifiziert.

Julian Schrader am 2. Juni 2006 #

@Lothar: Beschriftest du bei einem Blog-Kommentar den Briefumschlag? Ich sehe es vielmehr so, dass ich zuerst den Briefkopf schreibe (Absenderinformationen) und danach den Brief selbst. Also ist das Formular für Kommentare analog zum Brief aufgebaut. Meiner Meinung nach logisch.

Peter Rehm am 26. Juni 2006 #

Naja ich finde man darf Briefe nicht mit Blogs vergleichen ;)

Allerdings gibt es da auch interessante Studien, über die Bedienbarkeit, und die Intuition mit der Menschen Formulare ausfüllen. Gibt man z.b. 2 Felder für den Namen, und macht die Nachname und dann den Vornamen geben viele Benutzer trotzdem zuerst Vorname und dann Nachname ein, weil Sie es einfach so gewohnt sind.

Und bei fast jedem Formular im Internet gibt man zuerst seine Kontaktdaten ein.

Diskussion geschlossen

Die Kommentarfunktion dieses Artikels wurde deaktiviert. Private Mitteilungen an Martin bitte per E-Mail an martin@labuschin.com. Danke.