Webkrauts Logo

Webkrauts Webkrauts Schriftzug

- für mehr Qualität im Web

Formulare für mobile Geräte optimieren

HTML5

Formulare für mobile Geräte optimieren

Für das input-type-Attribut sieht HTML5 viele neue Werte vor. Mit der Wahl des richtigen Wertes wird auf mobilen Geräten die passende Tastatur »getriggert«. Durch kleine Anpassungen im HTML wird die Usability von Formularen auf iPad & Co so deutlich verbessert.

Formularelemente nehmen unter allen HTML-Elementen eine besondere Rolle ein. Erst durch sie wird das Internet zum interaktiven Medium. Von daher sollten Formulare mit besonderer Sorgfalt aufgebaut werden. Erschreckend ist etwa, dass auf zahlreichen Webseiten kein label-Element verwendet wird und so eine einfache Möglichkeit ausgelassen wird, die Nutzbarkeit eines Formulars deutlich zu verbessern.

Ein kurzer Blick auf die Grundlagen

  1. <label for="vorname">Vorname</label>
  2. <input type="text" name="vorname" id="vorname">
  3. <input type="checkbox" name="agb" id="agb">
  4. <label for="agb">AGB anerkennen</label>

So sieht’s aus:

Das label ist die Beschriftung eines Formularelements und wird über die id des Formularelements (egal, ob input, select oder textarea) und dem for-Attribut im label verknüpft. Erst damit ist es Nutzern von Screenreadern möglich, ein Formular richtig zu füllen, da die Beschriftung der Felder eindeutig ist.

Nicht nur Screenreadernutzer profitieren vom korrekten Umgang mit dem label-Element. Klicken Nutzer auf die Beschriftung, dann befindet sich der Fokus im Eingabefeld. Klicken sie auf das label einer Radio- oder Checkbox, wird die Box aktiviert und bei Checkboxen beim zweiten Klick wieder deaktiviert. Bei den kleinen Radio- und Checkboxen wird über das label-Element die Klickfläche vergrößert und die Bedienbarkeit ist für alle Nutzer verbessert.

Neue Herausforderung durch SmartPhones und Tablets

Die Vergrößerung der klicksensiblen Fläche steigert die Usability der Formulare auch auf mobilen Geräten. Mit den neuen HTML5-Formular-Attributen kann die Formularbedienbarkeit auf iOS- und Android-Geräten mit wenig Aufwand zusätzlich verbessert werden.

Grundlage für die Optimierung ist die Tatsache, dass sich die Tastatur auf mobilen Geräten von den Tastaturen von Desktoprechnern und Laptops unterscheidet. Das ist für die meisten selbstverständlich, für die Optimierung eines Formulars muss man sich aber genau diese Tatsache vor Augen halten. Es sind nie alle Zeichen auf einem Blick verfügbar oder mit dem Drücken der Umschalttaste zu erreichen. Mobile Geräte bieten unterschiedliche Tastaturansichten, eine Standardansicht mit Buchstaben und den häufigsten Satzzeichen, eine weitere für Zahlen und weiteren Satz- und Sonderzeichen, eine oder mehrere Ansichten für diverse Sonderzeichen.

Bei der Optimierung steht die Wahl des richtigen type-Attributs für das input-Element im Mittelpunkt. Ziel ist immer, die richtige Tastaturansicht zu triggern und damit den Weg zum richtigen Zeichen so kurz wie möglich zu halten. Sprich: Bei jedem Formularelement gilt es, sich zu überlegen, welche Zeichen Nutzer dort eingeben werden, um dann den passenden Wert für das type-Attribut zu wählen.

type="email"

  1. <label for="email-adresse">E-Mail-Adresse</label>
  2. <input type="email" name="email-adresse" id="email-adresse">

So sieht’s aus:

