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.