Barrierefreie Formulare erstellen

Creating Accessible Forms

Online-Formulare sind die Grundlage der Kommunikation in der Moderne. Ohne Formulare hätten wir nur statische Text-Websites mit Bildern von Katzen zum Ansehen. Sicher, es klingt nicht allzu schlecht, aber wie würden wir ohne Formulare Katzenbilder mit all unseren Freunden und unserer Familie diskutieren und teilen? Wie wäre es, online einzukaufen, einen Flug zu buchen, spät in der Nacht Pizza zu bestellen oder einen Termin für ein Treffen auf dieser Dating-Site zu vereinbaren?

Aus diesem Grund ist eine gut geschriebene Formularstruktur und ein gut gestaltetes Design entscheidend für den Erfolg jeder Website oder App. Werfen wir einen Blick auf einige Bereiche, wie wir die Barrierefreiheit beim Formulardesign verbessern können.

Etiketten

Gut sichtbare, deutliche und präzise Formularetiketten sind entscheidend für den Erfolg, damit jeder ein Formular ausfüllen kann. Ohne eine Beschriftung wüsste niemand, was der beabsichtigte Zweck für jedes Formularfeld wäre!

Betrachten wir einige Designüberlegungen beim Hinzufügen von Beschriftungen zu unseren Formularen.

Platzhalter

HTML-Formularfelder verfügen über ein Attribut namens placeholder . Der Wert des Attributs fügt Text in das Feld ein, und wenn jemand mit der Eingabe beginnt, wird der Platzhaltertext automatisch entfernt.

Der ursprüngliche Zweck dieses Attributs besteht darin, Hilfs- oder Hinweistext innerhalb der input zu platzieren. Manchmal werden jedoch Platzhalter anstelle eines tatsächlichen HTML- label -Elements verwendet. Dies ist aus mehreren Gründen problematisch:

  • Ohne ein der input zugeordnetes label - Element können einige Screenreader den Zweck der input möglicherweise nicht vermitteln .
  • Wenn jemand mit der Eingabe beginnt und der placeholder aus der Ansicht entfernt wird, kann der Kontext der input verloren gehen, wodurch jemand gezwungen wird, den eingegebenen Text zu entfernen, um sich daran zu erinnern, wofür die input war.
  • Um die Anforderungen an den Farbkontrast zu erfüllen, muss der standardmäßige graue Text abgedunkelt werden. Dadurch können einige Leute glauben, dass bereits Text in die input wurde.

Es gibt weitere Probleme mit dem placeholder , aber wenn Sie diese wenigen berücksichtigen, ist es klar, dass placeholder nicht als Ersatz für ein tatsächliches label verwendet werden sollten .

Schwebende Etiketten

Die „Floating Label“-Technik scheint in letzter Zeit immer beliebter zu werden. Je nach Implementierung besteht die Grundidee darin, CSS zu verwenden, um den label (oder manchmal den placeholder ) über dem zugehörigen input zu positionieren. Wenn jemand mit der Eingabe beginnt, wird der label nach oben "schweben" und über der Eingabe platziert.

Der Vorteil dieses Ansatzes besteht darin, dass Platz zwischen den Eingaben eingespart wird, wenn der Platz auf dem Bildschirm knapp ist. Es gibt auch den klaren Vorteil, dass ein label -Element mit seinem input verknüpft ist, damit Screenreader den Zweck der input vermitteln .

Die Kehrseite dieses Ansatzes ist ein direktes Ergebnis seines Daseinszwecks; Wenn die label über der input , lässt der verfügbare Platz normalerweise nur weniger als die ideale Textgröße zu. Dies kann dazu führen, dass Personen mit Sehbehinderung den Etikettentext nur schwer lesen können . Natürlich könnten sie einfach in den Bildschirm hineinzoomen, aber warum sollten wir mehr Arbeit für unsere Benutzer schaffen?

Dann betrifft die andere Sorge die tatsächliche Umsetzung. Wenn die Technik am Ende das placeholder anstelle eines tatsächlichen label verwendet, würde dies zu den zuvor besprochenen Problemen führen, hauptsächlich dem Fehlen eines vermittelten Zwecks bei der Interaktion mit einem Bildschirmlesegerät.

Immer sichtbare Etiketten

