1630988 - Don't make all descendants of aria-activedescendant focusable

Status: RESOLVED WONTFIX

(Core :: Disability Access APIs, defect, P3)

Description

[Eitan Isaacson [:eeejay]]

Currently all nodes with IDs that are descendants of aria-activedescendant are focusable.

This is problematic for at least 3 reason:

1. It's an arbitrary application of the focusable state. Having an ID does not mean the item ever becomes an active descendant target by the web app. The inverse is true too, not having an ID doesn't mean the node won't receive one in the future while simultaneously setting it as the active descendant target.
2. Advertising a focusable state means the user can directly set the focus of the item. Our TakeFocus method now allows any IDed item to become "active" and changes the aria-activedescendant attribute on the ancestor! This is a violation of spec, and not very helpful for most web app's states that probably don't have mutation observers for that kind of contingency.
3. If we are to universally notify of focusable event state changes (bug 1629162), it becomes prohibitively expensive if you need to walk an entire subtree and find all the "focusable" descendants when aria-activedescendant is added or removed.

Comment 1

[Eitan Isaacson [:eeejay]]

Attachment: Bug 1630988 - aria-activedescendant targets should fire FOCUSABLE state changes.

When an accessible becomes an active descendant it should gain the FOCUSABLE state, and lose it when it stops being an active descendant.

In addition, not all accessibles with DOM node IDs that are descendants of aria-activedescendant should be FOCUSABLE.

Comment 2

[Eitan Isaacson [:eeejay]]

Parking a patch here for any future assignee to be inspired.

Comment 3

[James Teh [:Jamie]]

As things currently stand, this would be a spec violation. See section 4.3.2 of the ARIA spec:

4. For any element with an ID attribute, where the element is a descendant of an element with the aria-activedescendant attribute, apply the following accessibility API states to the target to ensure the object is accessible:
A. Focusable, if the element also has a WAI-ARIA role, because the aria-activedescendant of the container can potentially point to it.

We can argue this is wrong, but if we want to do that, we need to argue it at the spec level.

Comment 4

[James Teh [:Jamie]]

Our TakeFocus method now allows any IDed item to become "active" and changes the aria-activedescendant attribute on the ancestor! This is a violation of spec, and not very helpful for most web app's states that probably don't have mutation observers for that kind of contingency.

This at least is no longer the case after bug 1305428.

Given that "fixing" this would be a spec violation (see comment 3), I'm closing this for now. We can reopen if we decide to push for a spec change here.