Focusability of elements with `aria-disabled=true`

[SaekiTominaga]

Describe your concern

Elements with the HTML disabled attribute are excluded from focusability. On the other hand, aria-disabled=true is expressed as follows

Disabled elements might not receive focus from the tab order.

“might not”, so aria-disabled=true can be interpreted as accepting focus.

Based on this, there is a discourse that the use of the disabled attribute is inappropriate for accessibility reasons and that the aria-disabled attribute should be used instead.

The following code is an example of a form in which the submit button is disabled until the input values match the correct format.

<form>
  <p><label>Part number:
    <input pattern="[0-9][A-Z]{3}" name="part" title="A part number is a digit followed by three uppercase letters." />
  </label></p>

  <p><button type="submit" disabled="">Send</button></p>
</form>

<script>
document.querySelector('input').addEventListener('input', (ev) => {
  document.querySelector('button').disabled = !ev.target.validity.valid;
});
</script>

In this case, they say, the disabled attribute should use aria-disabled instead, since the very existence of the submit button cannot be recognized by navigating with the Tab key.

However, I believe the following. The behavior of disabled and aria-disabled should be the same, and if being unable to focus is a problem, we should avoid disabling the element in the first place.

So why does aria-disabled not necessarily disable focus?

Is it justifiable to avoid disabled in favor of aria-disabled because I want to disable an element but still give it focus?

Link to the version of the specification or documentation you were looking at at.

Link to documentation: https://w3c.github.io/aria/#aria-disabled

[JAWS-test]

See https://www.w3.org/WAI/ARIA/apg/practices/keyboard-interface/#focusabilityofdisabledcontrols

[SaekiTominaga]

Thanks for sharing the link!

It makes sense now that I understand the use case that even disabled elements should be focusable.

However, as I noted in my first comment, there are many who argue that the disabled attribute should be avoided.

I think the current explanation of aria-disabled is one of the reasons for the misunderstanding that disabled should be avoided unnecessarily.

Even if it is not as specific as APG, could the wording be changed to be a little clearer?

I would like to hear everyone opinions.

[JAWS-test]

Deactivating the submit button is bad because it violates WCAG SC 3.3.1. SC 3.3.1 requires error messages to be in text form. If I do not display an error message and only use the deactivated submit button to communicate that there is an error, then this is problematic. This would not be better if the submit button receives the focus and is marked with aria-disabled

[pkra]

This question appears to have been answered. As per today's WG call, we're closing this issue. Feel free to follow up.