Das ideale Design von Formularetiketten in Bezug auf Barrierefreiheit ist das "immer sichtbar"-Etikett. So wie es sich anhört, weist diese Technik eine Textbezeichnung auf, die während der gesamten Erfahrung des Ausfüllens des Formulars immer präsent ist.

Die Vorteile dieses Ansatzes liegen auf der Hand:

  • Die Textbeschriftung befindet sich an einer konsistenten, vorhersagbaren Position
  • Das label ist immer sichtbar und erfordert keine kognitive Belastung, sich an den Eingabezweck erinnern zu müssen
  • Screenreader vermitteln den Zweck der input , wenn sie mit Etikettentext interagieren, der groß ist und ausreichend weißen Raum hat, um lesbar zu sein

Vor diesem Hintergrund wird dringend empfohlen, die Beschriftungen sichtbar zu halten. Beseitigen Sie jegliches Rätselraten von Ihren Benutzern und ermöglichen Sie ihnen, die anstehende Aufgabe mit Leichtigkeit und Zuversicht zu erledigen.

Visuell versteckte Etiketten

Ein weiterer Etikettentyp, den wir besprechen müssen, ist das "visuell verborgene" Etikett. Diese erscheinen oft in winzigen, einmaligen Formulareingaben wie Such- oder Sprachauswahlkomponenten, wo der Platz begrenzt ist.

Wie wir wissen, müssen Formulareingabeelemente immer eine label enthalten, um ihren Zweck mit dem input zu teilen. Was können wir tun, wenn ein Design ein nicht sichtbares label erfordert? Sehen wir uns an, wie man ein visuell verstecktes Etikett auf zwei verschiedene Arten anwendet, wobei jede Methode am Ende zum gleichen Ergebnis führt.

Hinweis: Benutzer von Sprachdiktaten haben möglicherweise Schwierigkeiten, den richtigen Call-to-Action zu finden, wenn sie auf die einzelnen Steuerelemente mit einer visuell verborgenen Bezeichnung zugreifen. Mit Vorsicht fortfahren.

Die .visuallyhidden -Klasse

Wenn Sie die .visuallyhidden (manchmal auch als .sr-only bezeichnet) direkt auf das label -Element anwenden, wird das Label für sehende Benutzer entfernt, bleibt aber für Screenreader-Benutzer verfügbar.

 <label for="lang-selector" class="visuallyhidden">Select a language</label> <select id="lang-selector"> <!-- ... --> </select>

Der aria-label Ansatz

Eine andere Möglichkeit besteht darin, das Attribut aria-label direkt auf das input anzuwenden, um ein „verstecktes“ Label bereitzustellen.

 <select aria-label="Select a language"> <!-- ... --> </select>

Genau wie beim .visuallyhidden Ansatz wird dies eine label für die input bereitstellen, und bei input wird der aria-label von Bildschirmlesegeräten angesagt.

Benötigte Felder

Wenn zum Ausfüllen eines Formulars nur bestimmte Felder erforderlich oder optional sind, ist es am besten, diese Anforderung mit visuellen und akustischen Hinweisen zu kennzeichnen. Dies hilft den Leuten zu wissen, welche Felder sie unbedingt ausfüllen müssen, was wiederum Sicherheit beim Ausfüllen des Formulars gibt.

Visueller Hinweis

Bei der label als Erforderlich erfolgt dies normalerweise mit einem Sternchen oder einem Symbol neben der Formularbeschriftung. Unabhängig davon, ob Sie das Sternchen oder eine andere Form eines Symbols verwenden, ist Folgendes wichtig:

  • Die Platzierung des Symbols ist im gesamten Formular konsistent

  • Das Symbol weist ein Kontrastverhältnis auf, das hoch genug ist, um sichtbar zu sein ( 3.0:1 für Nicht-Text-Elemente).

 <label for="email"> Email <svg class="required-icon" role="presentation" aria-hidden="true" focusable="false" … > <!-- … --> </svg> </label>

Wenn Sie ein Feld als optional markieren, reicht es aus, diesen Kontext als einfachen Text innerhalb der label zu platzieren.

 <label for="email">Email (Optional)</label>

Hörbarer Hinweis

Um einen Screenreader-Benutzer über ein erforderliches Feld zu informieren, können wir dem input einfach das Attribut aria-required hinzufügen. Dies informiert den Benutzer darüber, dass dieses Feld erforderlich ist, fügt jedoch nichts anderes in Bezug auf die Feldvalidierung hinzu.

 <label for="email">Email</label> <input type="email" id="email" name="email" aria-required="true" />