Der Attributwert email sorgt dafür, dass sowohl auf iOS- als auch auf Android-Geräten die Tastatur um ein @-Zeichen ergänzt wird. Ein Wechsel zur richtigen Tastatur, bzw. die Überlegung, auf welcher Tastatur sich das @-Zeichen überhaupt befindet, ist damit hinfällig.

Tastatur mit @-Zeichen beim type-Parameter email auf dem iPad
Tastatur mit @-Zeichen beim type-Parameter email auf dem iPad

Android zeigt zusätzlich eine Taste mit der Aufschrift .com an. Hält der Nutzer die Taste einen kurzen Moment fest, erscheinen weitere Top-Level-Domains, die je nach Android-Version und Spracheinstellung des Gerätes variieren.

Tastatur mit @-Zeichen und .com-Taste beim type-Parameter email auf Android
Tastatur mit @-Zeichen und .com-Taste beim type-Parameter email auf Android

Hier profitieren nicht nur Nutzer mobiler Geräte. Auch bei neueren Browsern bewirkt type="email", dass die Eingabe vor dem Senden überprüft wird und eine falsche Eingabe das Absenden des Formulars verhindert (insofern diese Überprüfung durch den Browser nicht über das Attribut formnovalidate deaktiviert ist).

Fehlermeldung beim type-Parameter email im Google Chrome
Fehlermeldung beim type-Parameter email
im Google Chrome

Allerdings ist diese Validierung nur halbherzig, mit der Eingabe von a@b gilt die Prüfung auf eine korrekte E-Mail-Adresse als gültig. iOS selbst überprüft die Eingabe nicht.

type="tel" und type="number"

  1. <label for="telefon">Telefon</label>
  2. <input type="tel" name="telefon" id="telefon">

So sieht’s aus:

Soll in ein Feld eine Postleitzahl, eine Bestellmenge oder eine Telefonnummer eingegeben werden, bieten sich die type-Werte tel oder number an. Das bringt auf beiden mobilen Betriebssystemen die Zahlentastatur zur Ansicht.

Zahlentastatur beim type-Parameter tel auf dem iPad
Zahlentastatur beim type-Parameter tel auf dem iPad

Vor allem unter Android wird ein Zahlenblock angezeigt, der die Eingabe noch einfacher macht.

Zahlenblock beim type-Parameter tel auf Android
Zahlenblock beim type-Parameter tel auf Android

Während tel auch die Eingabe bestimmter Sonderzeichen erlaubt, können bei number ausschließlich Zahlen eingegeben werden. Dabei sind nicht nur ganze Zahlen zulässig, auch Fließkommazahlen können eingegeben werden.

Zahlenblock ohne Sonderzeichen beim type-Parameter number auf Android
Zahlenblock ohne Sonderzeichen
beim type-Parameter number
auf Android

Je nach Android-Gerät ist jedoch die Eingabe eines Kommas bzw. Punktes nicht möglich. Von daher: number sollte nur dann eingesetzt werden, wenn zu 100% sicher ist, dass eine ganze Zahl eingegeben wird, wie beispielsweise bei einer Bestellmenge. Bei einer Hausnummer, die prinzipiell noch einen Zusatz haben kann (z. B. 16a), wäre der Einsatz von number hingegen fatal.

type="url"

  1. <label for="domain">Domain</label>
  2. <input type="url" name="domain" id="domain">

So sieht’s aus:

Statt der normalen Buchstabentastatur werden bei type="url" auf iOS-Geräten neben den Buchstaben nur Zeichen angezeigt, die in einer URL erlaubt sind: Doppelpunkt, Slash, Bindestrich und Unterstrich. Die Space-Taste hingegen ist hier nicht zu finden.

Ebenfalls wird eine .com- bzw. .de-Taste angezeigt (je nach Spracheinstellung des Geräts), die auch hier beim Halten bzw. Hochwischen weitere Top-Level-Domains anzeigt.

Tastatur beim type-Parameter url auf dem iPad mit .com-Taste
Tastatur beim type-Parameter url auf dem iPad mit .com-Taste

