When to use the disabled attribute vs the aria-disabled attribute for HTML elements?

Question

I'm trying to make a form accessible. Should I make my inputs have both disabled and aria-disabled attributes, or just one?

<label for="textbox1">Input</label>
<input id="textbox1" type="text" name="Text Box" disabled>

Or like this?

<label for="textbox1">Input</label>
<input id="textbox1" type="text" name="Text Box" aria-disabled="true">

Or like this?

<label for="textbox1">Input</label>
<input id="textbox1" type="text" name="Text Box" aria-disabled="true" disabled>

Solution 1

I can take your example, put it in a CodePen, and check it in JAWS and NVDA (sorry, no VoiceOver today):

<label for="textbox1">Input</label>
<input id="textbox1" type="text" name="Text Box" disabled>

You will be happy to know that both NVDA and JAWS skip the field (or if explicitly focused, announce that is disabled).

In short, you do not need aria-disabled any longer. Just use disabled.

You can read a bit more about the ARIA attributes you can dump in this article by Steve Faulkner (one of the editors of the ARIA spec) from 2015 (though aria-disabled is not explicitly listed, the concept is the same): http://html5doctor.com/on-html-belts-and-aria-braces/

If my answer looks similar to your other question about required versus aria-required, that is because it is essentially the same answer.

Solution 2

An important distinction is that when using voice-over the item with just the 'disabled' property will not be tabbed to. However the item with aria-disabled="true" will still be able to receive focus and report to the screen reader as dimmed.

Solution 3

In short, you do not need aria-disabled any longer. Just use disabled.

To complete @aardrian answer.

When you use an HTML control which supports natively the disabled attribute, you do not need the aria-disabled attribute.

If you use a custom control then you can use the aria-disabled attribute. For instance, in the following code, the "Pause" button will be disabled until the "Play" button is pressed (our javascript will then change tabindex and aria-disabled attributes).

<img src="controls/play.png"
  id="audio-start"
  alt="Start"
  role="button"
  aria-disabled="false"
  tabindex="0" />

<img src="controls/pause.png"
  id="audio-pause"
  alt="Pause"
  role="button"
  aria-disabled="true"
  tabindex="-1" />

Note that according to W3C:

Disabled elements might not receive focus from the tab order. [...] In addition to setting the aria-disabled attribute, authors SHOULD change the appearance (grayed out, etc.) to indicate that the item has been disabled.

Comments

[Volker E.]

Thanks for your answer. It's concerning to see that disabled is stated equal with aria-disabled in other answers above. Although ARIA 1.0 doesn't describe disabled as related concept of aria-disabled and that in a popular screen reader like VoiceOver disabled results in elements not being perceivable, as in not read out at all.

[cage rattler]

This is the correct answer. The experience in screen-readers and other assistive devices is very poor using the disabled attribute. Disabled controls are not announced at all during normal navigation. This is the only case I know of where the native HTML solution, even when used properly and when the markup is semantic, is ineffective, and the aria-attribute should be used in it's place.

[Black]

Why does aria exist if it is not usefull at all?

[aardrian]

@Black, Your question makes an assertion that is demonstrably false. ARIA is incredibly useful. In this case since browsers did not properly pass the disabled state to assistive technology, ARIA was needed to bridge that gap until browsers handled it correctly.

[gaurav5430]

So the screen reader would completely ignore the fact there is a button which is disabled? Isn't this very different from the experience that sighted users get? Wouldn't the screen reader users be looking for a submit button even if to know that it is disabled?

[aardrian]

@gaurav5430, no, a screen reader does not completely ignore it. It removes it from the tab flow of the page, just as a browser does for a disabled control. A screen reader user arrowing through the page will find it. If a screen reader is expecting one, that user will generally start arrowing.

[brandonbradley]

One good way to mitigate this is to explicitly put the item into the tab flow by setting tabindex="0" on the element. The disabled element will still be reachable by tabbing then and still be meaningful to screen reader users. This could then also be combined with custom messaging (custom tooltips, or areia-live areas' to let the user know why the item is disabled and/or what they need to do to enable it.

[brennanyoung]

This is the correct answer. The two attributes are not 100% interchangeable, although the semantics are almost identical. Some folks argue that disabled controls should always be removed from the tab order (in which case, use disabled) - and please note that there are usually other ways of discovering UI controls than tabbing. Other folks prefer disabled controls to be 'discoverable' by tabbing (in which case, use aria-disabled, with appropriate styling). You'll be WCAG-compliant either way, but please do careful user testing to discover the right attribute for your project.

[actimel]

It's definitely not as simple as that. If you're making a form that cannot be submitted unless filled properly (sometime it's a requirement) you should use aria-disabled instead of disabled, so that the submit button is not completely hidden from users of assistive technology. You should also link the disabled button with validation errors via aria-describedby or pass the information why the form can't be submitted in some other way. See this examples a11y-101.com/development/aria-disabled

[aardrian]

@actimel using disabled (on a native control that accepts it) disables for all users, keyboard, screen reader, voice, etc. Using aria-disabled only affects screen readers. aria-disabled does not impact keyboard, voice, mouse, touch, etc., unless you also script it. In which case, use disabled.

[actimel]

@aardrian you've missed the point, unfortunately. If you have to implement a design that disables the submit button of a form until it's filled in (which I consider a bad design, but that's my personal opinion), you should use aria-disabled combined with styling and functionality preventing the form submission. It's very puzzling that the submit button would be missing completely for SR users. There are many articles on this topic. E.g. css-tricks.com/making-disabled-buttons-more-inclusive

[actimel]

@aardian I suggest updating you answer, as it's definitely not that simple. Please, go through the articles I've linked.

[aardrian]

Not on SO often anymore, but finally following up. OP asked about using either or both disabled and aria-disabled on a native HTML form element. As such, disabled is sufficient. Your statement about it not being that simple is because you have extended OP's question (to include submit buttons, which is not part of OP question). Additionally, I know both those posts. A11y-101 is not a great resource, and I reviewed the CSS-Tricks post prior to publication.