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 t

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.