Wenn ein Screenreader auf diese input stößt , kann er etwas wie „E-Mail, Text bearbeiten, erforderlich“ ankündigen.

Zusätzliche Anweisungen

Neben dem visuellen Hinweis für jedes erforderliche Feld neben dem label empfiehlt es sich auch, oben Anweisungen zu platzieren, die den Benutzer über jeden Feldtyp informieren. Etwas in der Art von:

<!-- When marking as Required… --> <p aria-hidden="true">* denotes a required field</p>​ <!-- When marking as Optional… --> <p>All fields required unless described otherwise.</p>

Mit dieser Klartextnotiz haben Menschen mit kognitiven Beeinträchtigungen , ältere Generationen oder jemand, der neu im Internet ist, weniger Probleme zu verstehen, welche Felder obligatorisch sind, und verbringen daher weniger Zeit und Mühe mit dem Ausfüllen des Formulars.

Das required Attribut

Als Entwickler denken Sie jetzt vielleicht: „Warum verwenden Sie nicht einfach das in HTML integrierte required Attribut? Wird dadurch nicht auch ein erforderliches Feld angekündigt?“

Es ist wahr, dass das Einschließen des required Attributs ein ähnliches Ergebnis liefert wie die Verwendung von aria-required , wobei der Screenreader-Benutzer über ein erforderliches Feld informiert wird. Der Unterschied besteht darin, dass die Verwendung von aria-required es dem Entwickler ermöglicht, benutzerdefinierte Validierungsregeln einzufügen.

Vermeiden Sie native Validierung

Die Verwendung der benutzerdefinierten Validierung anstelle der integrierten Browservalidierung wird aus mehreren Gründen dringend bevorzugt:

  • Größere Kontrolle über Fehlermeldungen
  • Nachrichten können in mehrere Sprachen übersetzt werden
  • Konsistente und vorhersehbare Messaging-Implementierung
  • Nachrichten werden nicht nach kurzer Zeit aus der Ansicht entfernt

Aus diesen Gründen wird dringend empfohlen, eine benutzerdefinierte Formularvalidierung zu implementieren.

WCAG-Erfolgskriterien

Dies kommt auf 3.3.2 Etiketten oder Anweisungen zurück, wo es heißt:

„Etiketten oder Anweisungen werden bereitgestellt, wenn der Inhalt Benutzereingaben erfordert.“

Fehler

Das Design von Formularfehlermeldungen kann sehr heikel sein. Die Idee ist, das Bewusstsein auf den aktuellen Stand der Form zu lenken, ohne überwältigend zu wirken. Leider ist es sehr leicht, bei der Anzeige von Fehlerzuständen Frust oder Kummer zu verursachen, insbesondere bei denjenigen, die nicht so technisch versiert sind und bereits sehr vorsichtig und nervös sind, einen Computer zu verwenden.

Als Designer und Entwickler liegt es in unserer Verantwortung, unseren Benutzern den Einstieg in die von uns erstellten Systeme zu erleichtern und ihnen den Weg zu weisen, den wir ihnen vorgezeichnet haben.

Fehlermeldungen

Betrachten wir in diesem Sinne eine Designästhetik, die informell ist und ihr Bestes tut, um gleichzeitig nicht aufdringlich zu sein.

Drei Dinge, die Sie in diesem Abschnitt beachten sollten, sind:

  • Fehlertext
  • Eingabestile
  • Fehlerliste

Fehlertext

Fehlertext ist entscheidend, wenn ein Fehlerzustand übermittelt wird. Ohne diesen Text erkennen die Benutzer möglicherweise nicht, dass sich das Formular in einem Zustand befindet, in dem es nicht gesendet werden kann. Sicher, wir könnten die Farbe des input ändern, vielleicht seine border oder background so ändern, dass es als Fehlerzustand erkennbar ist. Wie wir jedoch bereits gesehen haben, ist es nicht ideal, sich nur auf Farbe zu verlassen, um Bedeutung zu vermitteln.

