Hier ist eine einfache, praktische Möglichkeit, die Leistung von Apps auf mobilen Geräten zu verbessern: Konfigurieren Sie HTML-Eingabefelder immer mit den richtigen Attributen type, inputmode und autocomplete. Während diese drei Attribute oft isoliert betrachtet werden, ergeben sie im Kontext der mobilen Benutzererfahrung am meisten Sinn, wenn man sie als Team betrachtet.
Es besteht kein Zweifel daran, dass Formulare auf Mobilgeräten zeitaufwendig und mühsam auszufüllen sein können. Durch die richtige Konfiguration der Eingabefelder können wir jedoch sicherstellen, dass der Dateneingabeprozess für unsere Benutzer so nahtlos wie möglich ist. Betrachten wir einige Beispiele und Best Practices, die wir verwenden können, um bessere Benutzererlebnisse auf Mobilgeräten zu schaffen.

Verwendung des richtigen Eingabetyps
Dies ist am einfachsten richtig zu machen. Eingabetypen wie email, tel und url werden von Browsern gut unterstützt. Während der Vorteil der Verwendung eines Typs wie tel gegenüber dem allgemeineren text bei Desktop-Browsern schwer zu erkennen sein mag, ist er bei mobilen Geräten sofort offensichtlich.
Die Wahl des geeigneten Typs ändert die Tastatur, die auf Android- und iOS-Geräten angezeigt wird, wenn ein Benutzer das Feld fokussiert. Mit sehr geringem Aufwand, nur durch die Verwendung des richtigen Typs, zeigen wir benutzerdefinierte Tastaturen für E-Mail-Adressen, Telefonnummern, URLs und sogar Suchfelder.




Eines ist zu beachten: Sowohl input type="email" als auch input type="url" verfügen über eine Validierungsfunktion, und moderne Browser zeigen einen Fehler-Tooltip an, wenn ihre Werte nicht den erwarteten Formaten entsprechen, wenn der Benutzer das Formular absendet. Wenn Sie diese Funktionalität lieber deaktivieren möchten, können Sie einfach das Attribut novalidate zum enthaltenden form hinzufügen.
Ein kurzer Abstecher zu Datumstypen
HTML-Eingaben umfassen weit mehr als spezialisierte Texteingaben – es gibt auch Radio-Buttons, Checkboxen und so weiter. Für die Zwecke dieser Diskussion spreche ich jedoch hauptsächlich über die eher textbasierten Eingaben.
Es gibt einen Eingabetyp, der im Grenzbereich zwischen den freiformigeren Texteingaben und Eingabewidgets wie Radio-Buttons liegt: date. Der Eingabetyp date gibt es in verschiedenen Varianten, die auf Mobilgeräten gut unterstützt werden, darunter date, time, datetime-local und month. Diese rufen auf iOS und Android benutzerdefinierte Widgets auf, wenn sie fokussiert werden. Anstatt eine spezialisierte Tastatur auszulösen, zeigen sie eine auswahlähnliche Benutzeroberfläche unter iOS und verschiedene Arten von Widgets unter Android an (wo die Selektoren für date und time besonders elegant sind).
Ich war begeistert, native Standardeinstellungen auf Mobilgeräten verwenden zu können, bis ich mich umschaute und feststellte, dass die meisten großen Apps und mobilen Websites benutzerdefinierte Datumsauswähler anstelle von nativen Datumseingabetypen verwenden. Dafür könnte es mehrere Gründe geben. Erstens finde ich den nativen iOS-Datumsauswähler weniger intuitiv als ein Kalender-ähnliches Widget. Zweitens ist selbst die schön gestaltete Android-Implementierung im Vergleich zu benutzerdefinierten Komponenten recht begrenzt – es gibt zum Beispiel keine einfache Möglichkeit, einen Datumsbereich anstelle eines einzelnen Datums einzugeben.
Dennoch sind die Datumseingabetypen einen Blick wert, wenn der von Ihnen verwendete benutzerdefinierte Datumsauswähler auf Mobilgeräten nicht gut funktioniert. Wenn Sie die nativen Eingabewidgets unter iOS und Android ausprobieren möchten und gleichzeitig sicherstellen möchten, dass Desktop-Benutzer ein benutzerdefiniertes Widget anstelle des Standard-Dropdowns sehen, versteckt dieser CSS-Schnipsel das Kalender-Dropdown für Desktop-Browser, die ihn implementieren.
::-webkit-calendar-picker-indicator {
display: none;
}


