6 ms·

If accessibility tools remove the focus from the disabled button and focus the document instead when a button is disabled, wouldn't this be a problem of the acc

by dbrgn 3y ago

If accessibility tools remove the focus from the disabled button and focus the document instead when a button is disabled, wouldn't this be a problem of the accessibility tool in the first place? Even just focussing the parent element would be a much much better idea than focusing the document. Making a button look disabled without actuall disabling it sounds like a semantically bad idea.

alpaca128 3y ago
As written in the article the "disabled" attribute doesn't disable submissions either, so it's mostly an appearance thing either way.
- 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.
      - 3y ago
- SebastianKra 3y ago
  Yes it does. You can't submit a form by pressing enter unless it contains a non-disabled <button type="submit" /> It's a shame that screen-reader support sucks, but it's semantically correct.
lopis 3y ago
It virtually always better to allow the button to be pressed and present a reason why the click action failed. "this field is required" or "this field is not valid" or "do this action first". A disabled button is just confusing even for people that can see.
- flappyeagle 3y ago
  [flagged]
lloeki 3y ago
Isn't it instead that the browser changes the focus target upon disablement, and the accessibility tool merely follows? That's what I understood but I may be wrong.
- hunter2_ 3y ago
  Indeed, the outcome of a focused thing becoming unfocusable affects typical keyboard usage (tab order), not just accessibility tools.
  - dbrgn 3y ago
    In that case the developer could explicitly move focus to something that makes sense in the context of the application flow.
moritzwarhier 3y ago
Basically the whole "disable submit button after submit" thing is a lazy hack. Double submit should be prevented by other means and "disabled" is semantically different from "this action is in progress". This problem can basically only occur for async form submits, so one can easily just alter the button and replace it with a dummy like ("submitting") in any way it seems fit, using JS. One can also set a "submitting" CSS class for the UI state and change text accordingly (or aria-label). For old-fashioned plain HTML form submits, the browser handles the client side of the double-submit problem already, no?
- Spivak 3y ago
  > Basically the whole "disable submit button after submit" thing is a lazy hack. It is and there is a ready-made solution to handle it https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/ETag https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/ET... Your HTTP library likely already has support for it.
  - hombre_fatal 3y ago
    How would etags help you avoid multiple inflight requests from users double submitting a form?
    - mgkimsal 3y ago
      Potentially snarky answer: they don't/can't. A double click is something people do within a split second. Within a few ms, your application is now trying let's say, to store a comment and send a notification. Even with some sort of one-time token, process A will check the token, mark it 'used', but process B may be doing the same thing, and when process B started, the token was valid then too. If stored in SQL, you can try to do something with locking the table or row, and a second process might not get to update (or you can look in to optimistic locking/versioning/etc) but it's a thorny problem to deal with when people 'double click' and two processes start within a few ms of each other. tldr: disabling a submit button to prevent a double click scenario is by far the easiest and most pragmatic approach that stops the problem from entering "much more complex/difficult" territory. Ideally, the 'disabled' state might auto-undisable after a couple seconds, but the original request handler should be able to reset the state after processing the response. Would be so much nicer if this was a standard attribute to add in to forms to prevent this (2 single clicks registered back to back within X ms... ignore second). edit: finished the article, and the 'data-submitting' approach is something I also have implemented some times, and works decently well as an alternative. You're still having to prevent double submission. etags won't really help there.
gpvos 3y ago
It's not the accessibility tools that do that, it's the default browser behaviour.
- feoren 3y ago
  Screen readers are browsers. They could just ... not do that.
  - jay_kyburz 3y ago
    Browsers can't change their behavior.
    - danShumway 3y ago
      It is extremely complicated for browsers to change their existing behavior, and we should be cautious about them doing so. We could however introduce another attribute that has the correct behavior, deprecate `disabled`, and throw warnings during ARIA validation/linting for pages that continue to use it. Call it `blocked` or `unsusable` or have if you want to be fancy, make a `status` or something with attribute with multiple values that it accepts. Whatever seems most reasonable. But my point is we're not trapped in the world of developers needing to poorly replicate browser functionality for every single form they make; we could still have an attribute that makes it easy for developers to by-default program forms with the correct behavior. In Javascript, adding `let` and `const` didn't require us to get rid of `var`. We didn't have to change `var` behavior to make `let` throw errors on redeclarations. There are options here for providing tools within browsers that work correctly.
    - Lornedon 3y ago
      Why not?
      - gpvos 3y ago
        They can, but they have to think a lot about backwards compatibility and existing code. So sometimes they can't, and in this particular case I think it's going to be hard, mostly because of existing Javascript code. Also there's standardization and coordination between browsers, but if there is a genuine need for something they tend to find a way.