Auf Android-Geräten triggert url leider keine spezielle Tastatur.

type="date", type="datetime", type="datetime-local", type="time" und type="month"

  1. <label for="datum">Datum</label>
  2. <input type="date" name="datum" id="datum">
  3. <label for="zeit">Zeit</label>
  4. <input type="time" name="zeit" id="zeit">

So sieht’s aus:

Anzeige eines Drehrädchen beim type-Parameter datetime auf dem iPad
Anzeige eines Drehrädchen beim
type-Parameter datetime
auf dem iPad

Eine Reihe von Zeit bzw. Datumswerten sind date, datetime, datetime-local, time und month. Diese führen auf iPad und iPhone dazu, dass keine Tastatur, sondern das Apple-typische Drehrädchen angezeigt wird.

Ein solches Bedienelement liefert einen genormten Zeitstring an den Server, der zum Beispiel so aussieht: 2013-12-15T12:45:17Z. Dieser Zeitwert erfordert eine spezielle Verarbeitung. Da jedoch Android sowie die meisten Desktop-Browser kein zufriedenstellendes Bedienelement anbieten, sollten Zeit bzw. Datumswerte für ein input-Element nur zum Einsatz kommen, wenn eine Seite ausschließlich für Apple-Geräte erstellt oder ein Fallback für die anderen Betriebssysteme angeboten wird.

type="week" und type="color"

Lediglich der Vollständigkeit halber seien hier die Werte week und color erwähnt. Ältere Android-Versionen und iOS unterstützen diese Parameter nicht, auch bei Desktop-Browsern ist keine browserübergreifende Unterstützung gegeben, von daher sind diese Werte für den Praxiseinsatz noch nicht geeignet.

autocapitalize="off"

  1. <label for="username">Username</label>
  2. <input type="text" autocapitalize="off" name= "username" id="username">

So sieht’s aus:

Eine Optimierung anderer Art ist die Unterdrückung der Umschalttaste. Standardmäßig wird (falls dies in den Einstellungen nicht deaktiviert wurde) die Umschalttaste aktiviert, sobald der Fokus im Feld ist, so dass die Eingabe mit einem Großbuchstaben beginnt. Was grundsätzlich eine gute Idee ist, muss nicht immer gewollt sein. Beispielsweise bei der Eingabe eines Usernamens, der wahrscheinlich bei vielen nicht mit einem Großbuchstaben beginnt.

Über autocapitalize="off" wird das automatische Aktivieren der Umschalttaste abgestellt. Allerdings ist autocapitalize kein Teil vom HTML5-Standard, sondern stammt von Apple, daher greift dieses Attribut nur auf iOS-Geräten.

autocorrect und spellcheck

  1. <label for="nutzername">Nutzername</label>
  2. <input type="text" autocorrect="off" spellcheck="false" name="username" id="nutzername">

So sieht’s aus:

Ähnlich wie bei der Umschalttaste verhält es sich mit der Autokorrektur. Bei der Eingabe eines Nutzernamens ist es eher hinderlich, wenn das Gerät Wortvorschläge macht. spellcheck="false" ist dabei valides HTML5 und unterdrückt die Autokorrektur auf Android-Geräten, autocorrect="off" ist von Apple und bewirkt den gleichen Effekt auf iPhone und iPad.

Browserkompatibilität

Nicht nur bei neuen input-type-Attributwerten, sondern generell beim Einsatz von neuen HTML5-Elementen müssen sich Webentwickler die Frage nach der Browserunterstützung stellen. Neue Strukturelemente wie section oder article müssen entweder mit div-Elementen umbaut werden oder beispielsweise über html5shiv »aktiviert« werden, damit diese die Darstellung im Internet Explorer 8 nicht »zerfetzen«.

