Tree Inclusion focus/activedescendant requirements need clarification

[cookiecrook]

From:
https://w3c.github.io/aria/#tree_inclusion

This bullet covers two disparate requirements and should therefore be split into separate bullets with clarifications: one regarding focus, and the other regarding activedescendant.

Elements that are focusable, or have an ID attribute and an ancestor with the aria-activedescendant attribute that matches the implicit or explicit semantics of the required context role. In either case, the element may receive focus and may fire an accessibility API focus event.

Comments individually:

Elements that are focusable, […] may receive focus and may fire an accessibility API focus event.

Hidden elements that are focusable generally are not exposed unless they become focused. I'd suggest that this be change to include something like both "visible elements that are focusable" and ~"hidden elements if/when they become focused."

Elements that have an ID attribute and an ancestor with the aria-activedescendant attribute that matches the implicit or explicit semantics of the required context role.

This is confusing. I can't parse "aria-activedescendant attribute that matches the implicit or explicit semantics of the required context role." The aria-activedescendant attribute value is an IDREF, so I don't know how an IDREF would match "the implicit or explicit semantics of the required context role."

[carmacleod]

@cookiecrook

This similar paragraph in Core-AAM General rules for exposing WAI-ARIA semantics seems easier to parse:

A DOM element is included if it has semantic significance. As a first approximation, it is significant if it has an explicit or implicit WAI-ARIA role, state, or property, is focusable or interactive, or bears a relationship with some other element (e.g., the element referenced by aria-controls).

We are planning to move some of the Core-AAM content into the ARIA spec, i.e. replacing or augmenting what is currently there. (See w3c/core-aam#28)

[carmacleod]

@cookiecrook

I can't parse "aria-activedescendant attribute that matches the implicit or explicit semantics of the required context role."

I can't parse that either. 😄 Must be a copy/paste error. I changed it to:

"aria-activedescendant attribute that matches the ID"

So the single bullet split into 2 separate bullets now reads:

• Elements that are focusable may receive focus and may fire an accessibility API focus event.
• Elements that have an ID attribute, and are owned by or have an ancestor with the aria-activedescendant attribute that matches the ID, may receive focus and may fire an accessibility API focus event.

I added the bit about "owned by" because I think it needs to be there - correct me if I am wrong.

Regarding your comment about hidden elements:

Hidden elements that are focusable generally are not exposed unless they become focused. I'd suggest that this be change to include something like both "visible elements that are focusable" and ~"hidden elements if/when they become focused."

I assume that you mean "aria-hidden", because any other type of hidden can't take focus. Unless you mean "off screen"? Anyhow, perhaps that merits a separate point for clarity, something like:

• Elements, or any of their descendants, that receive focus and fire an accessibility API focus event even though they have aria-hidden set to true.

(Is it really true that those aren't generally exposed by UA unless they become focused?)

I decided to make the 3 bullets that reference focus be "sub-points" of the general "may fire an event" bullet, as follows:

• Elements that may fire an accessibility API event.
  • Elements that are focusable may receive focus and may fire an accessibility API focus event.
  • Elements that have an ID attribute, and are owned by or have an ancestor with the aria-activedescendant attribute that matches the ID, may receive focus and may fire an accessibility API focus event.
  • Elements, or any of their descendants, that receive focus and fire an accessibility API focus event even though they have aria-hidden set to true.

Hope that helps clarify.

[carmacleod]

(Is it really true that those aren't generally exposed by UA unless they become focused?)

I answered my own question. Yes, it's true... :)
The Core AAM table for aria-hidden says:

• "aria-hidden=true on an unfocused element" SHOULD NOT be exposed.
• "aria-hidden=true when element is focused or fires an accessibility event" is exposed on all platforms, with most platforms mapping aria-hidden to a "hidden" property; AX exposes the element without mapping aria-hidden.

New question: I guess I should try to capture "... or fires an accessibility event".
If I rewrite the 3rd "focus" bullet as follows, do you think it's clear enough?

• Elements, or any of their descendants, that receive focus and fire an accessibility API focus event (or any accessibility API event) even though they have aria-hidden set to true.