Beginnen wir mit einem Anmeldeformular. Die meisten Unternehmen wollen langfristige Beziehungen zu ihren Nutzern. Dazu müssen sich Benutzer anmelden. Und dazu müssen sie den Nutzern einen Gegenwert bieten. Niemand möchte sich bei Ihrem Service anmelden – er möchte nur auf alles zugreifen, was Sie anbieten, oder das Versprechen einer schnelleren Erfahrung beim nächsten Besuch.

Trotz des grundlegenden Aussehens des Registrierungsformulars gibt es viele Dinge zu beachten: die primitiven Elemente, aus denen ein Formular besteht (Beschriftungen, Schaltflächen und Eingaben), Möglichkeiten zur Reduzierung des Aufwands (selbst bei kleinen Formularen wie diesem) bis hin zum Formular Validierung.

Durch die Wahl einer so einfachen Form können wir die grundlegenden Qualitäten gut gestalteter Formulare näher betrachten.

## Wie es aussehen könnte

Das Formular besteht aus vier Feldern und einem Absenden-Button. Jedes Feld besteht aus einem Steuerelement (der Eingabe) und dem zugehörigen Label.

Hier ist der HTML-Code:

 <form> <label for="firstName">First name</label> <input type="text" name="firstName"> <label for="lastName">Last name</label> <input type="text" name="lastName"> <label for="email">Email address</label> <input type="email" name="email"> <label for="password">Create password</label> <input type="password" name="password" placeholder="Must be at least 8 characters"> <input type="submit" value="Register"> </form>

Labels sind der Ausgangspunkt unserer Diskussion.

## Etiketten

In Zugänglichkeit für alle legt Laura Kalbag vier allgemeine Parameter dar, die die Benutzererfahrung für alle verbessern:

• Visuell : Machen Sie es einfach zu sehen.
• Auditiv : Machen Sie es einfach zu hören.
• Motor : Erleichtern Sie die Interaktion.
• Kognitiv : Machen Sie es leicht verständlich.

Wenn wir Labels von jedem dieser Standpunkte aus betrachten, können wir sehen, wie wichtig Labels sind. Sehende Benutzer können sie lesen, sehbehinderte Benutzer können sie mithilfe eines Bildschirmlesegeräts hören, und motorisch eingeschränkte Benutzer können sich dank des größeren Trefferbereichs leichter auf das Feld konzentrieren. Das liegt daran, dass durch Klicken auf ein Label der Fokus auf das zugehörige Formularelement gesetzt wird.

Aus diesen Gründen sollte jedes Steuerelement, das Eingaben akzeptiert, ein zusätzliches <label> haben. Submit-Schaltflächen akzeptieren keine Eingaben, daher benötigen sie kein zusätzliches Label – das value -Attribut, das den Text innerhalb des Buttons wiedergibt, fungiert als barrierefreies Label.

Um eine Eingabe mit einem Label zu verbinden, müssen die id der Eingabe und das for -Attribut des Labels übereinstimmen und für die Seite eindeutig sein. Im Fall des E-Mail-Felds ist der Wert „E-Mail“:

 html < label for = "email" > Email address </ label > < input id = "email" >

Das Fehlen eines Etiketts bedeutet, die Bedürfnisse vieler Benutzer zu ignorieren, einschließlich derjenigen mit körperlichen und kognitiven Beeinträchtigungen. Indem wir uns auf die anerkannten Barrieren für Menschen mit Behinderungen konzentrieren, können wir unsere Formulare für alle einfacher und robuster gestalten.

So ist beispielsweise eine größere Trefferfläche für motorisch eingeschränkte Nutzer entscheidend, aber auch für Menschen ohne Beeinträchtigungen leichter zu treffen.

## Platzhalter

Das placeholder -Attribut soll einen Hinweis speichern. Es gibt Benutzern eine zusätzliche Anleitung beim Ausfüllen eines Felds – besonders nützlich für Felder mit komplexen Regeln, wie z. B. ein Passwortfeld.

Da es sich bei Platzhaltertext nicht um einen echten Wert handelt, ist er ausgegraut, damit er von den vom Benutzer eingegebenen Werten unterschieden werden kann.

Im Gegensatz zu Labels sind Hints optional und sollten nicht selbstverständlich verwendet werden. Nur weil das placeholder existiert, heißt das nicht, dass wir es verwenden müssen. Sie brauchen keinen Platzhalter für „Geben Sie Ihren Vornamen ein“, wenn die Bezeichnung „Vorname“ lautet – das ist unnötige Duplizierung.

Platzhalter bestechen durch ihre minimalistische, platzsparende Ästhetik. Dies liegt daran, dass Platzhaltertext innerhalb des Felds platziert wird. Dies ist jedoch ein problematischer Weg, Benutzern einen Hinweis zu geben.

Erstens verschwinden sie, wenn der Benutzer tippt. Verschwindender Text ist schwer zu merken, was zu Fehlern führen kann, wenn der Benutzer beispielsweise vergisst, eine der Passwortregeln zu erfüllen. Benutzer verwechseln häufig Platzhaltertext mit einem Wert, wodurch das Feld übersprungen wird, was wiederum später zu Fehlern führt. Grau-auf-Weiß-Text hat keinen ausreichenden Kontrast, wodurch er im Allgemeinen schwer lesbar ist. Und um das Ganze abzurunden, unterstützen einige Browser keine Platzhalter, einige Screenreader kündigen sie nicht an und langer Hinweistext wird möglicherweise abgeschnitten.

Das ist eine Menge Probleme für das, was im Wesentlichen nur Text ist. Alle Inhalte, insbesondere ein Formhinweis, sollten nicht als Nice-to-have angesehen werden. Anstatt also Platzhalter zu verwenden, ist es besser, den Hinweistext wie folgt über dem Steuerelement zu positionieren:

 <div class="field"> <label for="password"> <span class="field-label">Password</span> <span class="field-hint">Must contain 8+ characters with at least 1 number and 1 uppercase letter.</span> </label> <input type="password" name="password"> </div>

Der Hinweis wird innerhalb des Labels und innerhalb eines <span> platziert, sodass er unterschiedlich gestaltet werden kann. Durch die Platzierung innerhalb des Etiketts wird es von Screenreadern vorgelesen und vergrößert die Trefferfläche weiter.

Wie bei den meisten Dingen im Design ist dies nicht der einzige Weg, um diese Funktionalität zu erreichen. Wir könnten ARIA-Attribute verwenden, um den Hinweis mit der Eingabe zu verknüpfen:

 <div class="field"> <label for="password">Password</label> <p class="field-hint">Must contain 8+ characters with at least 1 number and 1 uppercase letter.</p> <input type="password" name="password"> </div>

Das Attribut aria-describedby wird verwendet, um den Hinweis über seine id zu verbinden – genau wie das Attribut for für Labels, aber umgekehrt. Es wird an das Label des Controls angehängt und nach einer kurzen Pause ausgelesen. In diesem Beispiel „muss das Passwort [Pause] acht Pluszeichen mit mindestens einer Ziffer und einem Großbuchstaben enthalten.“

Es gibt auch andere Unterschiede. Erstens wird durch Klicken auf den Hinweis (in diesem Fall ein <p> ) das Steuerelement nicht fokussiert, wodurch der Trefferbereich verringert wird. Zweitens wird ARIA trotz wachsender Unterstützung nie so gut unterstützt werden wie native Elemente. In diesem speziellen Fall unterstützt Internet Explorer 11 aria-describedby nicht. Aus diesem Grund lautet die erste Regel von ARIA, ARIA nicht zu verwenden:

„Wenn Sie ein natives HTML-Element oder -Attribut mit der Semantik und dem Verhalten, das Sie benötigen, bereits integriert verwenden können, anstatt ein Element umzufunktionieren und eine ARIA-Rolle, einen Status oder eine Eigenschaft hinzuzufügen, um es zugänglich zu machen, dann tun Sie dies .“

