Why does the 1.2 APG advocate that disable components are keyboard reachable?

[mbgower]

Describe your concern

While creating a selectable tree, a developer reviewed their work with us and asked about making disabled items in the tree focusable. They cited the following:

However, there are some contexts where it is common for disabled elements to be focusable, especially inside of composite widgets. For example, as demonstrated in the § 3.15 Menu or Menu bar pattern, disabled items are focusable when navigating through a menu with the arrow keys.

It then goes on to say:

For the following composite widget elements, keep them focusable when disabled: Options in a Listbox Menu items in a Menu or menu bar Tab elements in a set of Tabs Tree items in a Tree View

Our concern with this is that it does not seem to be reflect normal operation. For instance, the established interaction in a menu is that disabled menu items are not reachable by keyboard. The same is the case in a select. That is even documented, for instace:

disabled If this Boolean attribute is set, this option is not checkable. Often browsers grey out such control and it won't receive any browsing event, like mouse clicks or focus-related ones. If this attribute is not set, the element can still be disabled if one of its ancestors is a disabled element.

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

Link to documentation APG Focusability of disabled controls

Does the issue exists in the editors draft (the editors draft is the most recent draft of the specification)?

This section does not appear to exist in the editors draft. So we just wanted to verify that this guidance on disabled components is either under review or is being removed/revised in the next version.

Final note: We recognize the inequality of the current implementation, where a sighted user able to read the greyed text of the disable component is given information on the disabled component not provided to a blind user. This issue is raised to address inconsistency of guidance, not address the underlying issue.

[jnurthen]

Does the issue exists in the editors draft (the editors draft is the most recent draft of the specification)? This section does not appear to exist in the editors draft. So we just wanted to verify that this guidance on disabled components is either under review or is being removed/revised in the next version.

The editors draft linked here is the ARIA spec (as you filed this issue against the ARIA spec not against APG). I'm moving this issue to the practices repository.

[JAWS-test]

Our concern with this is that it does not seem to be reflect normal operation. For instance, the established interaction in a menu is that disabled menu items are not reachable by keyboard.

In non-web software, disabled menuitems often get keyboard focus. In web applications this should also be the case, as I have no chance to read the items with the virtual cursor using the screen reader, for example. Therefore, they should receive focus in form or application mode.

Related: https://github.com/w3c/aria-practices/issues/2176

[mcking65]

@mbgower wrote:

Does the issue exists in the editors draft (the editors draft is the most recent draft of the specification)? This section does not appear to exist in the editors draft. So we just wanted to verify that this guidance on disabled components is either under review or is being removed/revised in the next version.

You linked to the editor's draft of ARIA, not the editor's draft of APG.

There are no issues calling for removal of this guidance. There is no work in progress to remove it.

Final note: We recognize the inequality of the current implementation, where a sighted user able to read the greyed text of the disable component is given information on the disabled component not provided to a blind user. This issue is raised to address inconsistency of guidance, not address the underlying issue.

The APG is inconsistent with browser implementations of select for the purpose of resolving the underlying problem; all users should have equal access to the fact that certain elements are disabled. This is a situation where ARIA gives authors the option of creating components with behaviors that some authors may consider more accessible than what is available from browser implementations of similar elements.

This is similar to the type of consideration raised in #2258. If we want consistency, and want to lean in the direction of greater accessibility, perhaps advocating for changes to browser behavior would be most beneficial.

In the meantime, we might want to consider whether it would be helpful if the APG were to appropriately note more of the differences between APG guidance and examples and native HTML element behavior. This is done explicitly in the radio group examples and in the select-only combobox example.

[mbgower]

The APG is inconsistent with browser implementations of select for the purpose of resolving the underlying problem

But it isn't just browser implementations. Disabled components and subcomponents not receiving keyboard focus is the way operating systems have behaved pretty much since GUI systems were introduced.

A primary concern with this development, and with a few other moves by the ARIA/APG work, is that firmly established conventions -- things that have been the way they are for decades -- are being modified by the APG without the underlying systems also being tackled. The result is an environment that is more confusing for some users and more difficult to operate.

