{"id":22,"date":"2014-08-25T12:23:11","date_gmt":"2014-08-25T10:23:11","guid":{"rendered":"http:\/\/xmaz.de\/barrierefrei\/?page_id=22"},"modified":"2014-08-25T12:23:11","modified_gmt":"2014-08-25T10:23:11","slug":"usable-accessible-form-validation-error-recovery","status":"publish","type":"page","link":"https:\/\/immocado.com\/barrierefrei\/usable-accessible-form-validation-error-recovery\/","title":{"rendered":"Nutzbare und barrierefreie Formulare: Validierung und Fehlerbehebung"},"content":{"rendered":"<p>[Dies ist eine \u00dcbersetzung des englischsprachigen Artikels &#8222;<a href=\"http:\/\/webaim.org\/techniques\/formvalidation\/\"rel=\"nofollow\">Usable and Accessible Form Validation and Error Recovery<\/a>&#8222;. Copyright \u00a9 by www.Webaim.org]<\/p>\n<nav>\n<h2>Artikelinhalt<\/h2>\n<ol>\n<li><a href=\"#intro\">Einleitung<\/a><\/li>\n<li><a href=\"#usable\">Nutzbare Formulare bilden<\/a><\/li>\n<li><a href=\"#hiding\">Formularlabels verstecken <\/a><\/li>\n<li><a href=\"#form\">Formular-Validierung<\/a><\/li>\n<li><a href=\"#error\">Fehlerbehebung<\/a><\/li>\n<li><a href=\"#ariainvalid\">Aria-invalid<\/a><\/li>\n<li><a href=\"#summary\">Zusammenfassung<\/a><\/li>\n<\/ol>\n<\/nav>\n<div id=\"intro\" class=\"section\">\n<h2>Einleitung<\/h2>\n<p>Die Formular-Validierung ist ein Testverfahren, um sicherzustellen, dass Endnutzer die notwendigen Informationen im richtigen Format in Webformulare eingeben. Die Fehlerbehebung ist ein Prozess, der den Nutzer dahin f\u00fchrt, durch die Formular-Validierung erkannte, fehlende oder falsche Informationen zu korrigieren. Es gibt mehrere Methoden zur Durchf\u00fchrung der Formular-Validierung und zur Fehlerbehebung. Diese Methoden k\u00f6nnen normalerweise wie folgt kategorisiert werden:<br \/>\n1) Server-Seite: Die Formularinformation ist abgeschickt und durch einige Skriptsprachen (wie PHP, JSP, Perl, etc.) vom Webserver analysiert und mit der erforderlichen R\u00fcckmeldung wird eine neue Webseite generiert<br \/>\noder<br \/>\n2) Client-Seite: Die Formular-Validierung und die Fehlerbehebungsmechanismen werden innerhalb des Web-Clienten oder des Browsers mit JavaScript durchgef\u00fchrt. Es gibt Vorteile f\u00fcr jedes Verfahren.<\/p>\n<p>Vorteile der serverseitigen Validierung und Fehlerkorrektur:<\/p>\n<ul>\n<li>Das Formular kann ausgef\u00fcllt und ohne Unterbrechung von Validierungs-Benachrichtigungen, Fehlern oder Warnungen abgeschickt werden.<\/li>\n<li>Die Funktionalit\u00e4t erfordert nicht, dass Scripting aktiviert ist, oder auf dem Web-Browser unterst\u00fctzt wird.<\/li>\n<li>Mehr Sicherheit \u2013 die Validierungsmechanismen k\u00f6nnen nicht einfach umgangen, oder ver\u00e4ndert werden.<\/li>\n<\/ul>\n<p>Vorteile der clientseitigen Validierung und Fehlerkorrektur:<\/p>\n<ul>\n<li>Die Validierung kann auftreten, wenn die Formulare vollst\u00e4ndig ausgef\u00fcllt sind und bevor die Daten an den Server gesendet werden.<\/li>\n<li>Die Funktionalit\u00e4t erfordert kein serverseitiges Scripting.<\/li>\n<\/ul>\n<p>Einige Nutzer k\u00f6nnen Scripting deaktivieren. Daher sollten Entwickler kein clientseitiges Scripting erfordern, um das Web-Formular richtig vervollst\u00e4ndigen und abschicken zu k\u00f6nnen. Dar\u00fcber hinaus kann jede clientseitige Validierung, oder Information, leicht modifiziert oder deaktiviert werden. Web-Entwickler k\u00f6nnen die Vorteile von server- und clientseitiger Validierung und Fehlerbehebung nutzen, um sicherzustellen, dass ihre Formulare in einer nutzbaren und zug\u00e4nglichen Weise abgeschlossen sind.<\/p>\n<\/div>\n<div id=\"usable\" class=\"section\">\n<h2>Nutzbare Formulare bilden<\/h2>\n<p>Als Entwickler ist der erste Schritt, um sicherzustellen, dass ihre Formulare vollst\u00e4ndig korrekt sind, sie nutzerfreundlich und zug\u00e4nglich zu machen.<br \/>\nDies kann erreicht werden durch:<\/p>\n<ul>\n<li>Bereitstellung aller erforderlichen Anweisungen und Hinweise.<\/li>\n<li>Zuordnen von einem Textlabel zu Formular-Steuerelementen mit Hilfe der <a href=\"http:\/\/webaim.org\/techniques\/forms\"rel=\"nofollow\">Label-Elemente<\/a>.<\/li>\n<li>Gruppen von Checkboxen und Radio-buttons zuordnen, unter Verwendung von <a href=\"http:\/\/webaim.org\/techniques\/forms\/#labels\"rel=\"nofollow\">Fieldsets und Legenden<\/a>.<\/li>\n<li>Bereitstellung einer logischen Lese- und Navigationsordnung.<\/li>\n<li>Sicherstellen, dass das Formular nur mit der <a href=\"http:\/\/webaim.org\/techniques\/keyboard\/\"rel=\"nofollow\">Tastatur<\/a>\u00a0vollst\u00e4ndig ausgef\u00fcllt und abgeschickt werden kann.<\/li>\n<li>Pr\u00fcfen, ob die Formular-Steuerelemente, Etiketten und die Funktionalit\u00e4t verst\u00e4ndlich und nutzbar sind.<\/li>\n<\/ul>\n<p>Wenn ihr Formular verlangt, dass bestimmte Steuerelemente ausgef\u00fcllt oder ausgew\u00e4hlt werden, sollten Sie den Nutzer in einer nutzbaren, zug\u00e4nglichen und ersichtlichen Weise darauf hinweisen. Diese Anleitung sollte sich normalerweise neben und innerhalb des Etiketts des erforderlichen Formular-Steuerelements befinden. Da Screenreader-Nutzer von Formular-Steuerelement zu Formular-Steuerelement navigieren k\u00f6nnen, statt den Screenreader linear durch das Formular lesen zu lassen, kann der Screenreader diese wichtige Information nur dann vorlesen, wenn das Steuerelement den Fokus erh\u00e4lt und die Information innerhalb des Etiketts platziert ist. Das Etikett sollte ausreichend beschrieben und visuell deutlich sein.<\/p>\n<div class=\"example\">\n<div class=\"title\">Beispiel<\/div>\n<p class=\"markup\"><code>&lt;label for=\"firstname\"&gt;Vorname<br \/>\n&lt;span style=\"color:red\"&gt;(notwendig)&lt;\/span&gt;&lt;\/label&gt;&lt;br \/&gt;<br \/>\n&lt;input type=\"text\" name=\"firstname\" id=\"firstname\" \/&gt;<\/code><\/p>\n<p>angezeigt als:<\/p>\n<p><label for=\"firstname\">Vorname<br \/>\n<span style=\"color: red;\">(notwendig)<\/span><\/label><br \/>\n<input id=\"firstname\" name=\"firstname\" type=\"text\" \/><\/p>\n<p>Das <code>aria-required\u00a0<\/code>Attribut kann auch verwendet werden, um ben\u00f6tigte Felder f\u00fcr Screenreader-Nutzer anzugeben, besonders, wenn der Beschriftungstext dies nicht angibt, oder wenn nur Farbe oder Sternchen genutzt werden, um ben\u00f6tigte Felder anzuzeigen.<\/p>\n<\/div>\n<p>Wenn Informationen in Formulare eingegeben werden, m\u00fcssen die Daten in eine bestimmte Weise formatiert werden und ausreichende Anweisungen m\u00fcssen innerhalb des Etiketts des Steuerelements, oder innerhalb anderer zugeh\u00f6riger Inhalte (wie <code>aria-describedby<\/code>), angegeben werden. In vielen F\u00e4llen k\u00f6nnen Entwickler ihre Formulare vereinfachen, indem sie keine spezifische Formatierung erfordern. Wenn ein genaues Format (wie z.B. Telefonnummern) f\u00fcr den Eintrag in eine Datenbank erforderlich ist, kann zum Beispiel Scripting verwendet werden, um die vom Nutzer eingegebenen Daten neu zu formatieren und damit die Last vom Nutzer zu nehmen.<\/p>\n<\/div>\n<div id=\"hiding\" class=\"section\">\n<h2>Formularlabels verstecken<\/h2>\n<p>Es gibt einige F\u00e4lle, in denen Entwickler nicht wollen, dass Formularlabels sichtbar in ihren Formularen erscheinen. Dies ist \u00fcblich, wenn sie komplexe Formulare in Tabellen nutzen, in der Tabellen\u00fcberschriften die Funktion, oder den Zweck, von mehreren Formular-Steuerelementen in einer bestimmten Zeile oder Spalte angeben. Beim Ansehen von Tabellen\u00fcberschriften kann es optisch deutlich werden, welche Informationen in das Formular-Steuerelement eingegeben werden m\u00fcssen. Es kann m\u00fchsam sein, sich wiederholende Formularetiketten in einem komplexen Formular visuell sichtbar zu machen. Dies ist durch die Tatsache, dass einem Label-Element nur ein einziges Formular-Steuerelement zugeordnet werden kann, kompliziert. Allerdings, kann ein Screenreader den Zweck des Formular-Steuerelementes nicht erkennen, wenn das <code>&lt;label&gt;<\/code> -Element nicht vorhanden ist.<br \/>\nEs gibt mehrere Methoden um Formular-Labels (und andere Elemente) zu verstecken, damit sie optisch nicht auftreten, aber weiterhin von einem Screenreader abgerufen werden. Allerdings muss man immer vorsichtig sein, wenn Elemente visuell versteckt werden sollen. Sie sollten sich fragen, wieso die Information visuell nicht sinnvoll oder notwendig ist, aber jedoch f\u00fcr Screenreader-Nutzer. Sie m\u00fcssen sich auch dar\u00fcber bewusst sein, dass Formularlabels visuell zu verstecken einige Funktionen von der Seite entfernt \u2013 Nutzer k\u00f6nnen auf die Formularlabels klicken, um das zugeh\u00f6rige Formularsteuerelement sofort zu aktivieren, oder um darauf zugreifen zu k\u00f6nnen. Dies kann f\u00fcr Nutzer mit einigen Arten von motorischer Behinderung besonders hilfreich sein. <a href=\"http:\/\/webaim.org\/techniques\/css\/invisiblecontent\/\"rel=\"nofollow\">Lesen Sie mehr dar\u00fcber, Formularlabel sichtbar zu verstecken<\/a>.<\/p>\n<\/div>\n<div id=\"form\" class=\"section\">\n<h2>Formular-Validierung<\/h2>\n<p>Die Formular-Validierung stellt in der Regel keine Fragen zur Barrierefreiheit, da sie meist hinter den Kulissen arbeitet. Allerdings muss die Methode zum Aufrufen des Validierungsmechanismus barrierefrei zug\u00e4nglich sein. Das bedeutet, dass wenn Sie clientseitige Validierung nutzen, m\u00fcssen die Validierung und der Abgabeprozess sowohl \u00fcber die Maus, wie auch \u00fcber die Tastatur erreichbar sein.<\/p>\n<p>Da Sie sich in der Regel nicht sicher sein k\u00f6nnen, dass der Browser des Nutzers Scripting unterst\u00fctzt, muss das Formular zu einer realen URL f\u00fchren, wenn Scripting nicht verf\u00fcgbar ist. Sie sollten Formulare vermeiden, die sich f\u00fcr die Formularverarbeitung ausschlie\u00dflich auf Skriptfunktionen oder Ereignishandler verlassen, wie beispielsweise <code>&lt;form action=\"#\" onsubmit=\"validateform()\"&gt;<\/code>. Verwenden Sie stattdessen einen echten URL-Aktionswert f\u00fcr das Formular. Sie k\u00f6nnen die clientseitige Validierung immer noch aufrufen und diese wird als erstes verarbeitet, sofern Scripting aktiviert ist \u2013 <code>&lt;form action=\"submit.php\" onsubmit=\"return validateform()\"&gt;<\/code>.<\/p>\n<\/div>\n<div id=\"error\" class=\"section\">\n<h2>Fehlerbehebung<\/h2>\n<p>Wenn entweder die client- oder die serverseitige Validierung Fehler im Formular erkennt, gibt es ein 3-Schritt-Verfahren f\u00fcr die Gew\u00e4hrleistung einer nutzbaren und barrierefreien Fehlerbehebung:<\/p>\n<ol>\n<li>Benachrichtigung des Nutzers, dass ein Fehler vorhanden ist, in einer offensichtlichen und barrierefreien Weise.<\/li>\n<li>Lassen Sie den Nutzer in einfachen Weise Zugriff auf die Formular-Steuerelemente nehmen, die ver\u00e4ndert werden m\u00fcssen.<\/li>\n<li>Erlauben Sie die Wiedervorlage und die Revalidierung des Formulars.<\/li>\n<\/ol>\n<p>Es gibt drei einfache Wege, wie diese Anforderungen erf\u00fcllt werden k\u00f6nnen. Wir beschreiben diese als:<\/p>\n<ul>\n<li>Fehler melden, dann darauf fokussieren<\/li>\n<li>Fehlermeldungen auf der Seite<\/li>\n<li>Inline-Fehler<\/li>\n<\/ul>\n<p>Kein Ansatz ist der Beste f\u00fcr Barrierefreiheit, aber es k\u00f6nnte einen optimalen Ansatz geben, basierend auf dem Inhalt, dem Layout und der Komplexit\u00e4t der Formen, auf den sie angewendet werden.<\/p>\n<div class=\"section\">\n<h3>Fehler melden, dann darauf fokussieren<\/h3>\n<p>Der erste Schritt ist, den Benutzer zu informieren, dass es einen Fehler gibt. Diese Fehlermeldung sollte sichtbar, informativ und direkt zugreifbar sein. Eine Methode ist, eine JavaScript-Alert-Box, oder einen modalen Dialog zu verwenden, um den Nutzer \u00fcber einen Fehler zu informieren.<\/p>\n<div class=\"mediaobject\"><img decoding=\"async\" loading=\"lazy\" src=\"http:\/\/webaim.org\/techniques\/formvalidation\/media\/formvalidation2.gif\" alt=\"JavaScript alert indicating that required information was not submitted.\" width=\"300\" height=\"114\" \/><\/div>\n<p>Sie k\u00f6nnten dem Nutzer auch erm\u00f6glichen, Textantworten direkt in Skript-Prompts einzugeben.<\/p>\n<div class=\"mediaobject\"><img decoding=\"async\" loading=\"lazy\" src=\"http:\/\/webaim.org\/techniques\/formvalidation\/media\/formvalidation3.gif\" alt=\"JavaScript prompt for entering First Name\" width=\"300\" height=\"141\" \/><\/div>\n<p>Der Vorteil f\u00fcr den \u201eFehler melden, dann darauf fokussieren\u201c-Ansatz ist, das Nutzer direkt \u00fcber Fehler informiert werden und das Problem einfach und direkt beheben k\u00f6nnen. Der Hauptnachteil ist, dass jeweils nur ein Fehler angezeigt und behandelt werden kann.<\/p>\n<\/div>\n<div class=\"section\">\n<h3>Fehlermeldungen auf der Seite<\/h3>\n<p>Die Fehlermeldung kann auf der Webseite selbst geschrieben werden. Wenn clientseitiges Scripting verf\u00fcgbar ist, k\u00f6nnen Sie die Fehlermeldung auf die Seite schreiben, bevor das Formular abgeschickt wird. Wen serverseitiges Scripting aktiviert ist, regenerieren Sie normalerweise die Formularseite um das urspr\u00fcngliche Formular und die entsprechende Nachricht einzubeziehen. Feedback-Seiten, die nur die Fehlermeldung anzeigen und den Nutzer bitten, die Zur\u00fcck-Taste zu dr\u00fccken, um den Fehler zu beheben, k\u00f6nnen problematisch sein. Sie erfordern, dass der Nutzer sich an alle gemeldeten Fehler erinnert, dann auf die vorherige Seite zur\u00fcck geht und findet, wo die Fehler aufgetreten sind. Es ist normalerweise am besten, die Seite so zu regenerieren, dass das Formular \u00e4hnlich aussieht und funktioniert wie das urspr\u00fcngliche Formular und so abgesendet wurde, dass vorher richtig ausgef\u00fcllte Elemente nicht ver\u00e4ndert werden.<\/p>\n<p>Wie man vermuten kann, veranlasst die \u201eFehlermeldung auf der Seite\u201c-Methode die Fehlermeldung vor dem Formular zu erscheinen. Wenn die Fehlermeldung erscheint, sollte der Fokus im Normalfall direkt auf der Fehlermeldung sein. Dies erlaubt den Nutzern von Bildschirmleseger\u00e4ten und Tastaturen sofort auf die Fehlermeldung zuzugreifen, ohne das diese zwischen dem \u00fcbrigen Inhalt der Seite suchen m\u00fcssen. Die Nachricht sollte auch optisch deutlich sein. Der Fokus kann mit clientseitigem Scripting, mit JavaScript focus() oder \u00e4hnlichem, auf die Nachricht gesetzt werden, oder es wird ein Ankername in die URL der servergenerierten Seite eingef\u00fcgt (z.B. http:\/\/myserver.com\/form.php#errormessage), welcher den Fokus direkt auf einen benannten Anker die Element-ID setzt, das sich am Anfang der R\u00fcckmeldung befindet.<\/p>\n<p>Die Fehlermeldung sollte die aufgetretenen Fehler klar beschreiben und optimaler Weise Hinweise oder Anweisungen zu ihrer L\u00f6sung liefern. Zum Beispiel ist die Meldung \u201eDie Kursnummer ist nicht korrekt formatiert\u201c weniger hilfreich, als die Meldung \u201eDie Kursnummer muss eine 3-stellige Zahl sein\u201c. Es ist auch hilfreich, den Nutzer \u00fcber die Anzahl der entdeckten Fehler zu informieren.<\/p>\n<p>Sobald der Nutzer die Fehlermeldung gesehen hat, m\u00fcssen Sie einen Mechanismus bereitstellen, welcher es dem Nutzer erm\u00f6glicht, schnell auf das falsch ausgef\u00fcllte Formular-Steuerelement zuzugreifen und den Fehler zu beheben. Sie k\u00f6nnen einen Link innerhalb der Fehlermeldung bereitstellen, der den Fokus auf das entsprechende Formular-Steuerelement legt. W\u00e4hrend dies beim clientseitigen Scripting durchgef\u00fchrt werden kann, ist es normalerweise einfacher (und sicherer) einfach einen Link anzugeben, der den Fokus auf das Formular-Steuerelement setzt (welches durch eine eindeutige ID und\/oder den eindeutigen Namen identifiziert wird).<\/p>\n<div class=\"mediaobject\"><img decoding=\"async\" loading=\"lazy\" src=\"http:\/\/webaim.org\/techniques\/formvalidation\/media\/formvalidation4.gif\" alt=\"Example of a feedback message which provides links directly to the form controls that need to be addressed.\" width=\"400\" height=\"199\" \/><\/div>\n<p>Der Vorteil des \u201eFehlermeldungen auf der Seite\u201c-Ansatzes ist, dass alle Fehler zusammen pr\u00e4sentiert werden. Der Nachteil ist, dass es f\u00fcr den Nutzer schwer werden kann, sich an alle Fehler zu erinnern, alle zu finden und alle zu beheben, wenn mehrere Fehler auftreten.<\/p>\n<\/div>\n<div class=\"section\">\n<h3>Inline-Fehler<\/h3>\n<p>Ein anderer Ansatz ist es, die Fehlermeldungen im Formular im Kontext des Formular-Steuerelements anzuzeigen, welches Aufmerksamkeit ben\u00f6tigt. Dieser Ansatz erfordert optisch markante Fehlermeldungen, damit der Fokus unmittelbar auf ihnen landet. Die Fehlermeldung muss mit den jeweiligen Steuerelementen verkn\u00fcpft werden (durch Etikettierung oder vielleicht durch <code>aria-describedby<\/code>. Es kann hilfreich sein, den Fokus auf das erste Steuerelement zu setzen, das Aufmerksamkeit ben\u00f6tigt.<\/p>\n<p>Der Vorteil des \u201eInline-Fehler\u201c-Ansatzes ist, dass die Fehler im Zusammenhang mit ihren jeweiligen Steuerelementen angezeigt werden. Der Nachteil ist, dass Benutzer das Formular visuell \u00fcberfliegen oder navigieren m\u00fcssen, um die fehlerhaften Steuerelemente und ihre jeweiligen Fehlermeldungen zu finden. Dies kann einige Zeit in Anspruch nehmen.<\/p>\n<\/div>\n<\/div>\n<div id=\"ariainvalid\" class=\"section\">\n<h2>aria-invalid<\/h2>\n<p>Unabh\u00e4ngig zum Mechanismus, der verwendet wird, um Formularfehler zu identifizieren und zu beheben, sollte aria-invalid=\u201ctrue\u201c in der Regel auf jedes ung\u00fcltige Formular-Steuerelement gesetzt werden. Dieses Attribut bewirkt, dass Screenreader das Steuerelement als \u201eung\u00fcltig\u201c identifiziert und feststellt, dass es notwendig ist, dem Steuerelement Aufmerksamkeit zu widmen.<\/p>\n<\/div>\n<div id=\"summary\" class=\"section\">\n<h2>Zusammenfassung<\/h2>\n<p>In allen F\u00e4llen k\u00f6nnen Sie sorgf\u00e4ltige Benutzertests auf Schwierigkeiten oder Probleme ihrer Formular-Nutzbarkeit, der Validierung und der Fehlerkorrektur-Mechanismen aufmerksam machen. W\u00e4hrend sich dieser Artikel nur mit wenigen der vielen Variationen besch\u00e4ftigt, die genutzt werden k\u00f6nnen, um die Formular-Nutzbarkeit, die Validierung und einer barrierefreien und nutzerfreundlichen Fehlerbehebung sicherzustellen, sollten die folgenden allgemeinen Grunds\u00e4tze angewendet werden:<\/p>\n<ul>\n<li>Erstellen Sie Formulare, die einfach und intuitiv sind. Geben Sie alle notwendigen Anweisungen, Hinweise und Eingabeaufforderungen an.<\/li>\n<li>Stellen Sie sicher, dass die Formulare f\u00fcr Tastaturen zug\u00e4nglich sind.<\/li>\n<li>Verbinden Sie <label>Formularelemente mit Formular-Steuerelementen.<\/label><\/li>\n<li>Verwenden Sie Fieldsets und Legenden, um Gruppen von Checkboxen und Radio-Buttons zu verkn\u00fcpfen.<\/li>\n<li>Geben Sie notwendige Anweisungen innerhalb der <code>&lt;label&gt;-<\/code>Formularelemente an (z.B. erforderliche oder speziell formatierte Steuerelemente).<\/li>\n<li>Verlassen Sie sich nicht nur auf JavaScript f\u00fcr die Formular-Abgabe, Validierung und Fehlerbehebung.<\/li>\n<li>Alarmieren Sie den Nutzer \u00fcber die Validierungsfehler in einer offensichtlichen und barrierefreien Weise.<\/li>\n<li>Lassen Sie die Nutzer auf einfache Weise auf die Formular-Steuerelemente zugreifen, die ge\u00e4ndert werden m\u00fcssen.<\/li>\n<li>Erlauben Sie Wiedervorlage und Revalidierung der Formularinformationen<\/li>\n<\/ul>\n<\/div>\n<div id=\"related\">\n<h2>Verwandte Ressourcen<\/h2>\n<ul>\n<li><a href=\"http:\/\/webaim.org\/techniques\/forms\/\"rel=\"nofollow\">Erstellen von barrierefreien Formularen<\/a><\/li>\n<li><a href=\"http:\/\/webaim.org\/techniques\/keyboard\/\"rel=\"nofollow\">Zug\u00e4nglichkeit\u00a0f\u00fcr Tastaturen<\/a><\/li>\n<li><a href=\"http:\/\/webaim.org\/articles\/screenreader_testing\/\"rel=\"nofollow\">Testen mit Screenreadern<\/a><\/li>\n<\/ul>\n<\/div>\n","protected":false},"excerpt":{"rendered":"<p>[Dies ist eine \u00dcbersetzung des englischsprachigen Artikels &#8222;Usable and Accessible Form Validation and Error Recovery&#8222;. Copyright \u00a9 by www.Webaim.org] Artikelinhalt Einleitung Nutzbare Formulare bilden Formularlabels verstecken Formular-Validierung Fehlerbehebung Aria-invalid Zusammenfassung Einleitung Die Formular-Validierung ist ein Testverfahren, um sicherzustellen, dass Endnutzer die notwendigen Informationen im richtigen Format in Webformulare eingeben. Die Fehlerbehebung ist ein Prozess, der [&hellip;]<\/p>\n","protected":false},"author":1,"featured_media":0,"parent":0,"menu_order":0,"comment_status":"closed","ping_status":"closed","template":"","meta":[],"_links":{"self":[{"href":"https:\/\/immocado.com\/barrierefrei\/wp-json\/wp\/v2\/pages\/22"}],"collection":[{"href":"https:\/\/immocado.com\/barrierefrei\/wp-json\/wp\/v2\/pages"}],"about":[{"href":"https:\/\/immocado.com\/barrierefrei\/wp-json\/wp\/v2\/types\/page"}],"author":[{"embeddable":true,"href":"https:\/\/immocado.com\/barrierefrei\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/immocado.com\/barrierefrei\/wp-json\/wp\/v2\/comments?post=22"}],"version-history":[{"count":0,"href":"https:\/\/immocado.com\/barrierefrei\/wp-json\/wp\/v2\/pages\/22\/revisions"}],"wp:attachment":[{"href":"https:\/\/immocado.com\/barrierefrei\/wp-json\/wp\/v2\/media?parent=22"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}