Wie stellen wir also sicher, dass der Eingabefehlerstatus richtig übermittelt wird? Ein paar Dinge, die wir tun können, sind:

  • Text ausgeben, der aussagekräftig ist und den Benutzer nicht mit Fachjargon überfordert ( kognitive Beeinträchtigung ).
  • Zeigen Sie den Text unter der entsprechenden Eingabe an ( Low-Vision ).
  • Stellen Sie sicher, dass der Text lesbar ist, indem Sie seinen Farbkontrast testen.
  • Fügen Sie optional ein Symbol hinzu, um die Aufmerksamkeit des Benutzers auf den Text zu lenken.

Fehlertext mit seiner Eingabe verbinden

Wenn jemand, der einen Bildschirmleser verwendet, mit einem input in einem Fehlerzustand in Kontakt kommt, muss diese Information zusammen mit dem label angesagt werden. Andernfalls besteht eine gute Chance, dass der Fehlerkontext beim Navigieren durch ein Formular verloren geht.

Es gibt ein paar Möglichkeiten, dies zu erreichen, aber am robustesten wäre es, das Attribut aria-describedby in das input aufzunehmen. Durch das Hinzufügen dieses Attributs wird der Fehlertext in die "Warteschlange" zum Ankündigen des Elements im Tastaturfokus platziert.

Um die Verbindung programmgesteuert herzustellen, muss der aria-describedby Wert mit der id des Fehlertextcontainers übereinstimmen.

Lassen Sie uns beispielsweise ein input in einem Fehlerzustand überprüfen.

Keine Verbindung

 <label for="fname">First name</label> <input type="text" id="fname" name="fname" /> <span id="error-fname" class="error">First name is required</span>

Diese input enthält eine label und einen Fehlertext direkt darunter. Der Text ist jedoch nicht in der Ankündigung des label enthalten, da keine programmatische Verbindung hergestellt wird.

Lassen Sie uns die Verbindung mit aria-describedby herstellen, einem Attribut, das verwendet wird, um mehr Informationen für den gegebenen Kontext bereitzustellen.

Verwenden von Arie-beschrieben von

 <label for="fname">First name</label> <input type="text" id="fname" name="fname" aria-invalid="true" aria-describedby="error-fname" /> <span id="error-fname" class="error">First name is required</span>

Wenn das Attribut aria-describedby auf die input angewendet wird und sein Wert mit der id des Fehlertextcontainers übereinstimmt, würde die Ansage eines Screenreaders wie folgt klingen:

"Vorname, ungültig, Text bearbeiten. Vorname ist erforderlich."

Einer der Vorteile der Verwendung von aria-describedby besteht darin, dass es eine kurze Pause zwischen dem label und dem Fehlertext einfügt, wodurch es in der Ankündigung ein wenig unterschieden wird.

Fehlerliste

Das Anzeigen einer Fehlerliste, wenn sich ein Formular in einem Fehlerzustand befindet, ist besonders bei großen Formularen hilfreich. Dieser Inhalt besteht aus einer Überschrift, die den aktuellen Zustand des Formulars erklärt, gefolgt von einer ungeordneten Linkliste.

Die Überschrift, normalerweise ein h2 -Element, ist die primäre Methode, um den Benutzer auf den Fehlerstatus aufmerksam zu machen. Sehende Benutzer sehen den großen Text, und nicht visuelle Benutzer erhalten den Tastaturfokus mithilfe der Fokusverwaltung automatisch auf diesen Teil des Bildschirms; Wenn die Überschrift dem Benutzer angezeigt wird, senden Sie den Fokus mithilfe der JavaScript-Methode focus() an das Überschriftenelement und wenden tabindex="-1" auf das Überschriftenelement an, damit es den Fokus erhält.

Der Listenteil besteht aus einem ul Element, das Links enthält. Jeder Link stellt einen einzelnen Fehler im Formular dar. Der Linktext sollte mit dem Fehlertext übereinstimmen, der unterhalb der zugehörigen input ausgegeben wird. Bei Aktivierung wechselt der Tastaturfokus vom Link zur zugehörigen input , sodass sich der Benutzer auf das vorliegende Problem konzentrieren und es ansprechen kann.

 <h2 class="form-message__title" tabindex="-1"> Please adjust the following: </h2> <ul> <li> <a href="#fname" class="form-message__link"> First name is required </a> </li> <!-- ... --> </ul> <!-- ... --> <label for="fname">First name</label> <input type="text" id="fname" name="fname" aria-invalid="true" aria-describedby="error-fname" /> <span id="error-fname" class="error">First name is required</span>

