4 ms·

My product just failed an accessibility audit because we are using native HTML form validation and the official recommendation was to implement our own validati

by kaoD 2y ago

My product just failed an accessibility audit because we are using native HTML form validation and the official recommendation was to implement our own validation layer. EDIT: which I agree with. Native HTML validation has many flaws and visual customization is not my biggest concern to be honest (but it's the nail in the coffin). E.g.: - It's impossible to show multiple errors at once per field unless you concat strings ("You need a number. You need a symbol. Must be >10 chars.") This is both bad UX and bad for accessibility (you cannot navigate concatenated strings on the accessibility tree). And this isn't even implementation dependent, it's the spec! You need multiple errors at once because playing whack-a-validation-error is not fun for users. - It's browser-dependent which is bad because you can't control it and because the implementation is generally terrible (e.g. in Chrome it shows a popup on focus, which is not very accessible by itself because (1) it's a popup (2) that shows modally (3) and can't show all form errors at once). Not using popups for important information is accessibility 101, but browsers cannot afford to do anything else without interfering with the actual document. - You still need custom validation for form-wide errors (like errors that don't belong to a particular field, "Fields A and B are incompatible") so you might as well have a consistent validation story. - It requires you to have hidden inputs to be consistent (-ish) if you have some custom input that doesn't fit any of the native input types -- this breaks accessibility too and fixing it is as hard as having your own accessibility-friendly validation story. - The custom validity API is imperative and cumbersome to use. Not using custom validity is almost never an option unless you want terrible messages ("This field is invalid") And many more. HTML form validation is terrible.

josephcsible 2y ago
What was the auditors' reasoning for that?
- kaoD 2y ago
  That the browser implementations are generally terrible and wouldn't pass accessibility audits, so all browsers would have to change and then some time to pass for the fixed versions to be widespread. We didn't discuss browser-specific issues in detail, but I edited some points in my original message that highlight some of the issues that I suspect make it a no-go for accessibility.
  - SoftTalker 2y ago
    Seems to me that this says that the browsers have the accessibility problems and that's what should be fixed. Why does every website developer have to work around this while the browsers get a free pass? If field validation is "standard HTML" and browsers can't do it in an accessible way, that's squarely a browser problem.
    - kaoD 2y ago
      Because in reality browsers can't do much. The API and spec are broken as-is. I'll quote my top-level comment: > This is both bad UX and bad for accessibility (you cannot navigate concatenated strings on the accessibility tree). And this isn't even implementation dependent, it's the spec! > Not using popups for important information is accessibility 101, but browsers cannot afford to do anything else without interfering with the actual document. Plus it doesn't matter who's to blame: people with accessibility issues need access now.
    - everdimension 2y ago
      totally And if they fix it, it'll be fixed for everyone
    - dspillett 2y ago
      > Why does every website developer have to work around this while the browsers get a free pass? Because browser makers are merrily taking that free pass, whether we like it or not, and people who need accessibility allowances need them now, or better still quite some years ago, rather than at some future time after we've nagged the browsers into taking useful action. It isn't entirely the browser people's fault, there are significant issues in the spec, as already discussed in these comments by people who know more about it than I, and that is part of why they feel justified in taking the free ride, but as some of them were involved in the original specs and they are in a position to propose alternatives & deliver PoC implementations, it is more their responsibility than they think. After all, Google in particular are more than willing & able to invent new specs¹ and throw implementations into production, when there might be marketshare, stalk^H^H^H^H^Hadvertising income, or protection money² on the line. ---- [1] and Apple deliberately break them, old or new, in a fit of pique! [2] Nice app/extension you have there, it would be a shame if it started failing store inclusion reviews, or if APIs had breaking changes for our benefit underneath you.
everdimension 2y ago
Thanks, that's quite interesting and insightful! Thank you for sharing 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 2y ago
  > You can read directly from the input's ValidityState (input.validity) 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).
braiamp 2y ago
Interesting, because for my apps, I implement all those validations. The form wide validation are done on server. Basically I have a bunch of layers of validation that leverages everything. Chrome having a shoddy unaccessible design is Chrome problem, I would file a bug report. > it's the spec This one? https://html.spec.whatwg.org/multipage/dom.html#concept-element-accessibility-considerations https://html.spec.whatwg.org/multipage/dom.html#concept-elem... I don't see anything that defines how validation messages should be presented (not even that they should be present)

by kaoD 2y ago

josephcsible 2y ago

What was the auditors' reasoning for that?

kaoD 2y ago
That the browser implementations are generally terrible and wouldn't pass accessibility audits, so all browsers would have to change and then some time to pass for the fixed versions to be widespread. We didn't discuss browser-specific issues in detail, but I edited some points in my original message that highlight some of the issues that I suspect make it a no-go for accessibility.
- SoftTalker 2y ago
  Seems to me that this says that the browsers have the accessibility problems and that's what should be fixed. Why does every website developer have to work around this while the browsers get a free pass? If field validation is "standard HTML" and browsers can't do it in an accessible way, that's squarely a browser problem.
  - kaoD 2y ago
    Because in reality browsers can't do much. The API and spec are broken as-is. I'll quote my top-level comment: > This is both bad UX and bad for accessibility (you cannot navigate concatenated strings on the accessibility tree). And this isn't even implementation dependent, it's the spec! > Not using popups for important information is accessibility 101, but browsers cannot afford to do anything else without interfering with the actual document. Plus it doesn't matter who's to blame: people with accessibility issues need access now.
  - everdimension 2y ago
    totally And if they fix it, it'll be fixed for everyone
  - dspillett 2y ago
    > Why does every website developer have to work around this while the browsers get a free pass? Because browser makers are merrily taking that free pass, whether we like it or not, and people who need accessibility allowances need them now, or better still quite some years ago, rather than at some future time after we've nagged the browsers into taking useful action. It isn't entirely the browser people's fault, there are significant issues in the spec, as already discussed in these comments by people who know more about it than I, and that is part of why they feel justified in taking the free ride, but as some of them were involved in the original specs and they are in a position to propose alternatives & deliver PoC implementations, it is more their responsibility than they think. After all, Google in particular are more than willing & able to invent new specs¹ and throw implementations into production, when there might be marketshare, stalk^H^H^H^H^Hadvertising income, or protection money² on the line. ---- [1] and Apple deliberately break them, old or new, in a fit of pique! [2] Nice app/extension you have there, it would be a shame if it started failing store inclusion reviews, or if APIs had breaking changes for our benefit underneath you.

everdimension 2y ago

Thanks, that's quite interesting and insightful! Thank you for sharing 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 2y ago
> You can read directly from the input's ValidityState (input.validity) 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).

braiamp 2y ago

Interesting, because for my apps, I implement all those validations. The form wide validation are done on server. Basically I have a bunch of layers of validation that leverages everything. Chrome having a shoddy unaccessible design is Chrome problem, I would file a bug report. > it's the spec This one? https://html.spec.whatwg.org/multipage/dom.html#concept-element-accessibility-considerations https://html.spec.whatwg.org/multipage/dom.html#concept-elem... I don't see anything that defines how validation messages should be presented (not even that they should be present)