3 ms·

Of course the submission needs to be handled separately (if a <form> tag is being used). But that's not the point. The semantics for a disabled button are much

by dbrgn 3y ago

Of course the submission needs to be handled separately (if a <form> tag is being used). But that's not the point. The semantics for a disabled button are much clearer: You indicate that the button cannot be pressed (because it wouldn't actually do anything). Having a button that can be clicked, but that doesn't do anything, sounds like a wrong choice. Even worse is "making it look like it cannot be pressed by adding CSS rules". From what I know about accessibility, semantics are key. If the semantics are clear, then accessibility tools can optimize their flows accordingly. Using styling to convey semantics is a bad idea. If accessibility tools cannot deal well with certain situations, then those tools should be improved instead of making semantics worse.

deleted 3y ago
[deleted]
creshal 3y ago
There's two levels here: 1. The screenreader transforms the visual structure into something understandable for the human behind it 2. The human tries to make sense of it and maintain a mental model of what the screenreader is presenting to them Semantics are key for #1, but #2 can still lose track of what's happening on a complex form. For that, it helps if the human can keep trying, and fix whatever they missed on the next pass.
lyu07282 3y ago
I agree that is a strange article, setting disabled on the submit button is absolutely the correct semantic solution, the CSS presented as a workaround is also not enough, you'll need to set CSS for pointer-events, hover, active, and focus at least to re-create (badly) what the browser actually does when a button is disabled. That feels like such a hack. Of course you need to block the onSubmit event on the form element too but that is a separate issue entirely. Do we really now have to work around broken screen readers too? Fuck that.
- hombre_fatal 3y ago
  Well, the article is right, though. The disabled attribute resets focus to the document which is really bad UX. It might seem like a trivial detail, but it's not for people who depend on keyboard navigation nor is it for any form where users might want to keep the button focused after submit. You don't have to use a screen reader to be inconvenienced here. I've had to handle the latter case in game-related apps, but another example off the top of my head would be the obvious ability to resubmit the Reddit reply form by hitting Enter again when it responds with its "Error, try again" message. I don't see the argument for settling for the poor UX of using the disabled attribute here if you knew better and had the time/energy to polish it. There is a level of polish where it makes sense to replace the disabled attribute with a disabled (e.g. "submitting") class which implements all the things you expect, like pointer-event changes, but is even more powerful, like being able to use it on a wider variety of elements and even container elements like `form`. Finally, as the article points out, you still to write JS to prevent double submits even when using the disabled attribute. It's used as a quick hack rather than any sort of "submitting" semantics, so there's nothing lost recreating it with CSS.
  - function_seven 3y ago
    Would it be a good idea to first move the focus to an adjacent item before disabling the submit button? Like, have something that says "Submitting...", move the focus to that, disable the [Submit] button, and also tag the form element with an attribute that marks it as already sent.
  - danShumway 3y ago
    > Finally, as the article points out, you still to write JS to prevent double submits even when using the disabled attribute. It's used as a quick hack rather than any sort of "submitting" semantics, so there's nothing lost recreating it with CSS. Eh, disabling an entire form submit is easy. Developers who manually replicate built-in browser features though and manually duplicate those features through CSS have far more opportunities to make mistakes and make inaccessible forms that don't account for keyboard focus vs click focus, different input methods, etc... The article is correct in the sense that it doesn't matter what the correct behavior is, if you want to build an accessible site for browsers as they exist today then you have to care about this. But it's still the fault of the browsers if developers are working around browser quirks because the built-in semantics that the browser exposes provide a bad UX. Ideally, over time, those quirks should be fixed within browsers, although of course doing so on the web is very complicated.

by dbrgn 3y ago

deleted 3y ago

[deleted]

creshal 3y ago

There's two levels here: 1. The screenreader transforms the visual structure into something understandable for the human behind it 2. The human tries to make sense of it and maintain a mental model of what the screenreader is presenting to them Semantics are key for #1, but #2 can still lose track of what's happening on a complex form. For that, it helps if the human can keep trying, and fix whatever they missed on the next pass.

lyu07282 3y ago

I agree that is a strange article, setting disabled on the submit button is absolutely the correct semantic solution, the CSS presented as a workaround is also not enough, you'll need to set CSS for pointer-events, hover, active, and focus at least to re-create (badly) what the browser actually does when a button is disabled. That feels like such a hack. Of course you need to block the onSubmit event on the form element too but that is a separate issue entirely. Do we really now have to work around broken screen readers too? Fuck that.

hombre_fatal 3y ago
Well, the article is right, though. The disabled attribute resets focus to the document which is really bad UX. It might seem like a trivial detail, but it's not for people who depend on keyboard navigation nor is it for any form where users might want to keep the button focused after submit. You don't have to use a screen reader to be inconvenienced here. I've had to handle the latter case in game-related apps, but another example off the top of my head would be the obvious ability to resubmit the Reddit reply form by hitting Enter again when it responds with its "Error, try again" message. I don't see the argument for settling for the poor UX of using the disabled attribute here if you knew better and had the time/energy to polish it. There is a level of polish where it makes sense to replace the disabled attribute with a disabled (e.g. "submitting") class which implements all the things you expect, like pointer-event changes, but is even more powerful, like being able to use it on a wider variety of elements and even container elements like `form`. Finally, as the article points out, you still to write JS to prevent double submits even when using the disabled attribute. It's used as a quick hack rather than any sort of "submitting" semantics, so there's nothing lost recreating it with CSS.
- function_seven 3y ago
  Would it be a good idea to first move the focus to an adjacent item before disabling the submit button? Like, have something that says "Submitting...", move the focus to that, disable the [Submit] button, and also tag the form element with an attribute that marks it as already sent.
- danShumway 3y ago
  > Finally, as the article points out, you still to write JS to prevent double submits even when using the disabled attribute. It's used as a quick hack rather than any sort of "submitting" semantics, so there's nothing lost recreating it with CSS. Eh, disabling an entire form submit is easy. Developers who manually replicate built-in browser features though and manually duplicate those features through CSS have far more opportunities to make mistakes and make inaccessible forms that don't account for keyboard focus vs click focus, different input methods, etc... The article is correct in the sense that it doesn't matter what the correct behavior is, if you want to build an accessible site for browsers as they exist today then you have to care about this. But it's still the fault of the browsers if developers are working around browser quirks because the built-in semantics that the browser exposes provide a bad UX. Ideally, over time, those quirks should be fixed within browsers, although of course doing so on the web is very complicated.