{"id":9010,"date":"2024-03-23T17:59:29","date_gmt":"2024-03-23T15:59:29","guid":{"rendered":"https:\/\/www.netz-barrierefrei.de\/wordpress\/?p=9010"},"modified":"2024-04-05T14:00:16","modified_gmt":"2024-04-05T12:00:16","slug":"fehler-management-in-der-digitalen-barrierefreiheit","status":"publish","type":"post","link":"https:\/\/www.netz-barrierefrei.de\/wordpress\/fehler-management-in-der-digitalen-barrierefreiheit\/","title":{"rendered":"Fehler-Management in der digitalen Barrierefreiheit"},"content":{"rendered":"<p><iframe loading=\"lazy\" src=\"https:\/\/digitale-barrierefreiheit.podigee.io\/221-fehler-management-in-der-digitalen-barrierefreiheit\/embed?context=external&#038;theme=default\" style=\"border: 0\" frameBorder=\"0\" height=\"100\" width=\"100%\"><\/iframe><br \/>\nMeines Erachtens geh\u00f6rt das Fehlermanagement nicht in die digitale Barrierefreiheit, sondern gilt f\u00fcr alle Nutzenden. Es ist ja eher tragi-komisch, dass wir seit fast 30 Jahren digitale Formulalre haben und trotzdem jeden Tag Formulare finden, wo die grundlegenden Patterns eines guten Fehlermanagements nicht beachtet werden. <\/p>\n<div id=\"ez-toc-container\" class=\"ez-toc-v2_0_86 counter-hierarchy ez-toc-counter ez-toc-white ez-toc-container-direction\">\n<div class=\"ez-toc-title-container\">\n<p class=\"ez-toc-title\" style=\"cursor:inherit\">Inhalt<\/p>\n<span class=\"ez-toc-title-toggle\"><a href=\"#\" class=\"ez-toc-pull-right ez-toc-btn ez-toc-btn-xs ez-toc-btn-default ez-toc-toggle\" aria-label=\"Toggle Table of Content\"><span class=\"ez-toc-js-icon-con\"><span class=\"\"><span class=\"eztoc-hide\" style=\"display:none;\">Toggle<\/span><span class=\"ez-toc-icon-toggle-span\"><svg style=\"fill: #999;color:#999\" xmlns=\"http:\/\/www.w3.org\/2000\/svg\" class=\"list-377408\" width=\"20px\" height=\"20px\" viewBox=\"0 0 24 24\" fill=\"none\"><path d=\"M6 6H4v2h2V6zm14 0H8v2h12V6zM4 11h2v2H4v-2zm16 0H8v2h12v-2zM4 16h2v2H4v-2zm16 0H8v2h12v-2z\" fill=\"currentColor\"><\/path><\/svg><svg style=\"fill: #999;color:#999\" class=\"arrow-unsorted-368013\" xmlns=\"http:\/\/www.w3.org\/2000\/svg\" width=\"10px\" height=\"10px\" viewBox=\"0 0 24 24\" version=\"1.2\" baseProfile=\"tiny\"><path d=\"M18.2 9.3l-6.2-6.3-6.2 6.3c-.2.2-.3.4-.3.7s.1.5.3.7c.2.2.4.3.7.3h11c.3 0 .5-.1.7-.3.2-.2.3-.5.3-.7s-.1-.5-.3-.7zM5.8 14.7l6.2 6.3 6.2-6.3c.2-.2.3-.5.3-.7s-.1-.5-.3-.7c-.2-.2-.4-.3-.7-.3h-11c-.3 0-.5.1-.7.3-.2.2-.3.5-.3.7s.1.5.3.7z\"\/><\/svg><\/span><\/span><\/span><\/a><\/span><\/div>\n<nav><ul class='ez-toc-list ez-toc-list-level-1 ' ><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-1\" href=\"https:\/\/www.netz-barrierefrei.de\/wordpress\/fehler-management-in-der-digitalen-barrierefreiheit\/#Die_WCAG_zum_Thema_Fehler\" >Die WCAG zum Thema Fehler<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-2\" href=\"https:\/\/www.netz-barrierefrei.de\/wordpress\/fehler-management-in-der-digitalen-barrierefreiheit\/#Fehler-Toleranz\" >Fehler-Toleranz<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-3\" href=\"https:\/\/www.netz-barrierefrei.de\/wordpress\/fehler-management-in-der-digitalen-barrierefreiheit\/#Fehler-Management\" >Fehler-Management<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-4\" href=\"https:\/\/www.netz-barrierefrei.de\/wordpress\/fehler-management-in-der-digitalen-barrierefreiheit\/#Fehler-Meldungen\" >Fehler-Meldungen<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-5\" href=\"https:\/\/www.netz-barrierefrei.de\/wordpress\/fehler-management-in-der-digitalen-barrierefreiheit\/#Pflichtangaben_kennzeichnen\" >Pflichtangaben kennzeichnen<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-6\" href=\"https:\/\/www.netz-barrierefrei.de\/wordpress\/fehler-management-in-der-digitalen-barrierefreiheit\/#Zusammenfassung_der_Eingaben\" >Zusammenfassung der Eingaben<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-7\" href=\"https:\/\/www.netz-barrierefrei.de\/wordpress\/fehler-management-in-der-digitalen-barrierefreiheit\/#Anwendungen\" >Anwendungen<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-8\" href=\"https:\/\/www.netz-barrierefrei.de\/wordpress\/fehler-management-in-der-digitalen-barrierefreiheit\/#Server-_und_andere_Fehlermeldungen\" >Server- und andere Fehlermeldungen<\/a><\/li><\/ul><\/nav><\/div>\n<h2><span class=\"ez-toc-section\" id=\"Die_WCAG_zum_Thema_Fehler\"><\/span>Die WCAG zum Thema Fehler<span class=\"ez-toc-section-end\"><\/span><\/h2>\n<p>Die folgenden WCAG-Kriterien gelten speziell f\u00fcr das Fehler-Management.<br \/>\n3.3 Fehler identifizieren und beschreiben (Error Identification)<br \/>\n\u2022Dieses Kriterium besagt, dass Fehler in Formularen so identifiziert und beschrieben werden m\u00fcssen, dass Benutzerinnen verstehen k\u00f6nnen, was falsch ist und wie sie den Fehler beheben k\u00f6nnen. Zum Beispiel sollten Benutzerinnen dar\u00fcber informiert werden, wenn sie ein Pflichtfeld leer gelassen haben oder wenn ihre Eingabe ung\u00fcltig ist.<br \/>\n3.3.1 Fehlererkennung (Error Suggestion)<br \/>\n\u2022Dieses Kriterium verlangt, dass Benutzern bei der Eingabe von Daten in Formularen Fehler automatisch erkannt werden, und ihnen Vorschl\u00e4ge zur Fehlerbehebung gemacht werden. Zum Beispiel k\u00f6nnte eine Webseite Benutzern eine Fehlermeldung anzeigen, wenn ihre E-Mail-Adresse ein ung\u00fcltiges Format hat, und ihnen dann vorschlagen, die Adresse zu \u00fcberpr\u00fcfen und erneut einzugeben.<br \/>\n3.3.2 Labels oder Anweisungen (Labels or Instructions)<br \/>\n\u2022Dieses Kriterium legt fest, dass Formularelemente (wie Textfelder, Dropdown-Listen usw.) klar beschriftet oder mit Anweisungen versehen sein m\u00fcssen, damit Benutzer verstehen, welche Art von Informationen erwartet werden. Klare Beschriftungen helfen Benutzern auch dabei, Fehler in <\/p>\n<h2><span class=\"ez-toc-section\" id=\"Fehler-Toleranz\"><\/span>Fehler-Toleranz<span class=\"ez-toc-section-end\"><\/span><\/h2>\n<p>Formulare sollten wo m\u00f6glich fehlertolerant sein. In der Regel spielt es zum Beispiel keine Rolle, ob jemand seine Telefonnummer mit Schr\u00e4gstrich, Bindestrich oder anderen Zeichen dazwischen schreibt. Wenn man in Deutschland lebt, ist es auch relativ unwahrscheinlich, dass man eine andere L\u00e4ndervorwahl hat &#8211; m\u00f6glich ja, wahrscheinlich nein. Dennoch muss man z.B. bei der Deutschen Bahn seine L\u00e4nder-Vorwahl eintragen. Manche Bank m\u00f6chte keine Leerzeichen in der IBAN, mancher Onlineshop m\u00f6chte keine Leerzeichen in der Kreditkarten-Nummer. Wenn aus irgendeinem Grund eindeutige Nummern notwendig w\u00e4ren, k\u00f6nnte das \u00fcber die Programmierung problemlos herausgefiltert werden.<br \/>\nUnabh\u00e4ngig davon sollte immer direkt beim Eingabefeld erl\u00e4utert werden, welche Zeichen erlaubt oder verboten sind. Oft kommt es bei Passwort-Vergaben vor, dass zwar alle m\u00f6glichen Zeichen gefordert, aus unerfindlichen Gr\u00fcnden aber auch bestimmte Sonderzeichen verboten sind. Zus\u00e4tzliche Angaben m\u00fcssen ebenso wie Fehlermeldungen \u00fcber ARIA described by eindeutig mit dem zugeh\u00f6rigen Eingabefeld verkn\u00fcpft werden.<br \/>\nH\u00e4ufig m\u00fcssen Eingaben in Namensfeldern mindestens drei Zeichen haben, aber viele Asiatinnen haben Namen mit nur zwei Zeichen. Ein gro\u00dfer Unsinn sind auch Select-Felder mit der Auswahl des Landes, in denen alle 300 staatlichen Entit\u00e4ten der Welt in alphabetischer Folge hinterlegt sind. Das mag bei der UNO Sinn machen, aber das jemand ein deutsches Formular ausf\u00fcllt und aus Mikronesien stammt ist sehr unwahrscheinlich. Sowas lie\u00dfe sich mit einer Auto-Suggest wesentlich besser l\u00f6sen: Man gibt etwa BRA ein und bekommt alle Staaten angezeigt, die mit Bra anfangen. Select-Felder sind nur f\u00fcr \u00fcberschaubare Mengen an Optionen sinnvoll. Zumindest sollten bei einem solchen Select-Feld die naheliegenden Optionen am Anfang stehen, bei einer deutsch-sprachigen Person also Deutschland, Schweiz, \u00d6sterreich und weitere Staaten, in denen Deutsch zu den offiziellen Sprachen geh\u00f6rt.<br \/>\nWo m\u00f6glich sollten mehrere Eingabe-M\u00f6glichkeiten angeboten werden. Leider muss man sagen, dass zum Beispiel die meisten Kalender-Widgets aus JavaScript-Bibliotheken nicht vern\u00fcnftig mit der Tastatur bedienbar sind. Es sollte m\u00f6glich sein, ein Datum einfach per Tastatur einzugeben. Alternativ gibt es auch die M\u00f6glichkeit, mit Select-Elementen oder mit Input-Feldern mit dem Attribut Date zu arbeiten.<br \/>\nWo m\u00f6glich sollte man eindeutige HTML-Elemente f\u00fcr die Eingabefelder verwenden. Diese k\u00f6nnen beim Korrigieren der Eingaben hilfreich sein oder beim automatischen Ausf\u00fcllen helfen. In HTML gibt es derzeit Attribute f\u00fcr Mail, Telefon und URLs.<br \/>\nDas WCAG-Kriterium 1.3.5 &#8211; Identifizierung von Eingabefeldern (Level AA) fordert die Hinterlegung von maschinen-lesbaren Attributen, um den Zweck von Eingabefeldern eindeutig identifizierbar zu machen, wenn sie sich auf die Nutzerin beziehen: Zum Beispiel Name, Wohnort, Telefonnummer und so weiter. Pers\u00f6nlich halte ich das f\u00fcr komplett \u00fcberfl\u00fcssig: Sowohl die Browser als auch die assistive Technologien verf\u00fcgen \u00fcber entsprechende Funktionalit\u00e4ten, aber vielleicht ist das bei den zust\u00e4ndigen Leuten noch nicht angekommen. Eine Liste der Attribute <a href=\"https:\/\/developer.mozilla.org\/en-US\/docs\/Web\/HTML\/Reference\/Attributes\/autocomplete\">gibt es beim Mozilla Developer Network<\/a>.<br \/>\nLabels, also Beschriftungen, sollten eindeutig und verst\u00e4ndlich sein. Schreiben Sie lieber &#8222;Vorname&#8220; statt &#8222;Name&#8220; oder &#8222;Stra\u00dfe&#8220; statt &#8222;Anschrift&#8220;, wenn genau diese Angaben gemeint sind. <\/p>\n<h2><span class=\"ez-toc-section\" id=\"Fehler-Management\"><\/span>Fehler-Management<span class=\"ez-toc-section-end\"><\/span><\/h2>\n<p>Bei langen Formularen sollten alle Fehler sowie die Stellen, an denen sie zu finden sind am Anfang zusammengefasst werden. F\u00fcr verschiedene behinderte Menschen &#8211; und nicht nur f\u00fcr sie &#8211; ist es schwierig bis unm\u00f6glich, ein langes Formular zu \u00fcberblicken. Au\u00dferdem sollte man mit Sprungankern direkt zu den Fehlerhaften Stellen gef\u00fchrt werden. Wenn es technisch m\u00f6glich ist, w\u00e4re es am besten, wenn nur noch die fehlerhaften Felder angezeigt werden. Pers\u00f6nlich finde ich heutzutage eine dynamische Validierung sinnvoller als das serverseitig zu machen. Es ist \u00f6kologischer und auch barrierefreier: Der Screenreader muss jede neu aufgerufene Seite einmal komplett buffern, die blinde Nutzerin muss jede neu geladene Seite ein St\u00fcck weit neu erkunden und zum Beispiel das Formular ansteuern.<br \/>\nLange Formulare sollten \u00fcber mehrere Unterseiten verteilt werden. Ob es nun statische Seiten oder Tabs sind, ist Geschmackssache. Wichtig ist allerdings, dass einmal get\u00e4tigte Eingaben automatisch gespeichert werden. Bei statischen und neu geladenen Webseiten sollten Fehlermeldungen direkt im Dokumenten-Titel sowie in der wichtigsten \u00dcberschrift untergebracht werden. Bei dynamischen Webseiten kann ARIA alert verwendet werden. <\/p>\n<h2><span class=\"ez-toc-section\" id=\"Fehler-Meldungen\"><\/span>Fehler-Meldungen<span class=\"ez-toc-section-end\"><\/span><\/h2>\n<p>Fehlermeldungen sollten so kurz wie m\u00f6glich, verst\u00e4ndlich und hilfreich sein. Bei einem Datum braucht man zum Beispiel ggf. ein Beispiel daf\u00fcr, wie eine korrekte Eingabe aussieht, zum Beispiel TT.MM.JJJJ.<br \/>\nFehlermeldungen d\u00fcrfen nicht nur \u00fcber Farbe oder andere sensorische Merkmale wie ein eingeblendetes Symbol gekennzeichnet werden. &#8222;Pr\u00fcfen Sie die rot markierten Felder&#8220; wie bei der Deutschen Bahn ist ein No-Go, aber leider nicht nur dort zu finden.<br \/>\nF\u00fcgen Sie einen Text wie &#8222;Fehler: Korrigieren Sie bitte &#8230;&#8220; oder \u00e4hnlich mit hilfreichen Infos hinzu. Wie oben erw\u00e4hnt muss die Fehlermeldung, wenn sie beim jeweiligen Element steht, wo der Fehler aufgetreten ist mit ARIA described by mit dem zugeh\u00f6rigen Eingabefeld verkn\u00fcpft werden. <\/p>\n<h2><span class=\"ez-toc-section\" id=\"Pflichtangaben_kennzeichnen\"><\/span>Pflichtangaben kennzeichnen<span class=\"ez-toc-section-end\"><\/span><\/h2>\n<p>Bei Pflichtangaben sind zwei Wege zu unterscheiden, die beide erf\u00fcllt werden sollten:<\/p>\n<ul>\n<li>Wenn Symbole wie der Stern verwendet werden, muss die Bedeutung des Symbols AM ANFANG des Formulars beschrieben werden. Wenn alle Felder Pflichtfelder sind, muss dies ebenfalls am Anfang beschrieben werden. Tats\u00e4chlich wird empfohlen, Pflichtfelder textlich wie etwa &#8222;Name (Pflichtfeld)&#8220; zu kennzeichnen, wobei Pflichtfeld Teil des maschinenlesbaren Labels ist. <\/li>\n<li>Unabh\u00e4ngig davon sollten alle Pflichtfelder auch maschinen-lesbar als solche gekennzeichnet werden, zum Beispiel \u00fcber ARIA required<\/li>\n<\/ul>\n<h2><span class=\"ez-toc-section\" id=\"Zusammenfassung_der_Eingaben\"><\/span>Zusammenfassung der Eingaben<span class=\"ez-toc-section-end\"><\/span><\/h2>\n<p>Bei komplexen und mit Geld verbundenen Eingaben sollten die Eingaben am Ende noch einmal zusammengefasst dargestellt werden. Dabei ist es wichtig, dass zum Beispiel Tabellen richtig formatiert sind. Tabelen werden etwa verwendet, um Informationen wie eingekaufte Produkte, zugeh\u00f6rige Preise und Mehrwertsteuer strukturiert darzustellen. <\/p>\n<h2><span class=\"ez-toc-section\" id=\"Anwendungen\"><\/span>Anwendungen<span class=\"ez-toc-section-end\"><\/span><\/h2>\n<p>Bez\u00fcglich Anwendungen hilft uns die WCAG leider nicht weiter. Hier w\u00fcrde ich pr\u00fcfen, wie schwerwiegend die Fehler sind. K\u00f6nnen zum Beispiel Dokumente nicht gespeichert oder Mails nicht verschickt werden, w\u00fcrde ich einen Dialog empfehlen, der durch die Nutzerin aktiv weggeklickt werden muss. Und nat\u00fcrlich hilfreich sein sollte, auch das leider eine Seltenheit.<br \/>\nHandelt es sich um nicht-kritische Fehler, k\u00f6nnen auch Toast-Messages verwendet werden, darauf bin ich <a href=\"https:\/\/www.netz-barrierefrei.de\/wordpress\/toast-messages-sind-nicht-barrierefrei\/\">hier ausf\u00fchrlich eingegangen<\/a>. Nicht-kritisch ist vielleicht eine sehr langsame Internet-Verbindung oder \u00c4hnliches. <\/p>\n<h2><span class=\"ez-toc-section\" id=\"Server-_und_andere_Fehlermeldungen\"><\/span>Server- und andere Fehlermeldungen<span class=\"ez-toc-section-end\"><\/span><\/h2>\n<p>Auch andere Fehlermeldungen sollten verst\u00e4ndlich und hilfreich sein. Nerds k\u00f6nnen mit 500, 400 oder 301 etwas anfangen. Normalsterbliche wissen allerdings nicht, was diese Serverfehler bedeuten und hilfreich sind sie auch nicht.<br \/>\nDas gilt entsprechend f\u00fcr alle Fehler-Meldungen, die auf Webseiten erzeugt werden. Die meisten h\u00e4ufig auftretenden Fehler lassen sich identifizieren. Und tun Sie mir bitte einen Gefallen: Schieben Sie die Fehler nicht auf die Nutzerinnnen. Hinweise wie &#8222;Wahrscheinlich haben Sie die URL falsch eingetippt&#8220; bei 404-Fehlermeldungen sind unh\u00f6flich und in aller Regel falsch. Wann haben Sie das letzte Mal eine l\u00e4ngere URL selbst eingetippt? Eben, es liegt eigentlich immer am Anbieter, der Seiten gel\u00f6scht und nicht umgeleitet hat.<br \/>\nAuch andere Hinweise etwa auf Werbeblocker, ausgeschaltetes JavaScript oder fehlende Rechte zur Anzeige von Social-Media-Inhalte sollten so formuliert werden, dass sie f\u00fcr Nicht-Techies verst\u00e4ndlich sind. <\/p>\n","protected":false},"excerpt":{"rendered":"<p>Meines Erachtens geh\u00f6rt das Fehlermanagement nicht in die digitale Barrierefreiheit, sondern gilt f\u00fcr alle Nutzenden. Es ist ja eher tragi-komisch, dass wir seit fast 30&#8230;<\/p>\n<div class=\"more-link-wrapper\"><a class=\"more-link\" href=\"https:\/\/www.netz-barrierefrei.de\/wordpress\/fehler-management-in-der-digitalen-barrierefreiheit\/\">Weiterlesen<span class=\"screen-reader-text\">Fehler-Management in der digitalen Barrierefreiheit<\/span><\/a><\/div>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"class_list":["post-9010","post","type-post","status-publish","format-standard","hentry","category-allgemein","entry"],"_links":{"self":[{"href":"https:\/\/www.netz-barrierefrei.de\/wordpress\/wp-json\/wp\/v2\/posts\/9010","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.netz-barrierefrei.de\/wordpress\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.netz-barrierefrei.de\/wordpress\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.netz-barrierefrei.de\/wordpress\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.netz-barrierefrei.de\/wordpress\/wp-json\/wp\/v2\/comments?post=9010"}],"version-history":[{"count":8,"href":"https:\/\/www.netz-barrierefrei.de\/wordpress\/wp-json\/wp\/v2\/posts\/9010\/revisions"}],"predecessor-version":[{"id":10008,"href":"https:\/\/www.netz-barrierefrei.de\/wordpress\/wp-json\/wp\/v2\/posts\/9010\/revisions\/10008"}],"wp:attachment":[{"href":"https:\/\/www.netz-barrierefrei.de\/wordpress\/wp-json\/wp\/v2\/media?parent=9010"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.netz-barrierefrei.de\/wordpress\/wp-json\/wp\/v2\/categories?post=9010"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.netz-barrierefrei.de\/wordpress\/wp-json\/wp\/v2\/tags?post=9010"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}