[Docs]: Reconsider recommendation to use the browser's built in HTML Form Validation

[danielnixon]

What version of React Router are you using?

NA

Steps to Reproduce

Read https://reactrouter.com/en/main/components/form

Expected Behavior

Please reconsider recommending the browser's native form validation, which is known to have accessibility issues.

A more accessible form validation experience can be had via scripting, after having turned off HTML5 validation via novalidate.

See for example https://www.tpgi.com/required-attribute-requirements/

To communicate why a control is being announced as invalid, form controls should have associated error messages to help people correct invalid entries. While we can’t, and often we don’t, rely on browser’s client-side validation to be accessible, there are ways to provide accessible inline error messages.

First, suppress the browser’s default validation messages by adding the novalidate attribute to the wrapping form element. Now you’ll be in complete control to implement a custom client-side validation script, and helpful messaging.

Use the novalidate attribute on a form to disable browsers’ client-side validation, and instead implement custom validation scripts and accessible error messaging.

I understand (and share) the motivation to "use the platform", but in this specific instance accessibility trumps the flawed native HTML5 form validation impl imo.

Actual Behavior

Recommendation to use the browser's built in HTML Form Validation.

[danielnixon]

I should hasten to add that I'm not suggesting removing the advice to validate server-side, that remains necessary either way.

[machour]

@danielnixon The blog post you linked to is 4 years old. Do you know if there's a more recent study about this?

[danielnixon]

• https://github.com/w3c/wcag/issues/961
• https://design-system.service.gov.uk/patterns/validation/#turn-off-html5-validation
• https://oliverjam.es/articles/better-native-form-validation#native-isnt-always-better
• https://adrianroselli.com/2019/02/avoid-default-field-validation.html

Update: 4 May 2022 #anchor

Three years on and this post is still accurate. The disappearing error messages in Chromium are one ongoing challenge, and browsers still do not respect zoom.

[brophdawg11]

I think there's 2 separate things to consider here:

1. Native Form Validation (element.validity)
2. Native Form Validation UI (the error boxes that pop up on blur)

I agree (2) is pretty horrible across browsers, but (1) is an incredibly powerful (and vastly underutilized) layer that avoids needing to load a bloated client-side form validation library which slows down your site and makes it even worse for slower networks/devices. I didn't write them but I don't think the docs are necessarily suggesting to use (2) as your UX and do nothing else. I think instead it's hinting at the fact that you may not need a bloated validation library due to (1).

Maybe we can just elaborate that while the built-in validation is powerful, it won't meet all accessibility criteria out of the box? Could include a few of the above links as well so folks can read into adding aria- attributes and novalidate etc.

[machour]

Sorry @danielnixon, our stale bot went rogue and closed this