4 ms·

Will browsers ever catch up here so that the right way to do it is the default way? Or at least one of the easiest ways? It's clearly difficult if there's so m

Will browsers ever catch up here so that the right way to do it is the default way? Or at least one of the easiest ways? It's clearly difficult if there's so many options and this generates so much discussion. It shouldn't be this hard to get a basic UI pattern right (submitting a form once with progress updates). If it's even a little hard, it's inevitable 90% of sites will get it wrong. There's just too much stuff for devs to realistically stay on top of to blame them. Related: the `inert` attribute has good support now for preventing users from editing/interacting with forms that are currently being submitted so you don't have to mess with overriding input events (https://developer.mozilla.org/en-US/docs/Web/HTML/Global_attributes/inert https://developer.mozilla.org/en-US/docs/Web/HTML/Global_att...). You'll have to add it manually when the form is submitted though, remove it if the submission fails, and use something like aria-live to give progress updates (https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Attributes/aria-live https://developer.mozilla.org/en-US/docs/Web/Accessibility/A...). You'll also need to manually test all your custom forms like this work on actual screen readers (they have inconsistent behaviour, similar to cross-browser bugs), as well as edge cases like resubmitting after a failure, when the network request fails with error feedback, and when the network request fails from a time out. Not easy.

ASalazarMX 3y ago
> Will browsers ever catch up here so that the right way to do it is the default way? Or at least one of the easiest ways? My pet peevee is how browsers; and later smartphones; normalized that interactive elements can reflow/reorganize all the time. Now, things like joining a specific WiFi, or mirropring to a specific TV, can become a game of chance if you don't let the UI settle a bit. We had this problem more or less solved before.
- jbverschoor 3y ago
  HTML is a document, as in hyperlinked rich text, format / "language". People abused HTTP/HTML as an application delivery platform. Now we finally have some better positioning / sizing for applications. It's the same as QWERTY... Not the best way, but got popular, and now we're stuck with it, trying to patch everything for the last 25 years.
danShumway 3y ago
`inert` has the exact same problem, and is arguably even worse since it removes content from the accessibility tree entirely: > Specifically, inert does the following: > Prevents the click event from being fired when the user clicks on the element. > Prevents the focus event from being raised by preventing the element from gaining focus. > Hides the element and its content from assistive technologies by excluding them from the accessibility tree. An `inert` attribute is basically invisible to screenreaders, and if you have mitigations in place for that, you might as well just use `disabled`. So I advise against using `inert`, I'm not going to say it's completely useless, but I don't think there are ton of instances where it makes sense and it's easy to get wrong. ---- The real solution here is pretty obvious: `disabled` shouldn't block focus. It's not what users want in most situations, and there are easy ways to block focus from an element if it needs focus blocked. The problem is that it would probably be extremely complicated to change browser specs to implement the better behavior. Introducing another attribute that has the correct behavior would likely be easier, but it's still not going to be trivial to get that through standardization process. But it's no great difficulty to block a button from being focusable in HTML, that's easy. We're only in this position because `disabled` blocks focus by default and offers no way to get focus back. Even manually setting a `tabindex` does nothing. And that's just bad design, clearly there are situations where disabled buttons should be able to receive focus. If not the default behavior, it should at least be possible to allow focus as an override.
- seanwilson 3y ago
  To clarify, I only meant `inert` is another (fairly new) tool that can be useful, not a complete solution. For example, you can use it to prevent the user editing the fields of the form while the current field values are being submitted. You don't need to use it on the submit button. As far as I remember, for similar behaviour you either have to add `disabled` to all the fields (then remember to revert only the `disabled` attributes you added if the form submit fails...) or wrap all the fields in a `disabled` `fieldset` tag (now you have to research if there's any quirks when you nest `fieldset`s). Saying that, why keep the focus on the submit button? Are there no better alternatives?
  - 3y ago
bluSCALE4 3y ago
You're absolutely right. It took me years to spoon feed myself web development while on the clock. I don't think there's a proper path forward for learning HTML and everyone has different opinions. But learning about WCAG should come right after learning HTML and CSS. Study BEM and a CSS library. Then basic Javascript or framework basics follow by CSS and JS molecular design principals with JSON and fetching. Then apply HTML semantics to write user actor tests. Anything I missed it's because I still haven't learned it so yes, it's a crazy world.

ASalazarMX 3y ago

> Will browsers ever catch up here so that the right way to do it is the default way? Or at least one of the easiest ways? My pet peevee is how browsers; and later smartphones; normalized that interactive elements can reflow/reorganize all the time. Now, things like joining a specific WiFi, or mirropring to a specific TV, can become a game of chance if you don't let the UI settle a bit. We had this problem more or less solved before.

jbverschoor 3y ago
HTML is a document, as in hyperlinked rich text, format / "language". People abused HTTP/HTML as an application delivery platform. Now we finally have some better positioning / sizing for applications. It's the same as QWERTY... Not the best way, but got popular, and now we're stuck with it, trying to patch everything for the last 25 years.

danShumway 3y ago

`inert` has the exact same problem, and is arguably even worse since it removes content from the accessibility tree entirely: > Specifically, inert does the following: > Prevents the click event from being fired when the user clicks on the element. > Prevents the focus event from being raised by preventing the element from gaining focus. > Hides the element and its content from assistive technologies by excluding them from the accessibility tree. An `inert` attribute is basically invisible to screenreaders, and if you have mitigations in place for that, you might as well just use `disabled`. So I advise against using `inert`, I'm not going to say it's completely useless, but I don't think there are ton of instances where it makes sense and it's easy to get wrong. ---- The real solution here is pretty obvious: `disabled` shouldn't block focus. It's not what users want in most situations, and there are easy ways to block focus from an element if it needs focus blocked. The problem is that it would probably be extremely complicated to change browser specs to implement the better behavior. Introducing another attribute that has the correct behavior would likely be easier, but it's still not going to be trivial to get that through standardization process. But it's no great difficulty to block a button from being focusable in HTML, that's easy. We're only in this position because `disabled` blocks focus by default and offers no way to get focus back. Even manually setting a `tabindex` does nothing. And that's just bad design, clearly there are situations where disabled buttons should be able to receive focus. If not the default behavior, it should at least be possible to allow focus as an override.

seanwilson 3y ago
To clarify, I only meant `inert` is another (fairly new) tool that can be useful, not a complete solution. For example, you can use it to prevent the user editing the fields of the form while the current field values are being submitted. You don't need to use it on the submit button. As far as I remember, for similar behaviour you either have to add `disabled` to all the fields (then remember to revert only the `disabled` attributes you added if the form submit fails...) or wrap all the fields in a `disabled` `fieldset` tag (now you have to research if there's any quirks when you nest `fieldset`s). Saying that, why keep the focus on the submit button? Are there no better alternatives?
- 3y ago

bluSCALE4 3y ago

You're absolutely right. It took me years to spoon feed myself web development while on the clock. I don't think there's a proper path forward for learning HTML and everyone has different opinions. But learning about WCAG should come right after learning HTML and CSS. Study BEM and a CSS library. Then basic Javascript or framework basics follow by CSS and JS molecular design principals with JSON and fetching. Then apply HTML semantics to write user actor tests. Anything I missed it's because I still haven't learned it so yes, it's a crazy world.