Das Aktivieren neuer type-Parameter ist hingegen nicht möglich und auch nicht notwendig. Browser sind nicht dumm und können mehr, als die Standards definieren. Fehlt ein type im input-Element, oder hat type eine neuen Wert, den der Browser nicht kennt, wird ein einfaches Eingabefeld vom type="text" angezeigt. So ist bei älteren Browsern beispielsweise bei type="email" trotzdem die Eingabe einer E-Mail möglich. Neuere Browser, vor allem Nutzer mobiler Geräte, profitieren von neuen type-Parametern, da die richtige Tastatur angezeigt und das Wechseln der Tastatur überflüssig wird.

Webentwickler müssen sich allerdings im Klaren sein, dass die Wahl des richtigen type-Parameters keine Garantie für korrekte Eingaben ist. Ganz nach der alten Entwickler-Devise »All input is evil (jede Eingabe ist bösartig)«: Auch wenn bestimmte type-Werte vergeben sind, müssen alle Eingaben serverseitig auf ein richtiges Format bzw. zulässige Werte überprüft werden.

Bezüglich der Bedienbarkeit eines Formulars stellen die neuen type-Werte jedoch eine enorme Verbesserung dar! Hier ist der Einsatz von HTML5 bereits heute sinnvoll.

Weiterführende Links

Kommentare

Paul Heisster
am 11.12.2013 - 09:07

Schöner Artikel, allerdings ist das name-Attribut obsolet in HTML5.

Permanenter Link

Matthias
am 11.12.2013 - 10:33

Das ist so nicht richtig, das name-Attribut ist für die Formular-Übertragung nach wie vor notwendig. Siehe HTML 4.10.22 Form submission. Dennoch ist der Artikel aufschlussreich und interessant.

Permanenter Link

Matthias
am 11.12.2013 - 10:40

Das Markup ließe sich verschlanken, wenn man die input-Elemente in die Labels einschließt.

  1. <label for="vorname">Vorname</label>
  2. <input type="text" name="vorname" id="vorname">

  1. <label>Vorname
  2.     <input type="text" name="vorname">
  3. </label>

Siehe HTML 4.10.4 The label element

Ansonsten ist es ein gelungener Beitrag, interessant für vor allem die unterschiedlichen Umsetzungen von ios bzw. android.

Permanenter Link
Jan Hellbusch

Jan Hellbusch (Webkraut)
am 11.12.2013 - 11:03

Es gibt nachwievor Kompatibilitätsprobleme mit implizite label-elemente. Leider wird in Screenreadern dann oft keine Beschriftung vorgelesen; die Technik ist nicht "accessibility supported". Ein Paar Infos dazu auf http://www.barrierefreies-webdesign.de/knowhow/formulare/label.html

Permanenter Link

Gunnar Bittersmann
am 11.12.2013 - 12:33

Danke, gut zu wissen.

input innerhalb von label ist auch sematischer Unsinn.

Permanenter Link
Patrick Lauke

Patrick Lauke (Webkraut)
am 11.12.2013 - 10:51

Da jedoch Android sowie die meisten Desktop-Browser kein zufriedenstellendes Bedienelement anbieten, sollten Zeit bzw. Datumswerte für ein input-Element nur zum Einsatz kommen, wenn eine Seite ausschließlich für Apple-Geräte erstellt oder ein Fallback für die anderen Betriebssysteme angeboten wird.
Android's "Browser" hat zwar Probleme mit den meisten "neuen" Input-Typen, aber Chrome und Firefox auf Android kommen schon mit recht orderntlichen UI-Implementierungen fuer Datum/Zeit daher...also nicht nur exklusiv fuer iOS, wuerd ich sagen.
Permanenter Link

Bernhard Häussner
am 11.12.2013 - 12:09

Auf Android-Geräten triggert url leider keine spezielle Tastatur.

Ich bekomme auf meinem Android (S3/Firefox) auch hier eine angepasste Tastatur für URLs mit Tasten für ".com", Punkt und Slash.

Permanenter Link

Gunnar Bittersmann
am 11.12.2013 - 12:21

