53

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>
unor
  • 92,415
  • 26
  • 211
  • 360
Ralph David Abernathy
  • 5,230
  • 11
  • 51
  • 78

3 Answers3

42

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.

brandonbradley
  • 607
  • 5
  • 7
  • 2
    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](https://www.w3.org/WAI/PF/aria/states_and_properties#aria-disabled) 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. – Volker E. Jan 08 '19 at 07:23
  • 2
    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. – cage rattler Jan 29 '19 at 19:55
  • 1
    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. – brandonbradley Aug 02 '19 at 20:08
  • 1
    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. – brennanyoung Nov 07 '19 at 15:41
  • This honestly sounds like a browser/screenreader bug. If there are textually-informative onscreen widgets (as disabled buttons generally are) and the browser is concealing their existence from visually-impaired users by omitting them, that sounds like a mistake. I would expect the screen-reader to announce to the user that it is skipping over the disabled button as they tab through. – Pxtl Jul 22 '22 at 15:21
34

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.

Community
  • 1
  • 1
aardrian
  • 8,581
  • 30
  • 40
  • Why does `aria` exist if it is not usefull at all? – Black May 15 '19 at 08:15
  • 4
    @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. – aardrian May 21 '19 at 15:16
  • 4
    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? – gaurav5430 Jun 06 '19 at 19:09
  • 1
    @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. – aardrian Jun 07 '19 at 20:36
  • 6
    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 https://a11y-101.com/development/aria-disabled – actimel Sep 08 '21 at 08:08
  • @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`. – aardrian Sep 20 '21 at 20:00
  • 3
    @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. https://css-tricks.com/making-disabled-buttons-more-inclusive/ – actimel Sep 22 '21 at 08:26
  • @aardian I suggest updating you answer, as it's definitely not that simple. Please, go through the articles I've linked. – actimel Sep 22 '21 at 08:31
  • 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. – aardrian May 03 '22 at 20:53
32

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.

Adam
  • 17,838
  • 32
  • 54