danShumway 3y ago
Agreed that this is a user-agent problem. People here are arguing about whether a form being submitted counts as actually disabled or not, but that's missing the broader point: even clearly disabled buttons should be selectable, because they might focus tooltips showing why they're disabled, or because users using a keyboard cycling through the interface shouldn't have their muscle memory interrupted by having the number of tabs required to reach a button change unexpectedly depending on the context, or to prevent errors during automation and scripting, and on and on. Even if you believe that an "in-progress" indicator should be treated differently from "disabled", it's still bad UX that disabled buttons aren't focusable and it's still bad semantics to avoid a browser attribute just to fix that problem. Now, you might have to avoid it anyway, because good luck getting browsers and screenreaders to all change their behavior; that would be fairly difficult to do. But... it is their fault regardless of what the rest of us on the web have to do to cover for their mistake and to make our applications accessible to people who are using these tools with their broken behaviors. ---- Mozilla writes about this exact scenario (https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Attributes/aria-disabled https://developer.mozilla.org/en-US/docs/Web/Accessibility/A...): > When needing to disable native HTML form controls, developers will need to specify the disabled attribute, as it provides all of the generally expected features of disabling a control by default. However, there can be instances where elements need to be exposed as disabled, but are still available for users to find when navigating via the Tab key. Doing so can improve their discoverability as they will not be removed from the focus order of the web page, as aria-disabled does not change the focusability of such elements, nor will the elements be dimmed by default browser styling, making them easier to read. Some examples of where this may be useful include: > The header button element associated with non-collapsible accordion panel, > A button which is important to keep in the page's focus order, but its action is presently unavailable - such as submitting a form, I would argue that if you are calling an aria-attribute and ignoring the real attribute specifically because the actual attribute is stricter than the aria-attribute and has unintended side-effects, then maybe the actual attribute is not accurately representing its semantic value or its expected semantic behavior. If screenreaders and browsers aren't using aria-disabled as an indicator to skip focus, then the clear indication from that is that disabled elements should not necessarily skip focus. If disabled elements were meant to universally be unfocusable, then aria-disabled would block focus.
rkuykendall-com 3y ago
I have been working on the web for 20 years, which isn't much but it's long enough to notice a pattern. 1. Accessibility tool handles common things badly 2. Accessibility nerds try (and fail) to get everyone to stop doing common thing 3. Accessibility tool handles common thing correctly There is a lot of great stuff you can do for accessibility, but always ask yourself if it is adding more data (like aria labels) or avoiding something you legitimately understand is not going to be compatible with accessible browsing (like onClick components inside onClick components). But things like "don't use basic HTML functionality because tools are bad" is advice that will look very silly in 5 years when the cycle continues. I guess one more is to be very careful not to assume anything is good or bad for accessibility. Most of the people talking have no experience with it whatsoever, and have not even installed the most popular software.

by dbrgn 3y ago

alpaca128 3y ago

As written in the article the "disabled" attribute doesn't disable submissions either, so it's mostly an appearance thing either way.

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.
    - 3y ago
SebastianKra 3y ago
Yes it does. You can't submit a form by pressing enter unless it contains a non-disabled <button type="submit" /> It's a shame that screen-reader support sucks, but it's semantically correct.

lopis 3y ago

It virtually always better to allow the button to be pressed and present a reason why the click action failed. "this field is required" or "this field is not valid" or "do this action first". A disabled button is just confusing even for people that can see.

flappyeagle 3y ago
[flagged]

lloeki 3y ago

Isn't it instead that the browser changes the focus target upon disablement, and the accessibility tool merely follows? That's what I understood but I may be wrong.

hunter2_ 3y ago
Indeed, the outcome of a focused thing becoming unfocusable affects typical keyboard usage (tab order), not just accessibility tools.
- dbrgn 3y ago
  In that case the developer could explicitly move focus to something that makes sense in the context of the application flow.

moritzwarhier 3y ago

Basically the whole "disable submit button after submit" thing is a lazy hack. Double submit should be prevented by other means and "disabled" is semantically different from "this action is in progress". This problem can basically only occur for async form submits, so one can easily just alter the button and replace it with a dummy like ("submitting") in any way it seems fit, using JS. One can also set a "submitting" CSS class for the UI state and change text accordingly (or aria-label). For old-fashioned plain HTML form submits, the browser handles the client side of the double-submit problem already, no?

Spivak 3y ago
> Basically the whole "disable submit button after submit" thing is a lazy hack. It is and there is a ready-made solution to handle it https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/ETag https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/ET... Your HTTP library likely already has support for it.
- hombre_fatal 3y ago
  How would etags help you avoid multiple inflight requests from users double submitting a form?
  - mgkimsal 3y ago
    Potentially snarky answer: they don't/can't. A double click is something people do within a split second. Within a few ms, your application is now trying let's say, to store a comment and send a notification. Even with some sort of one-time token, process A will check the token, mark it 'used', but process B may be doing the same thing, and when process B started, the token was valid then too. If stored in SQL, you can try to do something with locking the table or row, and a second process might not get to update (or you can look in to optimistic locking/versioning/etc) but it's a thorny problem to deal with when people 'double click' and two processes start within a few ms of each other. tldr: disabling a submit button to prevent a double click scenario is by far the easiest and most pragmatic approach that stops the problem from entering "much more complex/difficult" territory. Ideally, the 'disabled' state might auto-undisable after a couple seconds, but the original request handler should be able to reset the state after processing the response. Would be so much nicer if this was a standard attribute to add in to forms to prevent this (2 single clicks registered back to back within X ms... ignore second). edit: finished the article, and the 'data-submitting' approach is something I also have implemented some times, and works decently well as an alternative. You're still having to prevent double submission. etags won't really help there.

gpvos 3y ago

It's not the accessibility tools that do that, it's the default browser behaviour.

feoren 3y ago
Screen readers are browsers. They could just ... not do that.
- jay_kyburz 3y ago
  Browsers can't change their behavior.
  - danShumway 3y ago
    It is extremely complicated for browsers to change their existing behavior, and we should be cautious about them doing so. We could however introduce another attribute that has the correct behavior, deprecate `disabled`, and throw warnings during ARIA validation/linting for pages that continue to use it. Call it `blocked` or `unsusable` or have if you want to be fancy, make a `status` or something with attribute with multiple values that it accepts. Whatever seems most reasonable. But my point is we're not trapped in the world of developers needing to poorly replicate browser functionality for every single form they make; we could still have an attribute that makes it easy for developers to by-default program forms with the correct behavior. In Javascript, adding `let` and `const` didn't require us to get rid of `var`. We didn't have to change `var` behavior to make `let` throw errors on redeclarations. There are options here for providing tools within browsers that work correctly.
  - Lornedon 3y ago
    Why not?
    - gpvos 3y ago
      They can, but they have to think a lot about backwards compatibility and existing code. So sometimes they can't, and in this particular case I think it's going to be hard, mostly because of existing Javascript code. Also there's standardization and coordination between browsers, but if there is a genuine need for something they tend to find a way.

danShumway 3y ago

Agreed that this is a user-agent problem. People here are arguing about whether a form being submitted counts as actually disabled or not, but that's missing the broader point: even clearly disabled buttons should be selectable, because they might focus tooltips showing why they're disabled, or because users using a keyboard cycling through the interface shouldn't have their muscle memory interrupted by having the number of tabs required to reach a button change unexpectedly depending on the context, or to prevent errors during automation and scripting, and on and on. Even if you believe that an "in-progress" indicator should be treated differently from "disabled", it's still bad UX that disabled buttons aren't focusable and it's still bad semantics to avoid a browser attribute just to fix that problem. Now, you might have to avoid it anyway, because good luck getting browsers and screenreaders to all change their behavior; that would be fairly difficult to do. But... it is their fault regardless of what the rest of us on the web have to do to cover for their mistake and to make our applications accessible to people who are using these tools with their broken behaviors. ---- Mozilla writes about this exact scenario (https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Attributes/aria-disabled https://developer.mozilla.org/en-US/docs/Web/Accessibility/A...): > When needing to disable native HTML form controls, developers will need to specify the disabled attribute, as it provides all of the generally expected features of disabling a control by default. However, there can be instances where elements need to be exposed as disabled, but are still available for users to find when navigating via the Tab key. Doing so can improve their discoverability as they will not be removed from the focus order of the web page, as aria-disabled does not change the focusability of such elements, nor will the elements be dimmed by default browser styling, making them easier to read. Some examples of where this may be useful include: > The header button element associated with non-collapsible accordion panel, > A button which is important to keep in the page's focus order, but its action is presently unavailable - such as submitting a form, I would argue that if you are calling an aria-attribute and ignoring the real attribute specifically because the actual attribute is stricter than the aria-attribute and has unintended side-effects, then maybe the actual attribute is not accurately representing its semantic value or its expected semantic behavior. If screenreaders and browsers aren't using aria-disabled as an indicator to skip focus, then the clear indication from that is that disabled elements should not necessarily skip focus. If disabled elements were meant to universally be unfocusable, then aria-disabled would block focus.

rkuykendall-com 3y ago

I have been working on the web for 20 years, which isn't much but it's long enough to notice a pattern. 1. Accessibility tool handles common things badly 2. Accessibility nerds try (and fail) to get everyone to stop doing common thing 3. Accessibility tool handles common thing correctly There is a lot of great stuff you can do for accessibility, but always ask yourself if it is adding more data (like aria labels) or avoiding something you legitimately understand is not going to be compatible with accessible browsing (like onClick components inside onClick components). But things like "don't use basic HTML functionality because tools are bad" is advice that will look very silly in 5 years when the cycle continues. I guess one more is to be very careful not to assume anything is good or bad for accessibility. Most of the people talking have no experience with it whatsoever, and have not even installed the most popular software.