Shadow DOM and the accessibility tree

Hello all,

Is anyone working on specs for mapping shadow DOM content to the
accessibility tree?

I'm updating the SVG-AAM spec to use the shadow DOM model for SVG <use>
elements, allowing the re-used content to be fully accessible.  I haven't
found any other guidance in ARIA specs with respect to processing shadow
DOM content.

For the most part, shadow DOM could be addressed with a few lines of prose
in Core AAM, requiring that the "composed" (or flattened) DOM tree be used
as the basis for generating the accessibility tree.  That is, if an element
has shadow content that is replacing its official DOM children, the shadow
content should be used.

This would cover custom elements / web components, but it should also cover
native HTML widgets (e.g., date-picker inputs, videos with controls).
Under the latest shadow DOM model, these are described as "closed" shadow
DOMs.  The shadow DOM is closed to author scripts, but there is still an
internal model where the HTML element is replaced by the constituent
buttons, labels, sliders, and so on.  All of which, of course, needs to be
available in the accessibility tree.

*The one complication I've come across is what to do with
role=presentation.*  Should it mean that the entire shadow tree gets
excluded?  Or should it be treated like role=presentation on an <iframe>,
where the means of embedding content is presentational, but the embedded
content is still accessible?

For native widgets, the fact that widget content is keyboard accessible
should normally over-ride a role of presentation.  But if the author
disabled the element or removed it from the tab order, then I think a
role=presentation would currently exclude the entire widget.  I'm not sure.

For custom web components or for SVG <use> elements, this is no longer
hypothetical.  If the content is decorative or redundant, I suspect many
authors would think that role="presentation" should be enough to exclude
it.  We'll need to add clear authoring guidance if that's not going to be
the case.

On the other side, if a presentational role on a shadow-host element
automatically applies to the entire shadow tree, then how do you convey the
(very common) situation where the host element has no semantic meaning of
its own, it is only a placeholder for the structured content in the web
component template?

*My preference is to use the <iframe> model of interpretting
role=presentation.*  That means encouraging authors to always use
aria-hidden=true to actually hide an element (and all its child or shadow
content), so that role=presentation is only used for "transparent" markup.
But again, there may be cases where this conflicts with current behavior
for native widgets.

~Amelia