search

BIK-BITV / BIK-Web-Test

Testverfahren zur Prüfung der Barrierefeiheit von Webanwendungen anhand der Kriterien der WCAG 2.1, EN 301 549 und BITV 2.0
71 stars 21 forks source link

Prüfschritt 9.3.3.1 Fehlererkennung - Constraint validation API #254

Open sprungmarker opened 2 years ago

sprungmarker commented 2 years ago

Wir hatten ja mal besprochen, dass die browsereigene Fehlermeldungsroutine für mehr als 2-3 Formularfelder nicht hinreichend ist.

Jetzt fällt mir beim Testen auf, dass unterstützend für die browserinterne Fehlerroutine die Constraint validation API genutzt wird, d.h. hier lassen sich die browsereigenen Fehlermeldungen je nach Status und Formularfeld mit Hilfe von JavaSkript invividualisieren:

https://developer.mozilla.org/en-US/docs/Web/API/Constraint_validation Unterstützung ist gut: https://caniuse.com/?search=setCustomValidity

Soweit ich das testen konnte, funktioniert das schon ganz gut.

Würde damit die browsereigene Fehlerroutine in Kombination mit dieser Indivisualisierung wieder positiv bewertet werden können?

johannesFischer84 commented 2 years ago

Ich hatte zu browsereigenen Fehlermeldungen eher in Erinnerung, dass diese nicht barrierefrei sind, weil sie nach ein paar Sekunden von selbst verschwinden, weil sie beim Wegtabben verschwinden oder weil ihre Schrift nicht vergrößerbar ist, wenn der Browser-Zoom andere Inhalte vergrößert.

MarcHaunschild commented 2 years ago

Ein weiteres Problem ist, dass diese oft unspezifisch sind. So sollen ja Hinweise auf ein erwartetes Format gegeben werden, was die nicht tun. Es gibt da doch eine ganze Reihe Probleme. Wenn nur noch eines übrige bleibt (z.B. Formate) und darauf anders hingewiesen wird (z.B. im label) würde ich nichts mehr abziehen. Im echten Leben sehe ich aber entweder individuelle Fehlermeldungen oder die vom Browser - an denen überhaupt keine Hand angelegt wurde. Natürlich: wenn die Meldungen bleiben (auch an den Feldern bleiben beim scrollen - tun sie nämlich auch nicht), wenn sie eine echte Hilfe sind oder die anders bereit gestellt wird, wenn sie sich vergrößern lassen und sonst alle Bedingungen erfüllen (nutzerspezifische Einstellungen der drunterliegenden Plattform übernehmen sie derzeit auch nicht in allen B Browsern), sind sie nicht negativ zu bewerten.

sprungmarker commented 2 years ago

Ich kann euch ja in dem meisten zustimmen, wir sollten uns aber auch nicht Standards des Browser komplett verschliessen.

MarcHaunschild commented 2 years ago

Vielleicht sollten wir wirklich mal alle Probleme sammeln, die typischerweise mit Browserfehlermeldungen auftreten und dann gelegentlich überprüfen, ob diese zugänglicher werden und streichen mit der Zeit weg von der Liste, was die Hersteller behoben haben?!?

stefanFarnetani commented 2 years ago

Wenn wir gemeinsam eine Liste der Probleme aus Sicht der Barrierefreiheit zusammenbekommen, würde mir die Mühe machen und bei den Ticket-Systemen der Browser schauen, ob entsprechende Tickets angelegt wurden und ggf welche anlegen. Ich bin der Ansicht, wenn die Browser-Validierung verlässlich funktionieren würde, würde das sehr viele Probleme lösen. Da lohnt es sich auch ein wenig input zu liefern.

Das gleiche gilt übrigens auch für den Tastatur-Fokus. Ich bin mehr und mehr der Ansicht, dass man das Thema "visible fokus" browserseitig lösen sollte und die Website-Entwicklung komplett aus der Gleichung nehmen sollte.