Should aria-activedescendant targets still require an id in order to receive the focusable state?

[jcsteh]

Section 4.3.2 of the ARIA spec states:

4. Apply the following accessibility API states to any element with an ID attribute that can be referenced by an element with both an aria-activedescendant attribute and has DOM focus. ...
   1. Focusable, if the element also has a WAI-ARIA role.

This makes exposure of the focusable state conditional on whether the target has an id attribute. This made sense until relatively recently when the only way for aria-activedescendant to refer to a target was using an id. However, with element reflection, ariaActiveDescendantElement can refer to an element which does not have an id.

Given this, is this id requirement still valid? Should it be removed?

CC @aleventhal, @cookiecrook.

[aleventhal]

FWIW, Chromium also requires the role attribute on the descendant, and we have some special cases for dealing with an input field that controls a listbox/grid/etc. where the input field has the aria-descendant. Link to code.

Does anybody know which ATs use the focusable state and for what? Under the current standards, it's not possible to get the focusable state to be perfect for active descendants.

[jcsteh]

So the use case that caused me to raise this issue is Windows Voice Access, which seems to require that tabs (as in role="tab") have the focusable state in order for them to be considered actionable. I have no idea why, nor am I sure what other controls this applies to.

[jcsteh]

FWIW, Chromium also requires the role attribute on the descendant

So does Firefox; code.

[pkra]

I took this yesterday but it seems to me there's more language around IDs that should be overhauled (e.g. the spec's definition of "identify", other relationship properties). I'll try to get this started though.