Add section on native browser form validation to 3.3.1 understanding #4431
Conversation
✅ Deploy Preview for wcag2 ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
|
@patrickhlauke to re-check. |
patrickhlauke
left a comment
patrickhlauke
left a comment
There was a problem hiding this comment.
suggest renaming the section, moving it after the two existing notes, and tweaking the language (as it's not just the required attribute that triggers these things).
may also be worth couching the description a bit more into "in most user agents" type language (though from testing, the statements here hold true for chrome, edge, firefox, safari, probably others, from my testing)
|
@detlevhfischer let me know if you're happy for me to make some of my proposed more fundamental tweaks here for you, or if you want to do them yourself (don't want to just barge in and rewrite your PR without your approval) |
patrickhlauke
changed the title
|
Very happy for you to step in! |
otherwise, it makes it look like those notes/text only relate to native HTML validation
|
@detlevhfischer pushed some changes ... have a look and see if this still captures what you were trying to do |
|
Note that "success criterion/criteria" is almost always lower case now. Please see our style guide |
|
Apologies @mbgower .... removed my over-eager "capitalise ALL THE SUCCESS CRITERION mentions" faux-pas. @adampage this is now clean and ready for review. for reference, when I checked that the behaviour described here actually happens, i tested in the following combinations: windows chrome, firefox, edge, with JAWS and NVDA; ios/safari/VO; android/chrome/talkback; macos/safari/VO |
adampage
left a comment
adampage
left a comment
There was a problem hiding this comment.
Very helpful to have this documented. This is ready to go IMO! 🚀
|
@patrickhlauke read through "Files changed", looks good to me! |
|
It does not become clear whether the method to use the user agent's ability leads to a conformant page. One hand it says: "While this meets the requirements of this Success Criterion, it should be noted that there are several disadvantages related to this approach", while further down it states that the error message might not show with enlarged text (which is a violation of text resizing), and further down it states that the user might need to resubmit while in the other sections of the understanding it clearly suggests that all errors should be displayed at once for convenient correction. |
|
To rephrase my last comment: I think the new text somehow contradicts itself concerning the point whether this approach leads to a conformant page or not. |
|
I think that the browser native validation approach is not recommended, but if this violates another SC, it is still a pass for "Error identification". The only concern is about the back and forth with submissions-showing a single error-submit again-show another error, since the system is technically aware of all errors when the form is submitted the first time (and not showing all the messages for the identified errors), so it might represent a violation. However, since this is a native behaviour, we can discuss if this can be forgiven. |
The problem with native validation in Chrome and Firefox is that the error message can disappear or become dissociated from the form control that is in error. It therefore fails SC 3.3.1 even if the page only contains one form control. |
I don't think normatively it's required that error messages be persistent.
Is there an example of this? I've tried to replicate this with various zoom levels, scrolling around, etc, but it seems solid enough from my cursory testing. Is it an issue on mobile/small screen browsers, more than large screen/desktop ones? |
|
In Chrome, the error message disappears if you scroll the page such that the error message moves out of the viewport. The error message does not reappear when you scroll the page back to the original position, so there is no indication there was ever an error message. In Firefox, the error message remains in the same place in the viewport when the page is scrolled, so the visual relationship between the form control and the error message is lost. If the page contains multiple form controls, it is impossible to know which one the error message is associated with. I regard both behaviours as being non-conformant. |
|
ah, somehow missed the firefox behaviour. that's certainly a bug with firefox (which would impact "accessibility support" of that technique while it's not fixed) |
|
Discussed on backlog call 10/24. TF members on call concur that only concern is for bug in FireFox. Moved to Ready for Review. |
Co-authored-by: Patrick H. Lauke <[email protected]>
Addition of a section on native HTML error validation, addressing to some extent the issues #961 and #1773 and maybe other issues.
This is mainly to start / a first stab at updating this dated understanding text. Currently there are a couple of notes strewn in, one on rectification on user input, and another note saying that there can be different techniques to display the error in text, including rather dated techniques like Javascript alerts.
The pertinent question whether (and under what conditions) native HTML form validation can be deemed sufficient to meet 3.3.1 is not touched upon in the current understanding text. While it will be difficult to draw a definite line like "on forms with three fields or less native HTML validation can be considered sufficient", it seems necessary to address the disadvantages and maybe also the benefits of native HTML validation.
Other issues that remain to be worked into a revision are, for example, correcting the inclusion of ARIA Techniques as "sufficient" as noted in #4029, and possibly adding advice regarding the combination of available techniques (e.g., to warn against overdoing it with programmatic linking of inline error messages plus aria-live regions).
EDIT: preview link https://deploy-preview-4431--wcag2.netlify.app/understanding/error-identification (new section "Note on using native HTML form validation")