Eine letzte Anmerkung: date-Typen können nicht durch das Attribut inputmode überschrieben werden, das wir als nächstes besprechen.
Warum sollte mir inputmode wichtig sein?
Das Attribut inputmode ermöglicht es Ihnen, die von der Eingabeart vorgegebene mobile Tastatur zu überschreiben und direkt die Art der für den Benutzer angezeigten Tastatur anzugeben. Als ich dieses Attribut zum ersten Mal kennenlernte, war ich nicht beeindruckt – warum nicht einfach den richtigen type verwenden? Aber obwohl inputmode oft unnötig ist, gibt es einige Stellen, an denen das Attribut äußerst hilfreich sein kann. Der bemerkenswerteste Anwendungsfall, den ich für inputmode gefunden habe, ist die Verbesserung von Zahleneingaben.
Während einige HTML5-Eingabetypen wie url und email unkompliziert sind, ist input type="number" eine andere Sache. Er hat einige Zugänglichkeitsbedenken sowie eine etwas umständliche Benutzeroberfläche. Beispielsweise zeigen Desktop-Browser wie Chrome winzige Pfeile zum Erhöhen/Verringern an, die versehentlich durch Scrollen ausgelöst werden können.
Hier ist also ein Muster, das Sie sich merken und zukünftig verwenden sollten. Für die meisten numerischen Eingaben anstelle von:
<input type="number" />
…sollten Sie stattdessen dies verwenden
<input type="text" inputmode="decimal" />
Warum nicht inputmode="numeric" anstelle von inputmode="decimal"?
Die Attributwerte numeric und decimal erzeugen auf Android identische Tastaturen. Unter iOS zeigt numeric eine Tastatur an, die sowohl Zahlen als auch Satzzeichen anzeigt, während decimal ein fokussiertes Zahlenraster anzeigt, das fast genau wie der tel-Eingabetyp aussieht, nur ohne unnötige, auf Telefonnummern ausgerichtete Optionen. Deshalb bevorzuge ich es für die meisten Arten von Zahleneingaben.

numeric-Eingabe (links) und decimal-Eingabe (rechts)
numeric-Eingabe (links) und decimal-Eingabe (rechts)Christian Oliff hat einen ausgezeichneten Artikel geschrieben, der sich ausschließlich dem inputmode-Attribut widmet.
Vergessen Sie autocomplete nicht
Noch wichtiger als die Anzeige der richtigen mobilen Tastatur ist die Anzeige hilfreicher Autocomplete-Vorschläge. Das kann viel dazu beitragen, eine schnellere und frustrierendere Benutzererfahrung auf Mobilgeräten zu schaffen.
Obwohl Browser Heuristiken für die Anzeige von Autocomplete-Feldern haben, können Sie sich nicht auf sie verlassen und sollten trotzdem sicherstellen, dass Sie das richtige autocomplete-Attribut hinzufügen. Zum Beispiel habe ich unter iOS Safari festgestellt, dass ein input type="tel" nur Autocomplete-Optionen anzeigte, wenn ich explizit ein Attribut autocomplete="tel" hinzufügte.
Sie denken vielleicht, dass Sie mit den grundlegenden autocomplete-Optionen vertraut sind, wie z. B. denen, die dem Benutzer beim Ausfüllen von Kreditkartennummern oder Adressfeldern helfen, aber ich fordere Sie dringend auf, diese zu überprüfen, um sicherzustellen, dass Sie sich aller Optionen bewusst sind. Der Standard listet über 50 Werte auf! Wussten Sie, dass autocomplete="one-time-code" einen Telefonverifizierungs-Workflow super reibungslos gestalten kann?
Apropos autocomplete…
Ich möchte noch ein letztes Element erwähnen, mit dem Sie Ihre eigene benutzerdefinierte Autocomplete-Funktionalität erstellen können: datalist. Obwohl es auf Desktop-Chrome und Safari eine brauchbare – wenn auch etwas einfache – Autocomplete-Erfahrung bietet, glänzt es unter iOS, indem es Vorschläge in einer praktischen Zeile direkt über der Tastatur anzeigt, wo sich normalerweise die System-Autocomplete-Funktionalität befindet. Darüber hinaus ermöglicht es dem Benutzer, zwischen Text- und Select-ähnlichen Eingaben umzuschalten.
Unter Android hingegen erstellt datalist ein typischeres Autocomplete-Dropdown, wobei der Bereich über der Tastatur für die eigene Typ-Ahead-Funktionalität des Systems reserviert ist. Ein möglicher Vorteil dieses Stils ist, dass die Dropdown-Liste leicht scrollbar ist und sofortigen Zugriff auf alle möglichen Optionen bietet, sobald das Feld fokussiert ist. (Unter iOS müsste der Benutzer, um mehr als die drei obersten Treffer anzuzeigen, den Select-Picker durch Drücken des Abwärtspfeilsymbols aktivieren.)

