HTML-AAM: should we have some general language for sub-doms?

[jasonkiss]

From @cyns on January 12, 2016 18:33

Canvas has an author-supplied sub-dom, which also maps into the accessibility api tree
The audio and video elements can have a whole tree of children if @controls is present.
Should we add some general language to the document on how to handle these situations?

Here's what we have for UIA for canvas now. It seems inadequate.
Control Type: Image
NOTE: subdom elements will be mapped separately.

Copied from original issue: w3c/aria#141

[jasonkiss]

Here's a first stab at elements that are typically complex widgets with sub-trees of accessible objects in certain APIs, and that we might want to address in a distinct section, instead of overwhelming the individual mapping table entries with this level of detail.

• audio
• video
• canvas
• input@type=color
• input@type=date
• input@type=file
• input@type=datetime-local
• input@type=number
• input@type=week

[asurkov]

Do you have ideas who to approach these? It seems the format is currently restricted to a table, which doesn't have flexibility of adding random stuff.

[jasonkiss]

We can add a distinct section to the document that discusses how compound widgets and their sub-trees are typically exposed across different UAs and a11y APIs. This section would replace the need to include this info with each element's mappings in the table.

[rahimabdi]

Closing, to be handled by two new issues:

• How to handle <canvas> sub-dom/fallback content: Specify handling of fallback/sub DOM content for <canvas> #556.
• Propose UA requirements for complex <input> Shadow DOM parts and mappings (related to: Review/revise mappings for input type=file · Issue #421 · w3c/html-aam (github.com)): Propose UA requirements for <input> Shadow DOM mapping #557.