Disabled components are problematic from many angles. Similar problems exist for their low contrast implementation (not everyone can see them sufficiently, so users without ATs who cannot are disadvantaged from those who can in regard to deriving information). I'm not advocating the APG try to tackle that! Just that a piecemeal approach to modifying state presentation/interaction is likely to create unanticipated/under-appreciated problems as well. It would be disjointed enough tackling this at the HTML level. Doing it with just ARIA?

Other APG changes of direction have caused real and unresolved churn in our organization. I'm assuming we're not alone. As more developers and designers get exposed to such 'make disabled components navigable' advocacy, I'm anticipating some real problems. It also makes it more difficult for us to advocate that teams "just follow the APG."

[mcking65]

@mcking65 wrote:

The APG is inconsistent with browser implementations of select for the purpose of resolving the underlying problem

@mbgower wrote:

But it isn't just browser implementations. Disabled components and subcomponents not receiving keyboard focus is the way operating systems have behaved pretty much since GUI systems were introduced.

I am not aware that is the case. There are examples of focusable disabled buttons, menuitems, and just about any other control I can think of in native Windows and macOS apps. I am using Chrome right now, and on both Mac and Windows, I can find focusable disabled controls in the chrome of the browser.

I do not believe there is any consistency across time or operating systems wrt focusability of disabled elements.

@mbgower wrote:

A primary concern with this development, and with a few other moves by the ARIA/APG work, is that firmly established conventions -- things that have been the way they are for decades -- are being modified by the APG without the underlying systems also being tackled.

The process of APG is to observe those firmly established native behaviors and synthesize and align them as best possible, placing higher priority on the behaviors that we believe are likely to be most beneficial to users with disabilities. We attempt to make all these decisions carefully. There is often not a clear approach, so the APG attempts to provide clear guidance couched in flexible and non-normative language. The task force is open to discussion of all such issues, including the focusability of disabled elements.

That said, we do not have a UXR subgroup. I've always been concerned about that. Appropriate studies to support the TF work would be a large and expensive undertaking. There is also the matter that we don't yet have sufficient screen reader interoperability to generate valid study results for a significant portion of ARIA attributes. The aria-at project is aiming to tackle that problem. Consistent and robust AT support of ARIA will make robust UXR feasible.

Additionally, It is not part of the APG scope to attempt to fix inconsistencies between operating systems.

@mbgower wrote:

The result is an environment that is more confusing for some users and more difficult to operate.

That is the opposite of APG TF intentions. It would be wonderful if you could help resolve any problems of this nature that are arising.

As more developers and designers get exposed to such 'make disabled components navigable' advocacy, I'm anticipating some real problems. It also makes it more difficult for us to advocate that teams "just follow the APG."

Please provide the problem statements. And, if you have proposals for resolution, include those as well. Even better, if you'd like to do so, please join the TF to help us work on them.

[mbgower]

I am using Chrome right now, and on both Mac and Windows, I can find focusable disabled controls in the chrome of the browser.

Maybe we're talking about different things? If I pull up the Browser's application menu, on almost all the menus there are items that are disabled and when I arrow down, the disabled items are skipped. I think the following should be repeatable:

1. Launch a new window of the Chrome browser (so you only have 1 tab open)
2. Bring up the application menu (by whatever means normal for you)
3. Move to the Bookmarks menu
4. Arrow down through the list. The first items should be Bookmark Manager, Bookmark This Tab... and Bookmark All Tabs.... The Bookmark All Tabs... option is disabled, and the next down arrow will take you to the first item in your Bookmarks

The image below shows those first three menu items in Bookmarks, with the third one visually disabled.

PS I will note that if you are on a Mac and you go in and choose Enable Full Keyboard Access in Accessibility>Keyboard, this disabled item will now be in the order, but the Mac implementation of Full Keyboard Access is so... unique that it doesn't really help the discussion. For instance, that implementation puts every unselected radio button in a group into the tab order, amongst many other oddities which make it an entirely different paradigm (non-interactive content like headings and paragraphs get focus, etc)

