search

w3c / wcag

Web Content Accessibility Guidelines
https://w3c.github.io/wcag/guidelines/22/
Other
1.13k stars 257 forks source link

3.3.1 Error identification - does the default browser error validation count as PASS? #961

Open detlevhfischer opened 4 years ago

detlevhfischer commented 4 years ago

Hi, we currently have discussions here among evaluators whether the HTML5 default browser error validation without any custom error validation is sufficient to meet 3.3.1 Error Identification. On fields of type text, NVDA will after submit move focus to the first field in error and just read a non-descript error message like "Please fill in this field" (Firefox, Chrome) or "Required field" (Edge), but not the label of the field (I would assume screen reader users may learn soon to tab one step back and forth again to get it read out, or exit forms more and arrow up, but I am not sure). Compare https://codepen.io/stringyland/pen/BvMrqb Chrome does not highlight fields in error and the message disappears after about 6 seconds. It stands to reason that this is a Chrome UA issue - in Firefox, the message remains at least until the next tab. And on tabbing through the form, Edge will show popup messages for all fields in error.

Would you consider the fact that the label of the field in error is spoken by none of these browsers (with NVDA) a user agent issue?

Most of us tend to think (grudingly) that HTML5 native error validation would be a minimally conformant implementation for short forms, but we are less sure whether we can call this a PASS on longer forms when multiple fields may be in error but only the first field gets identified (and incompletely) - and some browsers are not very helpful in the way errors are indicated visually. Any thoughts?

patrickhlauke commented 4 years ago

interesting conundrum. while yes, the issue here is mostly that user agents have inconsistent support for these native form error messages (heck, I remember when I tested a few years ago, none of the browsers actually exposed their native error messages at all to AT), it seems that just using native errors fails if you think they're not sufficiently "accessibility supported" (as otherwise you're relying on browsers to do fulfill the "the item that is in error is identified and the error is described to the user in text" ... at least the "in text" part anyway).

so i'm tempted to say actually, no, can't rely purely on native form validation error messages currently due to lack of consistent implementation.

mraccess77 commented 4 years ago

The different implementations don't quite seem to meet the requirements as the error messages are not persistent and some browsers lack support which causes me to lean towards that the default behavior is not a pass by default.

JAWS-test commented 4 years ago

The output with JAWS is no better than with NVDA.

The main problem I see is that if other fields besides the first field are incorrect, the error messages of other fields are not noticeable (neither with screenreader nor without). Visually, the fields marked with red are marked as incorrect (Firefox, not in Chrome and not in the new Edge (based on chrome)) and the screenreader also outputs them as incorrect, but the cause of the error remains unclear.

The second problem is that if you navigate away from the incorrect field where the message is displayed and output and then navigate back, the error message is not noticable again.

For these reasons I wouldn't consider SC 3.3.1 to be fulfilled.

mtelgkamp commented 4 years ago

The corresponding bug reports for the browsers I found or created are

fstrr commented 6 months ago

This issue looks like it can be closed. If it needs to be re-opened, please do that and convert it to a Discussion.

patrickhlauke commented 3 months ago

I think this actually warrants re-opening, as the end result here seems to be that at least currently, pure browser validation is not sufficient to pass 3.3.1, and this fact should be surfaced somewhere (in understanding? a technique?)

patrickhlauke commented 3 months ago

Worth noting that at the moment, Chrome/VoiceOver and Firefox/VoiceOver on macOS don't announce the browser's default validation "bubbles", so at the very least it's an "accessibility supported" issue (while the picture looks much better nowadays on Windows, with Chrome/Firefox/Edge in combination with NVDA and JAWS happily announcing the validation errors as they appear)