Clarify how live region content be announced, given shadow DOM?

[domenic]

Consider the following DOM tree:

<p role="status">
  - <#shadow root#>
    - <slot></slot>
    - <span>B</span>
  - <span>A</span>

This translates to the following flat tree

<p role="status">
  <#shadow root#>
    - <span>A</span>
    - <span>B</span>

Effectively, this element has a flat tree with text content of "AB". However its light DOM children are just "A"; "B" is hidden in the shadow tree. This is somewhat analogous to some user-agent controls, where e.g. the "X" button on a search input would be hidden in the shadow DOM.

This brings up a couple interesting questions that I think are in the scope of the ARIA spec:

• Should AT announce the contents of the flat tree, or the light DOM tree? I.e. should it announce "A" or "AB"?
• Similarly, should AT monitor for changes to the flat tree, or to the light DOM tree? If I change the contents of the hidden-in-shadow-DOM span from "B" to "C", does this cause a new announcement of the live region?

Thoughts appreciated!

[jnurthen]

@domenic is there a definition of flat tree somewhere - this is a new term to me.

[scottaohara]

Apologies for the delay here, did some thinking / testing on this.

The content of the shadow DOM should be exposed to the accessibility tree, so any changes within it should also be picked up by live regions. So, specifically to your question the flat tree should be announced as it could be problematic if content was updating / exposed in the Shadow DOM, but not available to all users.

Fortunately, most current implementations seem to already be heading towards this same conclusion, with some gaps...

Taking your example I created the following test page:
https://scottaohara.github.io/tests/aria-live/shadow.html

Save for an issue specific to Firefox and JAWS, updating light or shadow DOM content in a live region was generally respected. Some other quirks are listed in the results I noted.

If we can help clarify anything further, please let us know!

[domenic]

@domenic is there a definition of flat tree somewhere - this is a new term to me.

It looks like there's no good definition in the specifications, which is a bit surprising. (Instead the specs just refer to specific ways of traversing the DOM tree ancestor/descendant relationships.) But an informal example can be found at https://developers.google.com/web/fundamentals/web-components/shadowdom#lightdom

Apologies for the delay here, did some thinking / testing on this.

Great stuff! It's good to hear that we have mostly-interoperable behavior here, and that the behavior seems pretty reasonable to me.

So maybe to get this in to the spec, we should modify sections like https://w3c.github.io/aria/#aria-atomic which currently say things like (emphasis mine):

When the content of a live region changes, user agents SHOULD examine the changed element...

If aria-atomic is explicitly set to true, assistive technologies will present the entire contents of the element, including the author-defined live region label if one exists.

to be more specific about what they mean by "contents"?

I think there are probably other parts of the spec (not just live regions, but e.g. accessible name calculation) which would also benefit from a more specific definition of contents.

Maybe we need some definition like child text content or descendant text content, but operating on the flat tree? /cc @annevk as DOM editor, and @zcorpan as someone who has recently been helping with this sort of ARIA rigorization work in other issues.

[annevk]

@domenic thus far flat tree has been considered a layout topic as we don't want to necessarily eagerly compute it. See https://drafts.csswg.org/css-scoping/#flattening for the current definition. Accessibility also largely operates on the "layout tree" so that's probably fine and it's mostly a matter of connecting various dots.

[zcorpan]

So we have at least these features (are there others, in accessibility space?):

• accessible name computation and accessible description computation
• live region "content" changes

that need to take these things into account (in addition to light DOM):

• shadow DOM
• CSS generated content

(It's unclear to me if live regions should announce changes to CSS generated content though.)

The "layout tree", while a concept browsers have, is not a concept that is specified, AFAIK.

The flat tree is specified, but doesn't include CSS generated content. For now, specifying things in terms of the flat tree, and calling out CSS generated content where necessary, seems like a good improvement over the status quo.

[scottaohara]

FWIW, updated my test page to include an example of injecting CSS content. Largely works the same as the previous examples.

[pkra]

@jnurthen should we move this to the 1.4 milestone?