Re: Shadow DOM and the accessibility tree

I thought of another shadow-DOM complication that needs to be defined for
accessibility mappings:

How are ID REFs matched? For example, for labelled-by relationships and so
on.  With shadow trees, an ID is no longer expected to be unique for the
entire document, only for the local node tree.

I suspect that in many cases with web components, it would be convenient if
all ARIA relationships were constrained to the local shadow tree.  That
preserves the general encapsulation goals of web components, and helps
prevent ID conflicts between different components.

For my <use> element case, however, that encapsulation would often be
problematic, since the shadow DOM content are often clones of content from
the main document, but the labelling element might not also be cloned.  For
example, in a scatterplot chart you may have 100s of copies of a marker
symbol, which are all labelled by the same text from a legend.  The legend
is part of the main DOM, not the shadow DOM for each symbol.

My preferred compromise:
Match ID REFs in the local shadow tree first; if a match isn't found,
search for the ID in the host element's tree, and if applicable in the
host's host's tree, recursively on up to the main document.  However, never
match in a child or sibling element's shadow tree.  If the shadow tree is
closed, then only match in the local tree, not in the host.

~ABR

On 18 July 2016 at 15:35, Amelia Bellamy-Royds <
amelia.bellamy.royds@gmail.com> wrote:

> 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
>