Accessibility: Disabled controls should not receive keyboard focus

[swashbuck]

Subject of the issue

We have recently had an accessibility audit for one of our clients. The consulting agency flagged the following issue regarding the disabled View button:

When using the Tab key to navigate the page, the disabled View links receive focus unexpectedly. Disabled controls should not receive keyboard focus. Across the site, there are other instances of disabled controls receiving keyboard focus.

A keyboard user expects to activate a focused element. They may be confused if this doesn't work.

Their recommendation:

Disabled controls should not receive keyboard focus. Currently the view links are using aria-disabled="true" to indicate programmatically that they are disabled. Unlike the disabled attribute, aria-disabled does not prevent keyboard focus. Add tabindex="-1" instead to prevent the links from being focusable.

Across the site, also consider not disabling controls where it can be avoided. We recommend not disabling buttons/links, instead, leave them active and provide feedback to the user to tell them what to do before if they try to activate it before it's ready. Otherwise, remove the disabled control until the function becomes available. In this case, the View link could be removed, leaving the locked icon and text instructions.

Type: WCAG 2
Principle: Operable
Level: A
Severity: Medium
Guideline: 2.4 Navigable
Success Criteria: 2.4.3 Focus Order (A)

Question

Do we agree with this advice? If so, there are several other places that would need to be updated in plugins and core.

Screenshots

[oliverfoster]

We use aria-disabled primarily for screen reader users, there is a small cost to non screen reader keyboard users.

References:
tabindex, aria-hidden, aria-disabled, disabled, interactive content , accessible name, object permanence

Glossary:

type	description	typical html	typically available to user groups
not focusable	not in the normal tab flow	tabindex="-1"	sight, mouse
not readable	cannot be reached with a screen reader cursor	aria-hidden=true	sight, mouse, keyboard
focusable	in the normal tab flow	tabindex="0"	sight, mouse, keyboard
readable	can be read by a screen reader using either focus via tab or the screen reader cursor using the arrows, enter, space or any other shortcut	:not(aria-hidden=true)	sight, mouse, keyboard, screen reader cursor
disabled	where an interactive content element is disabled	disabled=true	sight
aria-disabled	where an interactive content element is disabled	aria-disabled=true	sight, mouse, keyboard, screen reader cursor

Interactive content with a disabled attribute are not focusable and not readable and not available to mouse, keyboard or screen reader cursor users.

When given the aria-disabled attribute, interactive content becomes both focusable and readable - the screen reader prepends "unavailable" to the accessible name.

We use aria-disabled to allow screen reader users to see that there is some disabled interaction, it's an effort to leverage object permanence to lower cognitive load, whereby user interface elements do not appear and disappear without warning, only become disabled and enabled. Invariably all disabled element in adapt will become enabled through an interaction or were enabled and have been submitted. We do not have permanently disabled controls.

Icons and screen reader text have been added to buttons throughout to show sighted users that an element is locked. On pagination left/right ends there is no icon to explain why the button is disabled, the user must infer from the 1 of x labels.

That these disabled items can receive focus is by design, it allows screen reader users to use tab and screen reader cursors to perceive disabled elements.

Articles about why aria-disabled is better than disabled:
https://css-tricks.com/making-disabled-buttons-more-inclusive/
https://a11y-101.com/development/aria-disabled

Articles on why disabled buttons generally suck:
https://adamsilver.io/blog/the-problem-with-disabled-buttons-and-what-to-do-instead/
https://axesslab.com/disabled-buttons-suck/

We had a long discussion here about greyed vs opaque disabled buttons.

Adding warnings about what the users should do when they accidentally click a disabled button was discussed in the same issue on disabled buttons and resulted only in the reinclusion of the adapt-contrib-instructionError plugin for disabled question submit buttons. We could go further and add notify errors for all disabled buttons, but I think that is quite overkill with the locked icons, additional screen reader text and the aria-disabled buttons.

I do not at all agree with the advice, it would worsen the experience of screen reader users for a negligible benefit to keyboard tab users i.e. that they would not have to tab through a few disabled buttons.

Previous issue #108

[swashbuck]

Thanks, @oliverfoster . I'll include this in our response to the a11y consultants.

[oliverfoster]

Wcag 2.4.3 doesn't mention disabled buttons as far as I can tell https://www.w3.org/WAI/WCAG21/Understanding/focus-order.html