[mbgower]

Even better, if you'd like to do so, please join the TF to help us work on them.

I'd like to. But I'm overcommitted as it is, @mcking65. Trying to find a resource to take Carolyn's place!!

[JAWS-test]

@mbgower

Chrome seems to me to be an exception. In the rest of the desktop apps I checked on Windows 10, disabled menuitems get the focus (as I wrote above, by the way)

[mbgower]

How about Firefox? If I open up a Firefox browser and go to Firebox button, on both Mac and Windows, the "Recently close tabs" and "Recently closed windows" menu items are disabled and not in the navigation.

On the other hand, I did find that if I issue a Alt+S while in Firefox on Windows, that it displays the same menu and navigates onto the disabled components! I've pasted in screen snippets of both menus for those sighted users who are trying to understand the contexts.

So it's a real hodge-podge!

I had a look at some of the points in the background info on this, and agree that something is needed that tackles a number of challenges, including the question of the navigability of disabled/inactive components as well as the difficult-to-resolve 'greyed out' styling versus a need to minimum contrast yet visually clear distinguisher for disabled states (and read-only, for that matter). It could be that a more developed read-only state for controls is a possible path forward.

[sivakusayan]

My organization is also dealing with this issue right now. Is this recommendation more or less final? It feels like from this thread we're not sure about this behavior yet.

It seems like in web at least, screen reader users can technically find disabled elements using the virtual cursor. So maybe it's okay that the elements are not focusable? However, I'm not sure if this is good UX or not. This thread on UXStackExchange seems to imply that screen reader users will miss disabled buttons that are not focusable. This thread brings up a similar topic, but I wasn't able to find a definite conclusion by reading the email thread.

It's unfortunate that there is no consistency - in an outsider's opinion, it feels like the exact solution the working group lands on isn't as important as making sure the industry can agree on any decent specific standard. I feel like users can eventually learn how to find disabled elements assuming that websites are consistent in their strategy.

[mbgower]

It's unfortunate that there is no consistency

Consistency of interaction is an important goal to try to achieve. But it's equally important to understand all the ramifications of changing a model.

One of my concerns with the current APG direction is that it seems to make some disabled components navigable while leaving others non-navigable. Will most users (and for that matter, testers) be able to keep track of which disabled elements are supposed to be reachable and which aren't?

There is also the question of time on task. Especially if this is the start of a push to make all disabled elements navigable, what are the likely effects? At the moment, many interaction designs are relatively quick to complete because the unwanted actions are removed from the navigation order. At what point does having to navigate past a bunch of inoperable disabled elements disrupt my ability to get to actions I can actually do?

Also, what are the likely results of this being adopted? Some will be inclined to recommend that designs begin researching the effects of stripping out disabled components from designs to ensure time on task is not worsened for keyboard users -- only add items/components to the UI as they are logically required (using progressive disclosure, etc). What effect would such a development have on users with different cognitive and learning disabilities?

There are all interesting questions. Maybe work has been done to show what we gain and lose by making all disabled elements navigable? Can we get that research posted? From my brief investigating during this issue, it appears there has been a slow adoption of this principle for major operating systems. That's a fairly controlled environment. Is it likely to be as beneficial in the wild?

[JAWS-test]

@sivakusayan

It seems like in web at least, screen reader users can technically find disabled elements using the virtual cursor.

This is not always true. E.g. a submenu or a selection list of a drop down is only shown upon interaction: Then I can only perceive them in the form or application mode and not with the virtual cursor (because as soon as I switch to this, the faded-in contents are hidden again).

[JAWS-test]

@mbgower

I don't fully understand your concerns. When I read through the entire chapter https://w3c.github.io/aria-practices/#kbd_disabled_controls, I see that no standard is set here, but rather recommendations are made. It is explicitly emphasized that there is no right and wrong, but each method has advantages and disadvantages. It is also justified why in certain cases it can make sense that disabled elements get the keyboard focus.