Die ideale Positionierung der Fehlerliste ist direkt über dem Formular, was der Benutzerfreundlichkeit dient. Wenn beispielsweise jemand, der einen Bildschirmleser verwendet, an der Fehlerliste vorbeigeht, wird er zum Formular mit seinen input geführt. Jede input würde von ihrem eigenen Fehlerzustandstext begleitet, der den Benutzer darüber informiert, wie der input werden kann, um seine Validierungsanforderungen zu erfüllen.

Die Fehlerliste in Kombination mit dem Fehlertext unter der input stellt sicher, dass der Benutzer über die aktuellen Fehler informiert wird, die Aufmerksamkeit erfordern, und beseitigt die kognitive Belastung, sich nicht an jeden Fehler erinnern zu müssen, der behoben werden muss; die Fehlermeldung wird verfügbar sein, wenn sie am input ankommen.

WCAG-Erfolgskriterien

Dies kommt auf 3.3.1 Fehleridentifikation zurück, wo es heißt:

"Wenn ein Eingabefehler automatisch erkannt wird, wird das fehlerhafte Element identifiziert und der Fehler wird dem Benutzer in Textform beschrieben."

Erfolgsmeldung

Genauso wichtig, aber manchmal vergessen, ist die Erfolgsmeldung. Wenn jemand das Formular vollständig und korrekt ausfüllt, sollte Text vorhanden sein, um den Benutzer über den aktuellen Status zu informieren.

Wie bei der Überschrift der Fehlerliste sollte auch die Erfolgsmeldung mit großem, aufmerksamkeitsstarkem Text gestaltet werden. Darüber hinaus sollte der Tastaturfokus im Auftrag des Benutzers verwaltet und auf das Überschriftenelement der Erfolgsmeldung gesetzt werden. Damit wird der Benutzer über das Absenden des Formulars informiert und kann getrost mit einer anderen Aufgabe fortfahren.

Das autocomplete Attribut

Die HTML-Autovervollständigung hilft Benutzern, das Ausfüllen von Formularen zu vervollständigen, indem sie im Browser gespeicherte Daten verwendet. Dies ist besonders nützlich für Menschen mit motorischen oder kognitiven Beeinträchtigungen , die möglicherweise Schwierigkeiten haben, Formulare online auszufüllen.

Beispielsweise muss eine Formulareingabe, die nach der E-Mail-Adresse einer Person fragt, das autocomplete -Attribut enthalten, um einen Hinweis an den Browser oder andere Benutzeragenten zu senden, um diese Daten abzufragen:

 <label for="email">Email</label> <input type="email" id="email" name="email" autocomplete="email" ... />

Damit haben Benutzer eine viel einfachere und komfortablere Benutzererfahrung, wenn der Browser ihrer Wahl sie auffordert, ihre E-Mail-Adresse in ihrem Namen einzugeben.

Lesen Sie den Abschnitt „ W3C HTML 5.12 – 4.10.18.7. Autofill “ für alle anderen Eingabetypen und ihre entsprechenden Autocomplete-Attributwerte.

Inline-Validierung und Bedeutung der Schaltfläche „Senden“.

Im modernen Formulardesign und in der Entwicklung, besonders häufig in SPA-App-Demos, gibt es insbesondere zwei Trends: Inline-Validierung von Formularsteuerelementen, nachdem sie „berührt“ wurden (im Wesentlichen, wenn sich der Benutzer von der input wegbewegt) und Beibehalten des Sendens Schaltfläche in einem deaktivierten Zustand (über das disabled Attribut), bis jeder Validierungstest erfüllt wurde.

Inline-Validierung

Wenn es darum geht, gut nutzbare und zugängliche Formulare zu erstellen, insbesondere für Menschen mit Behinderungen, wird empfohlen, keine Inline-Validierung zu verwenden. Dieses Muster kann den Benutzer manchmal etwas verwirren oder frustrieren. Einige Beispiele, die dies veranschaulichen, sind:

  • Wenn jemand, der einen Screenreader verwendet, durch ein Formular navigiert, um sich einen allgemeinen Überblick zu verschaffen, versucht, zu lesen, was jedes Feld ist und welche Daten erwartet werden
  • Jemand, der vielleicht Formularfelder in einer anderen Reihenfolge ausfüllen möchte
  • Wenn jemand ein Feld verlässt, um etwas nachzuschlagen, um sicher zu sein, welche Daten in das Formularsteuerelement eingefügt werden sollen