Gut, dass die Webkrauts einen weiteren Artikel zu den Neuerungen in HTML5 bei Formularen bringen. Diese werden von Webentwicklern IMHO immer noch nicht weitläufig eingesetzt. Gut an dem Artikel ist auch, dass er die Bedeutung von Labels für die Barrierefreiheit hervorhebt.

Für mich völlig unverständlich ist aber, dass in einem Artikel, der doch die Vorzüge von HTML5 bei Formularen beschreiben will, das required-Attribut nirgends erwähnt ist. Dieses dient zur Auszeichnung von Pflichteingabefeldern. Füllt ein Nutzer ein derart gekennzeichnetes Pflichfeld nicht aus, wird das Formular in HTML5-konformen Browsern (mehr dazu gleich) nicht abgeschickt, ohne dass es dazu JavaScript bedarf.

Einige Dinge sind dem Autor wie auch den Korrekturlesern (bei den Webkrauts wird doch korrekturgelesen, oder?) durch die Lappen gegangen:

Auch bei neueren Browsern bewirkt type="email", dass die Eingabe vor dem Senden überprüft wird

Nicht erst beim Senden, sondern schon während der Eingabe, was sich durch CSS mit den Pseudoklassen :valid und :invalid auch visualisieren lässt, siehe dieses Beispiel.

iOS selbst überprüft die Eingabe nicht.

Diese Aussage ist falsch, in mehrfacher Hinsicht:

Die Überprüfung hat nichts mit dem Betriebssystem zu tun, sondern liegt in der Verantwortung des Browsers. In Chrome werden auch unter iOS nicht korrekt ausgefüllte Formulare nicht abgeschickt. Safari hingegen schickt solche diese trotzdem ab, und zwar nicht nur unter iOS, sondern auch unter OS X. It’s a bug, not a feature, denn das widerspricht der HTML5-Spezifikation (Schritt 4: „… and then abort these steps“).

Das ist es, was Safari falsch macht. Die Überprüfung von Eingabenfeldern beherrscht er schon, denn die Visualisierung per :valid und :invalid funktioniert auch im Safari.

An dieser Stelle auch nochmal der Hinweis, dass die meisten Browser type="email" so implementiert haben, dass gültige E-Mail-Adressen wie ivan@россия.рф als invalid gewertet werden und ein Formular bei derartiger Eingabe nicht abgeschickt werden kann. Das betrifft nicht nur E-Mail-Adressen mit nicht-lateinischen Zeichen; der Inhaber der Domain müller.example möchte schließlich auch seine Adresse info@müller.example verwenden können.

Die HTML5-Spezifikation ist hier äußerst mangelhaft: „User agents may transform the value for display and editing; in particular, user agents should convert punycode in the value to IDN in the display and vice versa.“ Vages „may“ und „should“ anstatt vorzuschreiben, dass Eingaben mit Nicht-ASCII-Zeichen verarbeitet werden müssen und wie das zu geschehen hat.

Zurück zum Text:

Soll in ein Feld eine Postleitzahl, eine Bestellmenge oder eine Telefonnummer eingegeben werden, bieten sich die type-Werte tel oder number an.

Nicht „oder“, sondern „beziehungsweise“, und andersrum: Soll in ein Feld eine Bestellmenge (zu PLZ kommen wir gleich) oder eine Telefonnummer eingegeben werden, bieten sich die type-Werte number beziehungsweise tel an.

Für eine Bestellmenge wäre type="tel" die falsche Auszeichnung.

Für Postleitzahlen ist aber auch type="number" falsch, denn das schließt viele Nutzer aus. Im deutschsprachigen Raum spricht man zwar von „Postleitzahlen“, auf Englisch aber sagt man „postal code“ – und das nicht ohne Grund, denn in Großbritannien enthalten diese nicht nur Ziffern, sondern auch Buchstaben. Möchte man im World-Wide Web Nutzer ausschließen, weil sie in einem anderen Land wohnen?