Float-Etiketten

Das Float-Etikettenmuster von Matt Smith ist eine Technik, die das Etikett als Platzhalter verwendet. Die Bezeichnung beginnt innerhalb des Steuerelements, schwebt jedoch über dem Steuerelement, wenn der Benutzer etwas eingibt, daher der Name. Diese Technik wird oft für ihre skurrilen, minimalistischen und platzsparenden Qualitäten gelobt.

Leider gibt es bei diesem Ansatz mehrere Probleme. Erstens gibt es keinen Platz für einen Hinweis, da Bezeichnung und Hinweis ein und dasselbe sind. Zweitens sind sie aufgrund ihres schlechten Kontrasts und des kleinen Textes, wie sie normalerweise entworfen werden, schwer zu lesen. (Ein geringerer Kontrast ist erforderlich, damit Benutzer die Möglichkeit haben, zwischen einem echten Wert und einem Platzhalter zu unterscheiden.) Drittens können sie wie Platzhalter mit einem Wert verwechselt und abgeschnitten werden.

Und Float-Etiketten sparen nicht wirklich Platz. Das Etikett braucht erst einmal Platz zum Einziehen. Auch wenn sie Platz gespart haben, ist das kaum ein guter Grund, die Nutzbarkeit von Formularen einzuschränken.

„Scheint nach viel Aufwand zu sein, wenn man einfach Labels über Eingaben platzieren und alle Vorteile/keine der Probleme nutzen könnte.“
— Luke Wroblewski auf Float-Etiketten

Schrullige und minimalistische Benutzeroberflächen sorgen nicht dafür, dass sich Benutzer großartig fühlen – offensichtliche, integrative und robuste Benutzeroberflächen tun dies. Die Höhe solcher Formulare künstlich zu reduzieren, ist sowohl wenig überzeugend als auch problematisch.

Stattdessen sollten Sie zu Beginn des Designprozesses vorrangig Platz für ein allgegenwärtiges, leicht verfügbares Etikett (und ggf. einen Hinweis) schaffen. Auf diese Weise müssen Sie Inhalte nicht auf engstem Raum unterbringen.

Wir werden in Kürze mehrere, weniger künstliche Techniken diskutieren, um die Größe von Formularen zu reduzieren.

## Das Fragenprotokoll

Eine wirkungsvolle und natürliche Möglichkeit, die Größe eines Formulars zu reduzieren, ist die Verwendung eines Frageprotokolls. Es hilft sicherzustellen, dass Sie wissen, warum Sie jede Frage stellen oder ein Formularfeld einfügen.

Muss das Registrierungsformular Vorname, Nachname, E-Mail-Adresse und Passwort erfassen? Gibt es bessere oder alternative Möglichkeiten, um nach diesen Informationen zu fragen, die die Erfahrung vereinfachen?

Aller Wahrscheinlichkeit nach müssen Sie nicht nach dem Vor- und Nachnamen des Benutzers fragen, damit er sich registrieren kann. Wenn Sie diese Informationen später aus irgendeinem Grund benötigen, fragen Sie danach. Durch das Entfernen dieser Felder können wir die Größe des Formulars halbieren. Alles ohne auf neuartige und problematische Muster zurückzugreifen.

### Anmeldung ohne Passwort

Eine Möglichkeit, Benutzer nicht nach einem Kennwort zu fragen, besteht darin, das Anmeldemuster ohne Kennwort zu verwenden. Es funktioniert, indem es die Sicherheit von E-Mail nutzt (die bereits ein Passwort benötigt). Benutzer geben nur ihre E-Mail-Adresse ein und der Dienst sendet einen speziellen Link an ihren Posteingang. Anschließend meldet sich der Benutzer sofort beim Dienst an.

Dies reduziert nicht nur die Größe des Formulars auf nur ein Feld, sondern erspart den Benutzern auch, sich ein weiteres Passwort zu merken. Während dies das Formular isoliert vereinfacht, fügt es auf andere Weise zusätzliche Komplexität für den Benutzer hinzu.

Erstens sind Benutzer mit diesem Ansatz möglicherweise weniger vertraut, und viele Menschen machen sich Sorgen um die Online-Sicherheit. Zweitens ist es langwierig, von der App zu Ihrem E-Mail-Konto wechseln zu müssen, insbesondere für Benutzer, die ihr Passwort kennen oder einen Passwort-Manager verwenden.

Es ist nicht so, dass eine Technik immer besser ist als die andere. Es ist so, dass uns ein Frageprotokoll dazu drängt, als Teil des Designprozesses darüber nachzudenken. Andernfalls würden Sie dem Formular gedankenlos ein Passwortfeld hinzufügen und wären damit fertig.

### Passphrasen

Passwörter sind im Allgemeinen kurz, schwer zu merken und leicht zu knacken. Benutzer müssen häufig ein Passwort mit mehr als acht Zeichen erstellen, das aus mindestens einem Groß- und einem Kleinbuchstaben sowie einer Zahl besteht. Diese Mikrointeraktion ist kaum ideal.

„Entschuldigung, aber Ihr Passwort muss einen Großbuchstaben, eine Zahl, ein Haiku, ein Bandenzeichen, eine Hieroglyphe und das Blut einer Jungfrau enthalten.“
— Anonymes Internet-Mem

Anstelle eines Passworts könnten wir Benutzer nach einer Passphrase fragen. Eine Passphrase ist eine Reihe von Wörtern wie „Monkeysinmygarden“ (sorry, das ist das erste, was mir in den Sinn kommt). Sie sind im Allgemeinen leichter zu merken als Passwörter und aufgrund ihrer Länge sicherer – Passphrasen müssen mindestens 16 Zeichen lang sein.

Der Nachteil ist, dass Passphrasen seltener verwendet werden und daher unbekannt sind. Dies kann Benutzern Angst machen, die sich bereits Sorgen um die Online-Sicherheit machen.

Egal, ob es sich um das Anmeldemuster ohne Passwort oder um Passphrasen handelt, wir sollten uns erst dann von Konventionen entfernen, wenn wir gründliche und vielfältige Benutzerrecherchen durchgeführt haben. Sie möchten nicht unwissentlich eine Reihe von Problemen gegen eine andere austauschen.

## Feldgestaltung

Die Art und Weise, wie Sie Ihre Formularkomponenten gestalten, wird zumindest teilweise von der Marke Ihres Produkts oder Unternehmens bestimmt. Dennoch sind Beschriftungsposition und Fokusstile wichtige Überlegungen.

### Etikettenposition

Die Eye-Tracking-Tests von Matteo Penzo haben gezeigt, dass die Positionierung des Etiketts über (im Gegensatz zu neben) der Formularsteuerung am besten funktioniert.

„Durch das Platzieren eines Labels direkt über dem Eingabefeld konnten Benutzer beide Elemente mit einer einzigen Augenbewegung erfassen.“

Aber es gibt noch andere Gründe, die Beschriftung über dem Feld zu platzieren. Bei kleinen Ansichtsfenstern ist neben der Steuerung kein Platz. Und bei großen Ansichtsfenstern erhöht das Heranzoomen die Wahrscheinlichkeit, dass der Text vom Bildschirm verschwindet.

Außerdem enthalten einige Beschriftungen viel Text, was dazu führt, dass sie sich über mehrere Zeilen erstrecken, was den visuellen Rhythmus stören würde, wenn sie neben dem Steuerelement platziert würden.

Obwohl Sie darauf abzielen sollten, die Bezeichnungen knapp zu halten, ist dies nicht immer möglich. Es ist eine gute Strategie, ein Muster zu verwenden, das unterschiedlichen Inhalten Rechnung trägt – indem Beschriftungen über dem Steuerelement positioniert werden.

