Re: Shadow DOM and the accessibility tree

On 18/07/2016 22:35, Amelia Bellamy-Royds wrote:
> Is anyone working on specs for mapping shadow DOM content to the
> accessibility tree?

No specific specs yet, but it's obviously something we've been thinking 
about in terms of Web Components/Shadow DOM.

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

AFAIK there is none.

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

Yes, this is effectively how it works for native elements like <audio> 
and <video> that use a shadow DOM.

We also have a much larger piece of thinking to do in terms of 
extensibility - what developers should do when creating an entirely new 
component. That goes beyond the shadow DOM mapping though.

>
> *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?
>
My hunch is that static content is not a primary use case for Web 
Components, though it may well be so for SVG. Having given it only brief 
consideration, I think the iframe model might be the way to go?

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


We need to look at the use cases for SVG <use> and Web Components/Shadow 
DOM, to find out what the similarities are and where there are 
differences. It's possible we might end up with an AAM for Shadow DOM 
(that may/may not include SVG <use>).


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


Léonie.


-- 
@LeonieWatson tink.uk Carpe diem

Received on Tuesday, 19 July 2016 08:06:18 UTC