Sie können diese Demo verwenden, um mit datalist zu experimentieren
Und Sie können alle Autocomplete-Optionen sowie die Werte für Eingabetype und inputmode durchsehen, mit diesem Tool, das ich erstellt habe, um Ihnen schnell verschiedene Eingabekonfigurationen auf Mobilgeräten anzuzeigen.
Zusammenfassung
Beim Erstellen eines Formulars bin ich oft versucht, mich auf die Perfektionierung des Desktop-Erlebnisses zu konzentrieren und das mobile Web als nachträglichen Gedanken zu behandeln. Aber während es etwas mehr Arbeit erfordert, um sicherzustellen, dass Formulare auf Mobilgeräten gut funktionieren, muss es nicht allzu schwierig sein. Hoffentlich hat dieser Artikel gezeigt, dass Sie mit wenigen einfachen Schritten Formulare für Ihre Benutzer auf Mobilgeräten erheblich bequemer gestalten können.
Es gibt jetzt auch Unterstützung für das Attribut „enterkeyhint“ für Formulare, um der Eingabetaste auf virtuellen Tastaturen Bezeichnungen zu geben, mit den Werten: enter, done, go, next, previous, search und send.
Ich würde gerne sehen, dass dies dem Tool hinzugefügt wird!
Bei der Verwendung
<input type="text" inputmode="decimal"/>für Zahleneingaben gibt es noch ein Problem: Obwohl Sie die Eingabepfeile auf dem Desktop entfernen und trotzdem die mobile Zahlentastatur erhalten, verlieren Sie die Garantie, dass der Eingabewert eine Zahl ist.
Beispielproblem: Ein (älterer) Benutzer auf dem Desktop gibt in ein Altersfeld „n.a.“ ein.
Dieses Problem kann (zumindest in modernen Browsern) durch die Verwendung des Attributs
patterngelöst werden.Wenn Sie beispielsweise eine Ganzzahl als Eingabe erwarten, verwenden Sie
<input type="text" inputmode="decimal" pattern="\d+"/>Die Eingabe von „n.a.“ in ein solches Feld würde dazu führen, dass der Browser das Feld hervorhebt (normalerweise rot) und eine Fehlermeldung anzeigt.
Zur Ergänzung der großartigen Informationen des Autors…
Die Verwendung von
autocompleteist nicht nur ein potenzieller Usability-Vorteil, wie Sie skizzieren, sondern derzeit auch die einzige Methode, um Erfolgskriterium 1.3.5 Eingabezweck identifizieren (Level AA) von WCAG 2.1 zu erfüllen. Es gibt eine leicht andere Liste vonautocomplete-Werten in WCAG 2.1, die sich auf die Verwendung des Inhalts beziehen und sich nur auf Informationen beziehen, die diese Person betreffen.Auch wenn WHATWG weitere
autocomplete-Werte hinzufügt, werden sich die WCAG-Werte wahrscheinlich nicht sofort ändern. Behalten Sie dies also im Hinterkopf, wenn Sie dies ein oder zwei Jahre später lesen und nach dem UX- und WCAG-Gewinn suchen.Hallo, danke für diesen Artikel! Ich habe versucht, den CSS-Code auf Squarespace einzugeben, und obwohl es funktionierte, hat es all meine anderen Plugins deaktiviert. Können Sie mir bitte helfen zu verstehen, warum das so ist? Danke!