Furthermore, the recommendations are based on the standard of desktop applications: Single disabled elements do not get the focus, if disabled elements are inside a widget (menu, drop down list etc.) they get the focus.

[mbgower]

@JAWS-test

When I read through the entire chapter..., I see that no standard is set here

Two things about this statement. First, the APG does not have the weight of a spec, so no "standard" is set, but if one is looking at the APG for guidance, the following is pretty emphatic from that perspective:

For the following composite widget elements, keep them focusable when disabled: Options in a Listbox Menu items in a Menu or menu bar Tab elements in a set of Tabs Tree items in a Tree View

I agree there is a preamble stating there is no perfect answer. But I also think that when there's a bulleted recommendation like that, it carries more weight.

You also said this is "based on the standard of desktop applications." Can you please provide me with some references? I didn't do much of a technical dig, but in a quick search the only specific thing I wound was the following in Windows App Development info on Keyboard Interaction:

Navigation to disabled items. By default, disabled items are not exposed through standard keyboard navigation.

I also have slight alarm bells about this statement in the doc:

For elements that are in the tab sequence when enabled, remove them from the tab sequence when disabled.

No problem with that sentiment. However, I'm seeing some people advocating (here and elsewhere) that tab navigation be provided where arrow navigation is (for instance, you tab to a menu, you press Enter to open it, you tab through each menu item). So what happens when something that looks like a 'menu item' is actually a link but the menu item is disabled? It seems to me to get messier.

[sivakusayan]

This might be a little nitpicky, but...

@JAWS-test

I see that no standard is set here, but rather recommendations are made. It is explicitly emphasized that there is no right and wrong, but each method has advantages and disadvantages.

I'm not sure if I personally read it that way - the way I interpreted the preamble was that "this is a complex problem, but after thinking about it for a while we determined this to be the best way forward". I didn't necessarily understand that this is one possible approach, but other approaches are valid, too. However, that might just come down to the following:

@mbgower

First, the APG does not have the weight of a spec, so no "standard" is set,

I suspect that, for the average web developer, the APG is probably perceived to have as much weight as the ARIA specifications. I suspect this from both my own experience trying to learn about accessibility as well as talking with around 50-60 other web developers at my company. I suspect this is the case because:

• The APG has the same styling as the ARIA specifications, giving it a heavier feel (maybe moving this information to the new APG will help)
• Recommendations from authority figures in the industry may as well be perceived as standards
• I find that a lot of people are intimidated by the ARIA specifications (and accessibility in general, but that's another topic), and so instead of learning about concepts like required context role and the like, we learn to more or less copy-paste implementations from the APG

I agree there is a preamble stating there is no perfect answer. But I also think that when there's a bulleted recommendation like that, it carries more weight.

Personally speaking, I don't think the bulleted points give these more weight to me - I like them because it makes the information easier to scan. Maybe some kind of bolded sentence in the paragraph before the bullet points (to draw the attention of people who are skimming) can make it clear that this is a recommendation, but not a standard.

[JAWS-test]

@mbgower

You also said this is "based on the standard of desktop applications." Can you please provide me with some references?

In most Windows desktop applications, disabled menu items receive focus. Whether this has been specified this way by Microsoft, I don't know. There are only a few exceptions (e.g. Chrome), which we had already discussed.

Otherwise, I am probably the wrong person to discuss this, as I did not write these guidelines. I just wanted to justify why they seem to make sense to me. Everything else should be decided by the ARIA Working Group.

I can only add that many SAP applications handle the problem perfectly: In the settings the user can choose whether disabled elements should receive the keyboard focus or not.

Thus, a corresponding setting in the operating system would be optimal, which would make it possible to determine the degree and efficiency of keyboard operation. The browsers and all native applications should then respect this setting. But that is pie in the sky. So for now, the question of what is recommended here for ARIA in terms of disabled should be clarified.