(no title)
everdimension | 1 year ago
The fact that something provided by the browser can fail accessibility requirements is definitely ironic. We're always taught that the motivation to "use the platform" and "follow semantics and semantic elements" is partly to satisfy the accessibility concerns.
I still think it's worth to leverage the native validation mechanisms.
* You don't have to use the native validity tooltips for the error messages. You can read directly from the input's ValidityState (input.validity) and render the message however you like and show multiple errors if you need to
* The browser can improve and you will benefit from using a standardized approach
The fact that "not using popups" supposedly breaks a11y sounds weird, though. But if you need to respond to an audit then this is the way you can go.
> Errors that do not belong to a particular field
These are indeed interesting! There are techniques to handle those, too. In my project I have a "HiddenValidationInput" component that renders an invisible readonly input that serves the purpose of rendering a custom error that doesn't belong to any other field. It's in fact quite a pleasure to use because you can just conditionally render it.
> The custom validity API is imperative and cumbersome to use
Absolutely agree on this one, and handling this is exactly what my article is about. And I really hope that this part will improve in time, too
kaoD|1 year ago
Feels like I don't gain much from that. Native validation is very limited and the few cases that it covers are super simple to implement already. Am I missing something?
I'd rather have a `validateSomething` which returns a discriminated union of error causes than using `pattern` and just getting a boolean.
> In my project I have a "HiddenValidationInput" component
Yeah, that's an accessibility issue (and the UX for the common user is terrible too for multiple reasons).