### Aussehen, Größe und Platz

Formularfelder sollten wie Formularfelder aussehen. Aber was bedeutet das genau?

Das bedeutet, dass ein Textfeld wie ein Textfeld aussehen sollte. Leere Kästchen bedeuten „füllen Sie mich aus“, weil sie leer sind, wie ein Malbuch. Dies ist zufällig einer der Gründe, warum Platzhalter nicht hilfreich sind. Sie entfernen das wahrgenommene Angebot, das ein leeres Textfeld sonst bieten würde.

Das bedeutet auch, dass der Leerraum eingerahmt (umrandet) werden sollte. Das Entfernen des Rahmens oder das Vorhandensein nur eines unteren Rahmens entfernt beispielsweise die wahrgenommenen Angebote. Eine untere Umrandung mag zunächst wie ein Trennzeichen erscheinen. Auch wenn Sie wissen, dass Sie etwas ausfüllen müssen, geht der Wert über oder unter die Linie?

Räumlich sollte die Beschriftung ihrem Formularsteuerelement am nächsten sein, nicht dem Steuerelement des vorherigen Felds. Dinge, die nahe beieinander erscheinen, suggerieren, dass sie zusammengehören. Ein gleicher Abstand könnte die Ästhetik verbessern, würde jedoch zu Lasten der Benutzerfreundlichkeit gehen.

Schließlich sollten die Beschriftung und das Textfeld selbst groß genug sein, um gelesen und angetippt werden zu können. Dies bedeutet wahrscheinlich eine Schriftgröße von mindestens 16 Pixel und idealerweise ein Gesamt-Tap-Ziel von mindestens 44 Pixel.

### Fokusstile

Fokusstile sind eine einfachere Perspektive. Standardmäßig legen Browser einen Umriss um das Element im Fokus, damit Benutzer, insbesondere diejenigen, die eine Tastatur verwenden, wissen, wo sie sich befinden. Das Problem mit dem Standard-Styling ist, dass es oft schwach und schwer zu erkennen und etwas hässlich ist.