Statt der normalen Buchstabentastatur werden bei type="url" auf iOS-Geräten neben den Buchstaben nur Zeichen angezeigt, die in einer URL erlaubt sind: Doppelpunkt, Slash, Bindestrich und Unterstrich oder die Space-Taste sind hier nicht zu finden.

Sollte der Satz eigentlich etwas ganz anderes sagen? Doppelpunkt, Slash, Bindestrich und Unterstrich sind doch zu finden (weil in URL erlaubt), und zwar an der Stelle der Space-Taste (weil in URL nicht erlaubt).

autocorrect="off" vs. spellcheck="false" – oh je, Browserkrieg 2.0.

Permanenter Link
Nicolai Schwarz

Nicolai Schwarz (Webkraut)
am 11.12.2013 - 13:07

Wenn du dir bei den Kommentaren soviel Arbeit machst: Wäre es für dich mittlerweile nicht viel sinnvoller, dich als Webkraut zu beteiligen und die Artikel vorher zu redigieren? ;)

Permanenter Link
Nicolai Schwarz

Nicolai Schwarz (Webkraut)
am 12.12.2013 - 09:44

Der falsche Satz rund um »Doppelpunkt, Slash, Bindestrich und Unterstrich oder die Space-Taste« geht auf mein Konto. Meine nächtliche Korrekturrunde hat tatsächlich den Sinn verdreht. Ich habe es korrigiert. Danke.

Permanenter Link

nikosch
am 11.12.2013 - 17:39

Das ist ja mal hilfreich. Vielen Dank!

Permanenter Link

hannenz
am 11.12.2013 - 22:51

Was ich aus dem Artikel gelernt habe ist, dass die ".com"-Taste auf der Android-Tastatur durch langes Drücken auch sinnvolle(re) Alternativen anbietet :)

Permanenter Link

Matthias
am 12.12.2013 - 10:00

Die „Tasten“, die durch längeres Drücken weitere Optionen offenbaren, sind besonders gekennzeichnet, zum Beispiel durch „…“ oben rechts.

Permanenter Link
Stephan Heller

Stephan Heller (Autor)
am 12.12.2013 - 10:52

Vielen Dank für die vielen Kommentare, besonders auch an Gunnar, der meinen Beitrag um wertvolles Wissen ergänzt hat.

Dass ich required ausgelassen habe, würde ich nicht mit "unverständlich" beschreiben. Im Vorfeld und in der Diskussion unter den Webkrauts wurden verschiedene Wünsche geäußert, manche Aussagen zu vertiefen, wie zum Beispiel, wie ich ein Fallback für die anderen Geräte umsetze.

Als Autor steht man hier stets vor der Frage: Gehe ich auf alle Einzelheiten und Eventualitäten ein, oder konzentriere ich mich auf mein Thema, mit dem Wissen, das der Beitrag auch Fragen offen lässt. Schließlich soll es kein Roman sein, sondern etwas, was man morgendlich kurz überfliegen kann, um eine ungefähre Idee zu bekommen, bei Themen, mit denen man noch nicht so viel zu tun hatte.

So hoffe ich doch, dass die anderen Webkrauts und ich auch in diesem Jahr wieder was liefern, was dem einen oder anderem neue Erkenntnisse verschafft, auch wenn es nur ein einzelner Punkt im ganzen Artikel ist. Dann hat sich die Arbeit schon gelohnt!

Permanenter Link

Michelle
am 26.02.2014 - 13:37

Danke für den Artikel. beim Einstieg in Mobile extrem Hilfreich :-) Leider gibt er nicht die Antwort nach der ich aktuell (verzweifelt) suche :-/ Wie kann man einen Zeilenumbruch vor einem Radio erzwingen. Und das der Text bittschön daneben stehen bleibt. Vorher alle 3 Radio nebeneinander für Mobile untereinander. Versuche mit clear, block etc. haben nicht gefruchtet.

Permanenter Link

Die Kommentare sind geschlossen.