Diese einfachen Aktionen lösen die Fehlermeldung aus und das Ergebnis kann ziemlich irritierend sein

Bei Usability-Studien wird oft geschimpft oder laut geflucht, wenn Fehlermeldungen erscheinen, bevor man überhaupt mit dem Ausfüllen von Formularen begonnen hat!

Zusätzliche Zugänglichkeitsprobleme treten auf, wenn der Benutzer von einem Feld wegnavigiert; Die Fehlermeldung wird visuell angezeigt, aber normalerweise nicht für Hilfstechnologien. Um die Fehlermeldung zu hören, muss der Benutzer rückwärts durch das Formular navigieren. Dies wäre eine unerwartete erforderliche Aktion, um den Fehlerzustand zu hören und zu verstehen.

Deaktivierter Zustand

Wenn die button „Senden“ standardmäßig disabled ist, steht das Steuerelement erst zur Verfügung, nachdem alle Formularvalidierungsregeln erfüllt wurden. Wenn dieses Muster vorhanden ist, kann dies zu einer verwirrenden oder frustrierenden Benutzererfahrung führen. Es gibt keinen Hinweis darauf, warum das Steuerelement nach dem Ausfüllen des Formulars beim ersten Durchgang deaktiviert wird.

Folglich können behinderte Bedienelemente zwei zusätzliche Herausforderungen für Einzelpersonen darstellen:

  • Menschen mit Sehbehinderung können den Schaltflächentext im gedimmten Zustand möglicherweise nicht wahrnehmen.
  • Einige Hilfstechnologien überspringen disabled Elemente; Benutzer von Screenreadern erhalten möglicherweise kein vollständiges Bild von dem, was auf der Benutzeroberfläche verfügbar ist, was zu Unsicherheit oder Selbstzweifeln führt .

Berücksichtigung der Zugänglichkeit mit diesem Muster

Um einige dieser potenziellen Schmerzpunkte für Benutzer zu lindern, wird empfohlen, einen etwas anderen, hybriden Ansatz zu wählen. Erwägen Sie, die folgenden Änderungen an Ihrem Formular-Workflow vorzunehmen:

  • Wenn sich ein input im Fehlerzustand befindet, geben Sie den Text der Fehlermeldung wie zuvor beschrieben aus. Dies dient als Erinnerung an den Fehler und den erwarteten Wert, wenn zu dem Steuerelement navigiert wird, sowie an alle anderen Steuerelemente in einem Fehlerzustand, wenn der Benutzer sich durch den Formularinhalt bewegt.
  • Wenn sich der input von der Formulareingabe entfernt, führen Sie den Validierungstest aus. Wenn der Test fehlschlägt, geben Sie den Fehlertext visuell für sehende Benutzer aus, aber sehen Sie davon ab, Screenreader-Benutzern den neuen Zustand mitzuteilen.
  • Wenn Sie eine input eingeben, die sich in einem Fehlerzustand befindet, entfernen Sie jeglichen Fehlertext; Fehlertext nur anzeigen, wenn sich der Fokus von der input entfernt .
  • Lassen Sie zu, dass die vollständige Formularvalidierung beim Absenden des Formulars ausgeführt wird, indem Sie die button „Senden“ aktiviert lassen. Dadurch kann der Benutzer das Formular leicht erkunden und sich beim ersten Durchlauf mit der Formularstruktur vertraut machen. Auch wenn die Formularfelder Fehler enthalten, erlauben Sie den Benutzern, das Formular zu ihren Bedingungen zu senden, wenn sie sich dazu wohl fühlen.

Mit diesen Änderungen wird jeder, der sich auf Hilfstechnologien verlässt oder beim Ausfüllen eines Formulars etwas mehr Anleitung benötigt, ein klareres Verständnis dafür haben, wie das Formular strukturiert ist und den aktuellen Status des Formulars sowie eventuelle Fehler enthält und wie man sie anspricht.

Wenn beim Senden Änderungen vorgenommen werden müssen, wird der Fokus auf die Fehlerliste gehoben. Von dort aus lenken Fehlerlinks den Fokus direkt auf die betreffende input . Ab diesem Zeitpunkt werden Fehlermeldungen beim Durchlaufen des Formulars angesagt, und Änderungen an den Daten können leicht und mit größerer Sicherheit seitens des Benutzers vorgenommen werden.

Ressourcen:

Zurück zum Blog