Während dies der Fall ist, sollten Sie nicht versucht sein, es zu entfernen, da dies die Benutzererfahrung für diejenigen, die den Bildschirm mit der Tastatur durchqueren, erheblich beeinträchtigen wird. Wir können das Standard-Styling überschreiben, um es klarer und ästhetisch ansprechender zu machen.

 input:focus { outline: 4px solid #ffbf47; }

## Das E-Mail-Feld

Trotz seines einfachen Aussehens sind einige wichtige Details in die Konstruktion des Feldes eingeflossen, die das Erlebnis beeinflussen.

Wie bereits erwähnt, haben einige Felder zusätzlich zum Label einen Hinweis, weshalb sich das Label in einer untergeordneten Spanne befindet. Die field-label Klasse ermöglicht es uns, sie über CSS zu stylen.

 <div class="field"> <label for="email"> <span class="field-label">Email address</span> </label> <input type="email" name="email"> </div>

Das Label selbst ist „E-Mail-Adresse“ und verwendet Groß- und Kleinschreibung. In „Ein Fall für die Groß- und Kleinschreibung machen“ erklärt John Saito, dass die Groß- und Kleinschreibung von Sätzen (im Gegensatz zur Groß- und Kleinschreibung von Titeln) im Allgemeinen einfacher zu lesen und freundlicher ist und es einfacher macht, Substantive zu erkennen. Ob Sie diesen Rat befolgen, liegt an Ihnen, aber welchen Stil Sie auch immer wählen, stellen Sie sicher, dass Sie ihn konsequent anwenden.

Das type -Attribut der Eingabe wird auf email gesetzt, was eine E-Mail-spezifische Bildschirmtastatur auf Mobilgeräten auslöst. Dies ermöglicht Benutzern einen einfachen Zugriff auf @ und . (Punkt)-Symbole, die jede E-Mail-Adresse enthalten muss.

Personen, die einen nicht unterstützenden Browser verwenden, sehen eine Standardtexteingabe ( <input type="text"> ). Dies ist eine Form der progressiven Verbesserung, die ein Eckpfeiler der Gestaltung inklusiver Erfahrungen ist.

### Progressive Enhancement

Bei der progressiven Verbesserung geht es um Benutzer. Es erleichtert auch unser Leben als Designer und Entwickler. Anstatt mit einer Reihe von Browsern und Geräten Schritt zu halten (was unmöglich ist!), können wir uns einfach auf Funktionen konzentrieren.

In erster Linie geht es bei der progressiven Verbesserung darum, den Benutzern immer ein angemessenes Erlebnis zu bieten, unabhängig von Browser, Gerät oder Verbindungsqualität. Wenn etwas schief geht – und das wird es – werden die Benutzer nicht leiden, da sie immer noch Dinge erledigen können.

Es gibt viele Möglichkeiten, wie eine Erfahrung schief gehen kann. Möglicherweise kann das Stylesheet oder Skript nicht geladen werden. Möglicherweise wird alles geladen, aber der Browser des Benutzers erkennt einige HTML-, CSS- oder JavaScript-Elemente nicht. Was auch immer passiert, die Verwendung von progressiver Verbesserung beim Entwerfen von Erlebnissen verhindert, dass Benutzer eine besonders schlechte Zeit haben.

Es beginnt mit HTML für Struktur und Inhalt. Wenn CSS oder JavaScript nicht geladen werden, ist das in Ordnung, da der Inhalt vorhanden ist.

Wenn alles korrekt geladen wird, werden möglicherweise verschiedene HTML-Elemente nicht erkannt. Beispielsweise verstehen einige Browser <input type="email"> nicht. Das ist jedoch in Ordnung, da Benutzer stattdessen ein Textfeld ( <input type="text"> ) erhalten. Benutzer können weiterhin eine E-Mail-Adresse eingeben; Sie erhalten einfach keine E-Mail-spezifische Tastatur auf dem Handy.

Vielleicht versteht der Browser ein ausgefallenes CSS nicht und ignoriert es einfach. In den meisten Fällen ist dies kein Problem. Nehmen wir an, Sie haben einen Button mit border-radius: 10px . Browser, die diese Regel nicht erkennen, zeigen eine Schaltfläche mit abgewinkelten Ecken. Die wahrgenommene Erschwinglichkeit der Schaltfläche wird wohl reduziert, aber die Benutzer bleiben unversehrt. In anderen Fällen kann es hilfreich sein, Feature-Abfragen zu verwenden.

Dann gibt es JavaScript, das komplizierter ist. Wenn der Browser versucht, Methoden zu parsen, die er nicht erkennt, wird er einen zischenden Anfall auslösen. Dies kann dazu führen, dass Ihre anderen (gültigen und unterstützten) Skripts fehlschlagen. Wenn Ihr Skript nicht zuerst überprüft, ob die Methoden vorhanden sind (Funktionserkennung) und funktionieren (Funktionstest), bevor sie sie verwenden, erhalten Benutzer möglicherweise eine fehlerhafte Benutzeroberfläche. Wenn beispielsweise der Click-Handler einer Schaltfläche eine nicht erkannte Methode aufruft, funktioniert die Schaltfläche nicht. Das ist schlecht.

So steigern Sie. Aber was besser ist, braucht überhaupt keine Verbesserung. HTML mit ein wenig CSS kann den Benutzern ein hervorragendes Erlebnis bieten. Der Inhalt zählt und dafür brauchen Sie kein JavaScript. Je mehr Sie sich auf Inhalt (HTML) und Stil (CSS) verlassen können, desto besser. Ich kann es nicht genug betonen: So oft ist das grundlegende Erlebnis das beste und leistungsstärkste. Es hat keinen Sinn, etwas zu verbessern, wenn es keinen Mehrwert bringt (siehe inklusives Designprinzip 7).

Natürlich gibt es Zeiten, in denen das grundlegende Erlebnis nicht so gut ist, wie es sein könnte – dann ist es an der Zeit, es zu verbessern. Aber wenn wir dem obigen Ansatz folgen, funktionieren die Dinge immer noch, wenn ein Stück CSS oder JavaScript nicht erkannt oder ausgeführt wird.

Progressive Verbesserung lässt uns darüber nachdenken, was passiert, wenn Dinge versagen. Es ermöglicht uns, Erfahrungen mit eingebauter Resilienz aufzubauen. Aber es lässt uns auch darüber nachdenken, ob überhaupt eine Verbesserung erforderlich ist; und wenn ja, wie man am besten vorgeht.

## Das Passwortfeld

Wir verwenden dasselbe Markup wie das zuvor besprochene E-Mail-Feld. Wenn Sie eine Vorlagensprache verwenden, können Sie eine Komponente erstellen, die beide Feldtypen unterstützt. Dies trägt dazu bei, den Grundsatz 3 des inklusiven Designs durchzusetzen, sei konsistent .

 <div class="field"> <label for="password"> <span class="field-label">Choose password</span> <span class="field-hint">Must contain 8+ characters with at least 1 number and 1 uppercase letter.</span> </label> <input type="password" name="password"> </div>

Das Passwortfeld enthält einen Hinweis. Ohne einen verstehen Benutzer die Anforderungen nicht, was wahrscheinlich zu einem Fehler führt, sobald sie versuchen, fortzufahren.

Das Attribut type="password" maskiert den Wert der Eingabe, indem es die Eingaben des Benutzers durch kleine schwarze Punkte ersetzt. Dies ist eine Sicherheitsmaßnahme, die verhindert, dass Personen sehen, was Sie eingegeben haben, wenn sie sich zufällig in der Nähe befinden.

### Eine Passwort-Enthüllung

Das Verdecken des Werts während der Eingabe durch den Benutzer erschwert die Korrektur von Tippfehlern. Wenn also einer erstellt wurde, ist es oft einfacher, den gesamten Eintrag zu löschen und neu zu beginnen. Dies ist frustrierend, da die meisten Benutzer einen Computer nicht verwenden, wenn ihnen jemand über die Schulter schaut.

Aufgrund des erhöhten Tippfehlerrisikos enthalten einige Registrierungsformulare ein zusätzliches Feld „Passwort bestätigen“. Dies ist eine Vorsichtsmaßnahme, bei der der Benutzer dasselbe Kennwort zweimal eingeben muss, was den Aufwand verdoppelt und die Benutzererfahrung verschlechtert. Stattdessen ist es besser, die Benutzer ihr Passwort preisgeben zu lassen, was den Grundsätzen 4 und 5 entspricht, die Kontrolle zu geben und Wahlmöglichkeiten anzubieten . Auf diese Weise können Benutzer ihr Passwort preisgeben, wenn sie wissen, dass niemand hinschaut, wodurch das Risiko von Tippfehlern verringert wird.

Neuere Versionen von Internet Explorer und Microsoft Edge bieten dieses Verhalten nativ. Da wir unsere eigene Lösung erstellen werden, sollten wir diese Funktion mit CSS wie folgt unterdrücken:

 input[type=password]::-ms-reveal { display: none; }

Zuerst müssen wir eine Schaltfläche neben dem Eingang einfügen. Das <button> -Element sollte Ihr Einstiegselement sein, um alles mit JavaScript zu ändern – außer zum Ändern des Standorts, wofür Links da sind. Beim Anklicken sollte das type-Attribut zwischen password und text umgeschaltet werden; und die Beschriftung der Schaltfläche zwischen „Anzeigen“ und „Ausblenden“.

 function PasswordReveal(input) { // store input as a property of the instance // so that it can be referenced in methods // on the prototype this.input = input; this.createButton(); }; PasswordReveal.prototype.createButton = function() { // create a button this.button = $('<button type="button">Show password</button>'); // inject button $(this.input).parent().append(this.button); // listen to the button's click event this.button.on('click', $.proxy(this, 'onButtonClick')); }; PasswordReveal.prototype.onButtonClick = function(e) { // Toggle input type and button text if(this.input.type === 'password') { this.input.type = 'text'; this.button.text('Hide password'); } else { this.input.type = 'password'; this.button.text('Show password'); } };

#### JavaScript-Syntax und Architekturhinweise

Da es viele JavaScript-Varianten und verschiedene Möglichkeiten gibt, Komponenten zu entwerfen, werden wir die Auswahlmöglichkeiten durchgehen, die zum Erstellen der Passwort-Reveal-Komponente und aller kommenden Komponenten in diesem Buch verwendet werden.

Zuerst verwenden wir einen Konstruktor. Ein Konstruktor ist eine Funktion, die üblicherweise in Großbuchstaben geschrieben wird – PasswordReveal , nicht passwordReveal . Es wird mit dem Schlüsselwort new initialisiert, wodurch wir denselben Code verwenden können, um mehrere Instanzen der Komponente zu erstellen:

 var passwordReveal1 = new PasswordReveal(document.getElementById('input1')); var passwordReveal2 = new PasswordReveal(document.getElementById('input2'));

Zweitens werden die Methoden der Komponente im Prototyp definiert – zum Beispiel PasswordReveal.prototype.onButtonClick . Der Prototyp ist die leistungsstärkste Methode, um Methoden über mehrere Instanzen derselben Komponente hinweg gemeinsam zu nutzen.

Drittens wird jQuery verwendet, um Elemente zu erstellen und abzurufen und Ereignisse abzuhören. Auch wenn jQuery möglicherweise nicht erforderlich oder bevorzugt ist, bedeutet seine Verwendung, dass sich dieses Buch auf Formulare und nicht auf die Komplexität browserübergreifender Komponenten konzentrieren kann.

Wenn Sie ein Designer sind, der ein wenig codiert, dann sollten die Allgegenwärtigkeit und die niedrige Eintrittsbarriere von jQuery hilfreich sein. Wenn Sie es vorziehen, jQuery nicht zu verwenden, haben Sie aus dem gleichen Grund keine Probleme, die Komponenten nach Ihren Wünschen umzugestalten.

Möglicherweise ist Ihnen auch die Verwendung der $.proxy Funktion aufgefallen. Dies ist die jQuery-Implementierung von Function.prototype.bind . Wenn wir diese Funktion nicht zum Abhören von Ereignissen verwenden würden, würde der Ereignishandler im Kontext des Elements aufgerufen werden ( this ). Im obigen Beispiel wäre this.button undefiniert. Aber wir möchten, dass this stattdessen das Objekt zum Aufdecken des Passworts ist, damit wir auf seine Eigenschaften und Methoden zugreifen können.

#### Alternative Schnittstellenoptionen

Die oben erstellte Schnittstelle zum Anzeigen des Passworts schaltet die Beschriftung der Schaltfläche zwischen „Passwort anzeigen“ und „Passwort verbergen“ um. Einige Screenreader-Benutzer können verwirrt werden, wenn die Bezeichnung der Schaltfläche geändert wird. Sobald ein Benutzer auf eine Schaltfläche trifft, erwartet er, dass diese Schaltfläche bestehen bleibt. Auch wenn die Schaltfläche persistent ist , lässt eine Änderung der Beschriftung den Eindruck entstehen, dass dies nicht der Fall ist.

Wenn Ihre Forschung zeigt, dass dies ein Problem ist, können Sie zwei alternative Ansätze ausprobieren.

Verwenden Sie zunächst ein Kontrollkästchen mit der dauerhaften Bezeichnung „Passwort anzeigen“. Der Zustand wird durch das checked -Attribut signalisiert. Screenreader-Benutzer hören „Passwort anzeigen, Kontrollkästchen, aktiviert“ (oder ähnlich). Sehende Benutzer sehen das Häkchen in der Checkbox. Das Problem bei diesem Ansatz besteht darin, dass Kontrollkästchen zur Eingabe von Daten und nicht zur Steuerung der Schnittstelle dienen. Einige Benutzer denken vielleicht, dass ihr Passwort dem System offenbart wird.

Oder ändern Sie zweitens den state der Schaltfläche – nicht die Bezeichnung. Um den Benutzern von Screenreadern den Status mitzuteilen, können Sie das Attribut „ aria-pressed “ zwischen „ true “ (gedrückt) und „ false “ (nicht gedrückt) umschalten.

 <button type="button" aria-pressed="true"> Show password </button>

Beim Fokussieren der Schaltfläche sagen Screenreader „Passwort anzeigen, Umschalttaste gedrückt“ (oder ähnlich). Für sehende Benutzer können Sie die Schaltfläche so gestalten, dass sie gedrückt oder nicht gedrückt aussieht, indem Sie die Attributauswahl wie folgt verwenden:

 [aria-pressed="true"] { box-shadow: inset 0 0 0 0.15rem #000, inset 0.25em 0.25em 0 #fff; }

Stellen Sie nur sicher, dass die ungepressten und gepressten Stile offensichtlich und differenziert sind, da sehende Benutzer sonst Schwierigkeiten haben könnten, den Unterschied zwischen ihnen zu erkennen.

### Mikroskopie

Die Bezeichnung ist auf „Passwort wählen“ und nicht auf „Passwort“ eingestellt. Letzteres ist etwas verwirrend und könnte den Benutzer auffordern, ein bereits vorhandenes Passwort einzugeben, was ein Sicherheitsproblem darstellen könnte. Auf subtilere Weise könnte es suggerieren, dass der Benutzer bereits registriert ist, wodurch Benutzer mit kognitiven Beeinträchtigungen glauben, dass sie sich stattdessen anmelden.

Wo „Passwort“ mehrdeutig ist, sorgt „Passwort wählen“ für Klarheit.

## Schaltflächenstile

Was ist ein Knopf? Wir beziehen uns auf viele verschiedene Arten von Komponenten auf einer Webseite als Schaltfläche. Tatsächlich habe ich bereits zwei verschiedene Arten von Schaltflächen behandelt, ohne sie hervorzuheben. Lass uns das jetzt tun.

Schaltflächen zum Senden von Formularen sind „Senden-Schaltflächen“ und werden normalerweise entweder als <input type="submit"> oder <button type="submit"> codiert. Das <button> -Element ist flexibler, da Sie andere Elemente darin verschachteln können. Aber das ist selten nötig. Die meisten Submit-Buttons enthalten nur Text.

Hinweis: Wenn Sie in älteren Versionen von Internet Explorer mehrere <button type="submit"> haben, sendet das Formular den Wert aller Schaltflächen an den Server, unabhängig davon, auf welche geklickt wurde. Sie müssen wissen, auf welche Schaltfläche geklickt wurde, damit Sie die richtige Vorgehensweise bestimmen können, weshalb dieses Element vermieden werden sollte.

Andere Schaltflächen werden in die Benutzeroberfläche eingefügt, um die Erfahrung mit JavaScript zu verbessern – ähnlich wie wir es mit der zuvor besprochenen Komponente zum Aufdecken von Passwörtern getan haben. Das war auch ein <button> , aber sein type war auf button (nicht submit ) gesetzt.

In beiden Fällen ist das erste, was Sie über Schaltflächen wissen sollten, dass sie keine Links sind. Links werden normalerweise unterstrichen (durch Benutzeragentenstile) oder speziell positioniert (in einer Navigationsleiste), sodass sie von normalem Text unterscheidbar sind. Wenn Sie den Mauszeiger über einen Link bewegen, verwandelt sich der Cursor in einen Zeiger. Dies liegt daran, dass Links im Gegensatz zu Schaltflächen ein schwach wahrgenommenes Angebot haben.

In Resilient Web Design diskutiert Jeremy Keith die Idee der materiellen Ehrlichkeit. Er sagt: „Ein Material sollte nicht als Ersatz für ein anderes verwendet werden. Sonst täuscht das Endergebnis.“ Einen Link wie eine Schaltfläche aussehen zu lassen, ist materiell unehrlich. Es teilt den Benutzern mit, dass Links und Schaltflächen gleich sind, wenn sie es nicht sind.

Links können Dinge tun, die Schaltflächen nicht können. Links können beispielsweise in einem neuen Tab geöffnet oder für später mit einem Lesezeichen versehen werden. Daher sollten Schaltflächen weder wie Links aussehen noch einen Zeigercursor haben. Stattdessen sollten wir Schaltflächen wie Schaltflächen aussehen lassen, die von Natur aus eine stark wahrgenommene Erschwinglichkeit haben. Ob sie abgerundete Ecken, Schlagschatten und Ränder haben, liegt bei Ihnen, aber sie sollten trotzdem wie Schaltflächen aussehen.

Schaltflächen können weiterhin Feedback beim Schweben (und beim Fokussieren) geben, indem sie beispielsweise die Hintergrundfarbe ändern.

### Platzierung

Schaltflächen zum Senden befinden sich normalerweise am unteren Rand des Formulars: Bei den meisten Formularen füllen die Benutzer die Felder von oben nach unten aus und senden sie dann ab. Aber soll der Button linksbündig, rechtsbündig oder zentriert sein? Um diese Frage zu beantworten, müssen wir darüber nachdenken, wo Benutzer normalerweise danach suchen werden.

Feldbeschriftungen und Formularsteuerelemente sind links ausgerichtet (in von links nach rechts gelesenen Sprachen) und werden von oben nach unten ausgeführt. Benutzer suchen nach dem nächsten Feld unter dem letzten. An dieser Stelle sollte natürlich auch der Submit-Button platziert werden: links und direkt unter dem letzten Feld. Dies hilft auch Benutzern, die hineinzoomen, da eine rechtsbündige Schaltfläche leichter aus dem Bildschirm verschwinden könnte.

### Text

Der Text des Buttons ist genauso wichtig wie sein Styling. Der Text sollte die ergriffenen Maßnahmen explizit beschreiben. Und weil es eine Handlung ist, sollte es ein Verb sein. Wir sollten darauf abzielen, so wenige Wörter wie möglich zu verwenden, weil es schneller zu lesen ist. Aber wir sollten Worte nicht auf Kosten der Klarheit entfernen.

Die genauen Worte können zum Tonfall Ihrer Marke passen, aber tauschen Sie Klarheit nicht gegen Eigenartigkeit aus.

Einfache und einfache Sprache ist für jeden leicht verständlich. Die genauen Worte hängen von der Art der Dienstleistung ab. Für unser Registrierungsformular ist „Registrieren“ in Ordnung, aber je nach Dienst ist „Beitreten“ oder „Anmelden“ möglicherweise besser geeignet.

## Validierung

Trotz unserer Bemühungen, ein umfassendes, einfaches und reibungsloses Registrierungserlebnis zu schaffen, können wir menschliche Fehler nicht ausschließen. Menschen machen Fehler und wenn sie das tun, sollten wir es so einfach wie möglich machen, sie zu beheben.

Bei der Formularvalidierung sind einige wichtige Details zu beachten. Von der Entscheidung, wann Feedback gegeben werden soll, über die Art und Weise, wie dieses Feedback angezeigt wird, bis hin zur Formulierung einer guten Fehlermeldung – all diese Dinge müssen berücksichtigt werden.

### HTML5-Validierung

HTML5-Validierung gibt es schon seit einiger Zeit. Durch das Hinzufügen von nur wenigen HTML-Attributen markieren unterstützende Browser fehlerhafte Felder, wenn das Formular gesendet wird. Nicht unterstützende Browser greifen auf die serverseitige Validierung zurück.

Normalerweise würde ich empfehlen, Funktionen zu verwenden, die der Browser kostenlos bereitstellt, da sie oft leistungsfähiger, robuster und zugänglicher sind. Ganz zu schweigen davon, dass es den Benutzern vertrauter wird, wenn mehr Websites beginnen, die Standardfunktionalität zu verwenden.

Obwohl die HTML5-Validierungsunterstützung recht gut ist, wird sie nicht einheitlich implementiert. Beispielsweise kann das erforderliche Attribut Felder von vornherein als ungültig markieren, was nicht erwünscht ist. Einige Browser wie Firefox 45.7 zeigen einen Fehler „Bitte geben Sie eine E-Mail-Adresse ein“ an, selbst wenn der Benutzer etwas in das Feld eingegeben hat, während Chrome beispielsweise sagt „Bitte fügen Sie ein ‚@‘ in die E-Mail-Adresse ein“. was hilfreicher ist.

Wir möchten den Benutzern auch die gleiche Schnittstelle bieten, unabhängig davon, ob Fehler auf dem Server oder dem Client abgefangen werden. Aus diesen Gründen entwickeln wir unsere eigene Lösung. Als erstes müssen Sie die HTML5-Validierung deaktivieren: <form novalidate>

### Bearbeitung der Einreichung

Wenn der Benutzer das Formular absendet, müssen wir prüfen, ob es Fehler gibt. Wenn dies der Fall ist, müssen wir verhindern, dass das Formular die Details an den Server sendet.

 function FormValidator(form) { form.on('submit', $.proxy(this, 'onSubmit')); } FormValidator.prototype.onSubmit = function(e) { if(!this.validate()) { e.preventDefault(); // show errors } };

Beachten Sie, dass wir auf das Sendeereignis des Formulars hören, nicht auf das Klickereignis der Schaltfläche. Letzteres hindert Benutzer daran, das Formular durch Drücken der Eingabetaste zu senden, wenn sich der Fokus in einem der Felder befindet. Dies wird auch als implizite Formularübermittlung bezeichnet.

### Feedback anzeigen

Es ist alles sehr gut, das Vorhandensein von Fehlern zu erkennen, aber an diesem Punkt sind die Benutzer nicht klüger. Es gibt drei unterschiedliche Teile der Benutzeroberfläche, die aktualisiert werden müssen. Wir werden jetzt über jeden von ihnen sprechen.

#### Dokumenttitel

Der <title> des Dokuments ist der erste Teil einer Webseite, der von Screenreadern vorgelesen wird. Als solches können wir es verwenden, um Benutzer schnell darüber zu informieren, dass bei ihrer Übermittlung etwas schief gelaufen ist. Dies ist besonders nützlich, wenn die Seite nach einer Serveranfrage neu geladen wird.

Obwohl wir die Benutzererfahrung verbessern, indem wir Fehler auf dem Client mit JavaScript abfangen, können nicht alle Fehler auf diese Weise abgefangen werden. Beispielsweise kann die Überprüfung, ob eine E-Mail-Adresse noch nicht vergeben ist, nur auf dem Server überprüft werden. Außerdem ist JavaScript fehleranfällig, sodass wir uns nicht allein auf seine Verfügbarkeit verlassen können.

Wo der ursprüngliche Seitentitel „Für [Dienst] registrieren“ lauten könnte, sollte er bei einem Fehler „(2 Fehler) Für [Dienst] registrieren“ (oder ähnlich) lauten. Der genaue Wortlaut ist etwas ansichtssache.

Das folgende JavaScript aktualisiert den Titel:

 document.title = "(" + this.errors.length + ")" + document.title;

Wie oben erwähnt, ist dies in erster Linie für Screenreader-Benutzer gedacht, aber wie es bei inklusivem Design oft der Fall ist, hilft das, was einer Gruppe von Benutzern hilft, auch allen anderen. Diesmal fungiert der aktualisierte Titel als Benachrichtigung auf der Registerkarte.

Fehlerzusammenfassung

Im Vergleich zum Titelelement ist die Fehlerzusammenfassung prominenter, die sehenden Benutzern mitteilt, dass etwas schief gelaufen ist. Aber es ist auch dafür verantwortlich, dass Benutzer verstehen, was schief gelaufen ist und wie es behoben werden kann.

Es befindet sich oben auf der Seite, sodass Benutzer nach einer Seitenaktualisierung nicht nach unten scrollen müssen, um es anzuzeigen (falls auf dem Server ein Fehler auftritt). Üblicherweise werden Fehler rot eingefärbt. Sich allein auf Farbe zu verlassen, könnte jedoch farbenblinde Benutzer ausschließen. Um die Aufmerksamkeit auf die Zusammenfassung zu lenken, sollten Sie auch Position, Größe, Text und Ikonografie verwenden.

Das Feld enthält eine Überschrift „Es besteht ein Problem“, um auf das Problem hinzuweisen. Beachten Sie, dass das Wort „Error“ nicht angezeigt wird, was nicht sehr freundlich ist. Stellen Sie sich vor, Sie würden Ihre Daten eingeben, um ein Auto in einem Ausstellungsraum zu kaufen, und einen Fehler gemacht haben. Der Verkäufer würde nicht „Fehler“ sagen – tatsächlich wäre es seltsam, wenn er das sagen würde.

 <div class="errorSummary" role="group" tabindex="-1" aria-labelledby="errorSummary-heading"> <h2>There's a problem</h2> <ul> <li><a href="#emailaddress">Enter an email address</a></li> <li><a href="#password">The password must contain an uppercase letter</a></li> </ul> </div>

Der Container hat die role group , die verwendet wird, um eine Reihe von Oberflächenelementen zu gruppieren: in diesem Fall die Überschrift und die Fehlerlinks. Das tabindex Attribut ist auf -1 gesetzt, sodass es programmgesteuert mit JavaScript fokussiert werden kann (wenn das Formular mit Fehlern gesendet wird). Dadurch wird sichergestellt, dass das Fehlerübersichtsfenster in die Ansicht gescrollt wird. Andernfalls würde die Benutzeroberfläche beim Senden nicht mehr reagieren und beschädigt erscheinen.

Hinweis: Die Verwendung tabindex="0" bedeutet, dass es über die Tabulatortaste permanent fokussierbar ist, was ein 2.4.3-Fokus-Order-WCAG-Fehler ist. Wenn Benutzer zu etwas gelangen können, erwarten sie, dass es tatsächlich etwas tut.

 FormValidator.prototype.showSummary = function () { // ... this.summary.focus(); };

Darunter befindet sich eine Liste mit Fehlerlinks. Durch Klicken auf einen Link wird der Fokus auf das fehlerhafte Feld gesetzt, sodass Benutzer schnell in das Formular springen können. Das href -Attribut des Links wird auf die ID des Steuerelements gesetzt, was in einigen Browsern ausreicht, um den Fokus darauf zu setzen. In anderen Browsern wird durch Klicken auf den Link die Eingabe jedoch nur angezeigt, ohne sie zu fokussieren. Um dies zu beheben, können wir die Eingabe explizit fokussieren.

 FormValidator.prototype.onErrorClick = function(e) { e.preventDefault(); var href = e.target.href; var id = href.substring(href.indexOf("#"), href.length); $(id).focus(); };

Wenn keine Fehler vorhanden sind, sollte das Zusammenfassungsfeld ausgeblendet sein. Dadurch wird sichergestellt, dass auf der Seite immer nur ein Zusammenfassungsfeld vorhanden ist und dass es immer an derselben Stelle angezeigt wird, unabhängig davon, ob Fehler vom Client oder vom Server gerendert werden. Um das Panel auszublenden, müssen wir eine Klasse von hidden hinzufügen.

 <div class="errorSummary hidden" ...></div>

 .hidden { display: none; }

Hinweis: Sie könnten das hidden Attribut/die verborgene Eigenschaft verwenden, um die Sichtbarkeit eines Elements umzuschalten, aber es gibt weniger Unterstützung dafür. Bei inklusivem Design geht es darum, Entscheidungen zu treffen, von denen Sie wissen, dass sie Menschen wahrscheinlich nicht ausschließen. Die Verwendung einer Klasse entspricht dieser Philosophie.

#### Inline-Fehler

Wir müssen die entsprechende Fehlermeldung direkt über dem Feld platzieren. Dies erspart Benutzern, auf der Seite nach oben und unten zu scrollen, um die Fehlermeldung zu überprüfen, und sie bewegen sich im Formular weiter nach unten. Wenn die Nachricht unter dem Feld platziert wird, erhöhen wir die Wahrscheinlichkeit, dass sie durch das Fenster zur automatischen Vervollständigung des Browsers oder durch die Bildschirmtastatur verdeckt wird.

 <div class="field"> <label for="blah"> <span class="field-error"> <svg width="1.5em" height="1.5em"><use xmlns:xlink="https://www.w3.org/1999/xlink" xlink:href="#warning-icon"></use></svg> Enter your email address. </span> <span class="field-error">Enter an email address</span> </label> </div>

Wie das zuvor erwähnte Hinweismuster wird die Fehlermeldung in das Etikett eingefügt. Wenn das Feld fokussiert ist, hören Screenreader-Benutzer die Nachricht im Kontext, sodass sie sich frei durch das Formular bewegen können, ohne auf die Zusammenfassung verweisen zu müssen.

Die Fehlermeldung ist rot und verwendet ein SVG-Warnsymbol, um die Aufmerksamkeit der Benutzer auf sich zu ziehen. Hätten wir nur einen Farbwechsel verwendet, um einen Fehler anzuzeigen, würde dies farbenblinde Benutzer ausschließen. Das funktioniert also wirklich gut für sehende Benutzer – aber was ist mit Screenreader-Benutzern?

Um sowohl sehenden als auch nicht sehenden Benutzern ein gleichwertiges Erlebnis zu bieten, können wir das gut unterstützte aria-invalid Attribut verwenden. Wenn der Benutzer die Eingabe fokussiert, wird es jetzt in Screenreadern „Ungültig“ (oder ähnlich) ankündigen.

 <input aria-inval>

Hinweis: Das Anmeldeformular besteht nur aus Texteingaben. In Kapitel 3, „Ein Flugbuchungsformular“, sehen wir uns an, wie man Fehler für Gruppen von Feldern, wie zum Beispiel Radio-Buttons, zugänglich einfügt.

### Senden Sie das Formular erneut

Beim zweiten Absenden des Formulars müssen wir die vorhandenen Fehler aus der Sicht löschen. Andernfalls werden Benutzern möglicherweise doppelte Fehler angezeigt.

 FormValidator.prototype.onSubmit = function(e) { this.resetPageTitle(); this.resetSummaryPanel(); this.removeInlineErrors(); if(!this.validate()) { e.preventDefault(); this.updatePageTitle(); this.showSummaryPanel(); this.showInlineErrors(); } };

### Initialisierung

Nachdem wir die FormValidator Komponente fertig definiert haben, können wir sie jetzt initialisieren. Um eine Instanz von FormValidator zu erstellen, müssen Sie das Formularelement als ersten Parameter übergeben.

 var validator = new FormValidator(document.getElementById('registration'));

Um beispielsweise das E-Mail-Feld zu validieren, rufen Sie die Methode addValidator() :

 validator.addValidator('email', [{ method: function(field) { return field.value.trim().length > 0; }, message: 'Enter your email address.' },{ method: function(field) { return (field.value.indexOf('@') > -1); }, message: 'Enter the 'at' symbol in the email address.' }]);

Der erste Parameter ist der name des Steuerelements und der zweite ein Array von Regelobjekten. Jede Regel enthält zwei Eigenschaften: method und message . Die method ist eine Funktion, die verschiedene Bedingungen testet, um entweder true oder false zurückzugeben. False versetzt das Feld in einen Fehlerzustand, der verwendet wird, um die Schnittstelle wie zuvor beschrieben mit Fehlern zu füllen.

#### Triviale Fehler vergeben

In The Design of Everyday Things spricht Don Norman über das Design für Fehler. Er spricht über die Art und Weise, wie Menschen sich unterhalten:

„Wenn eine Person etwas sagt, von dem wir glauben, dass es falsch ist, hinterfragen und debattieren wir. Wir geben kein Warnsignal. Wir piepen nicht. Wir geben keine Fehlermeldungen aus. […] In normalen Gesprächen zwischen zwei Freunden werden falsche Angaben als normal angesehen, als Annäherung an das, was wirklich gemeint war.“

Im Gegensatz zu Menschen sind Maschinen nicht intelligent genug, um die Bedeutung der meisten Handlungen zu bestimmen, aber sie verzeihen Fehler oft weit weniger, als sie sein müssten. Jared Spool macht in „Is Design Metrically Opposed?“ einen Witz darüber. (ca. 42 Minuten in):

„Es braucht eine Codezeile, um eine Telefonnummer zu nehmen und alle Bindestriche, Klammern und Leerzeichen zu entfernen, und es braucht zehn Codezeilen, um eine Fehlermeldung zu schreiben, in der Sie sie hinterlassen haben.“

Die addValidator Methode (oben gezeigt) zeigt, wie Validierungsregeln entworfen werden, damit sie triviale Fehler verzeihen. Die erste Regel zum Beispiel kürzt den Wert, bevor er seine Länge überprüft, wodurch der Benutzer entlastet wird.

### Live-Inline-Validierung

Die Live-Inline-Validierung gibt Benutzern Feedback, während sie tippen oder das Feld verlassen ( onblur ). Es gibt Hinweise darauf, dass die Live-Inline-Validierung die Genauigkeit verbessert und die Fertigstellungszeiten in langen Formularen verkürzt. Dies hat teilweise damit zu tun, dass Benutzern Feedback gegeben wird, wenn die Anforderungen des Bereichs in den Köpfen der Benutzer neu sind. Die Live-Inline-Validierung (oder kurz Live-Validierung) wirft jedoch mehrere Probleme auf.

Bei Eingaben, die eine bestimmte Anzahl von Zeichen erfordern, ist der erste Tastendruck immer eine ungültige Eingabe. Dies bedeutet, dass Benutzer frühzeitig unterbrochen werden, was dazu führen kann, dass sie den mentalen Kontext wechseln, von der Eingabe von Informationen bis zur Korrektur.

Alternativ könnten wir warten, bis der Benutzer genügend Zeichen eingegeben hat, bevor ein Fehler angezeigt wird. Dies bedeutet jedoch, dass Benutzer nur dann eine Rückmeldung erhalten, wenn sie einen korrekten Wert eingegeben haben, was etwas sinnlos ist.

Wir könnten warten, bis der Benutzer das Feld verlässt ( onblur ), aber das ist zu spät, da sich der Benutzer mental auf das nächste Feld vorbereitet (und oft begonnen hat, es einzugeben). Darüber hinaus wechseln einige Benutzer das Fenster oder verwenden einen Passwort-Manager, wenn sie ein Formular verwenden. Dadurch wird das Blur-Ereignis ausgelöst, wodurch ein Fehler angezeigt wird, bevor der Benutzer fertig ist. Alles sehr frustrierend.

Denken Sie daran, dass es kein Problem ist, Benutzern ohne Seitenaktualisierung Feedback zu geben. Es ist auch kein Problem, die Fehlermeldungen inline (neben den Feldern) einzufügen – das haben wir bereits getan. Das Problem mit Live-Feedback ist, dass es die Benutzer entweder zu früh oder zu spät unterbricht, was oft zu einem unangenehmen Erlebnis führt.

Wenn Benutzern häufig Fehler angezeigt werden, stimmt wahrscheinlich an anderer Stelle etwas nicht. Konzentrieren Sie sich darauf, Ihr Formular zu kürzen und eine bessere Anleitung zu bieten (gute Beschriftung und Hinweistext). Auf diese Weise sollten Benutzer nicht mehr als den einen oder anderen Fehler sehen. Wir werden uns im nächsten Kapitel längere Formen ansehen.

### Checklisten-Bestätigungsmuster

Eine Variante der Live-Validierung besteht darin, Regeln abzuhaken (sie als abgeschlossen zu markieren), während der Benutzer eintippt. Dies ist weniger invasiv als die Live-Validierung, eignet sich jedoch nicht für alle Arten von Bereichen. Hier ist ein Beispiel für das Anmeldeformular von MailChimp, das diese Technik für das Passwortfeld verwendet.

Sie sollten die Regeln über dem Feld platzieren. Andernfalls könnte die Bildschirmtastatur das Feedback überdecken. Infolgedessen können Benutzer mit der Eingabe aufhören und die Tastatur ausblenden, um dann das Feedback zu überprüfen.

### Ein Hinweis zum Deaktivieren von Submit-Schaltflächen

Einige Formulare sind so konzipiert, dass die Senden-Schaltfläche deaktiviert wird, bis alle Felder gültig sind. Dabei gibt es mehrere Probleme.

Erstens fragen sich die Benutzer, was an ihren Einträgen eigentlich falsch ist. Zweitens sind deaktivierte Schaltflächen nicht fokussierbar, was es schwierig macht, die Schaltfläche von blinden Benutzern zu entdecken, die mit der Tabulatortaste navigieren. Drittens sind deaktivierte Schaltflächen schwer zu lesen, da sie ausgegraut sind.

Da wir den Benutzern klares Feedback geben, wenn der Benutzer es erwartet, gibt es keinen guten Grund, dem Benutzer die Kontrolle zu entziehen, indem man die Schaltfläche ohnehin deaktiviert.

### Erstellen einer guten Fehlermeldung

Nichts ist wichtiger als Inhalte. Benutzer kommen nicht auf Ihre Website, um das Design zu genießen. Sie kommen, um den Inhalt oder das Ergebnis der Nutzung eines Dienstes zu genießen.

Selbst das durchdachteste, umfassendste und am schönsten gestaltete Erlebnis zählt nichts, wenn wir die Wörter ignorieren, die zur Erstellung von Fehlermeldungen verwendet werden. Eine Studie zeigte, dass das Anzeigen von benutzerdefinierten Fehlermeldungen die Conversions um 0,5 % erhöhte, was einem Jahresumsatz von mehr als 250.000 £ entsprach.

„Inhalt ist die Benutzererfahrung.“
– Ginny Redisch

Wie Beschriftungen, Hinweise und andere Inhalte sorgt eine gute Fehlermeldung mit möglichst wenigen Worten für Klarheit. Normalerweise sollten wir das Design einer Benutzeroberfläche basierend auf dem Inhalt vorantreiben – nicht umgekehrt. Aber in diesem Fall beeinflusst das Verständnis, wie und warum Sie Fehlermeldungen anzeigen, die Gestaltung der Wörter. Deshalb sagt Jared Spool: „Inhalt und Design sind untrennbare Arbeitspartner.“

Wir zeigen Nachrichten in der Zusammenfassung oben auf dem Bildschirm und neben den Feldern an. Die Pflege von zwei Versionen derselben Nachricht ist ein harter Verkauf für einen nicht überzeugenden Gewinn. Entwerfen Sie stattdessen eine Fehlermeldung, die an beiden Stellen funktioniert. „Geben Sie ein 'at'-Symbol ein“ benötigt Kontext aus der Feldbezeichnung, um sinnvoll zu sein. „Ihre E-Mail-Adresse benötigt ein ‚at‘-Symbol“ funktioniert an beiden Stellen gut.

Vermeiden Sie Höflichkeiten, wie zum Beispiel jede Fehlermeldung mit „Bitte“ zu beginnen. Das wirkt einerseits höflich; auf der anderen Seite steht es im Weg und impliziert eine Wahl.

Welchen Ansatz Sie auch wählen, es wird aufgrund der Art des Inhalts einige Wiederholungen geben. Und beim Testen wird normalerweise das Formular abgesendet, ohne irgendwelche Informationen einzugeben. Das macht die Wiederholung eklatant, was uns zum Ausflippen bringen kann. Aber wie oft ist das der Fall? Die meisten Benutzer versuchen nicht, die Schnittstelle zu beschädigen.

Unterschiedliche Fehler erfordern unterschiedliche Formatierung. Anweisungen wie „Geben Sie Ihren Vornamen ein“ sind selbstverständlich. Aber „Geben Sie einen Vornamen mit maximal 35 Zeichen ein“ ist länger, wortreicher und weniger natürlich als eine Beschreibung wie „Der Vorname darf höchstens 35 Zeichen lang sein“.

Hier ist eine Checkliste:

• Sei präzise. Verwenden Sie nicht mehr Wörter als nötig, aber lassen Sie keine Wörter auf Kosten der Klarheit aus.
• Sei konsequent. Verwenden Sie durchgehend den gleichen Ton, die gleichen Wörter und die gleiche Interpunktion.
• Sei genau. Wenn Sie wissen, warum etwas schief gelaufen ist, sagen Sie es. „Die E-Mail ist ungültig.“ ist mehrdeutig und belastet den Benutzer. "Die E-Mail braucht ein 'at'-Symbol" ist klar.
• Sei menschlich, vermeide Fachjargon. Verwenden Sie keine Wörter wie ungültig, verboten und obligatorisch.
• Verwenden Sie eine einfache Sprache. Fehlermeldungen sind keine Gelegenheit, den humorvollen Tonfall Ihrer Marke zu fördern.
• Verwenden Sie die aktive Stimme. Wenn ein Fehler eine Anweisung ist und Sie dem Benutzer sagen, was er tun soll. Beispiel: „Geben Sie Ihren Namen ein“, nicht „Vorname muss eingegeben werden“.
• Geben Sie dem Benutzer keine Schuld. Teilen Sie ihnen mit, was schief gelaufen ist und wie es behoben werden kann.

## Zusammenfassung

In diesem Kapitel haben wir mehrere grundlegende Herausforderungen beim Formulardesign gelöst, die weit über ein einfaches Registrierungsformular hinausgehen. In vielerlei Hinsicht ging es in diesem Kapitel sowohl darum, was wir nicht tun sollten, als auch darum, was wir tun sollten. Indem wir neuartige und künstliche platzsparende Muster vermeiden, um uns auf die Reduzierung der Anzahl der Felder zu konzentrieren, die wir einbeziehen, vermeiden wir mehrere Usability-Fehler und machen gleichzeitig Formulare angenehmer.

### Zu vermeidende Dinge

• Verwenden des placeholder als Mechanismus zum Speichern von Beschriftungs- und Hinweistext.
• Verwendung falscher Eingabetypen.
• Buttons und Links gleich gestalten.
• Validierung von Feldern während der Benutzereingabe.
• Senden-Schaltflächen deaktivieren.
• Mit komplexem Jargon und markenbeeinflusster Mikroskopie.

Und das ist es. Wenn Ihnen dieses erste Kapitel der Form Design Patterns gefallen hat, können Sie sich das Buch gleich zulegen. Fröhliches Lesen!