Hi Shane,
It occurred to me that we could actually use the aria implementation guide
as the core API mapping spec. as long as HTML, SVG, etc. mapped to the
native semantics.
I think what we would do is basically call the WAI-ARIA Implementation
Guide the User Agent Accessibility Implementation Guide. It would end up
being a general accessibility API mapping guide to be used by web host
languages.
This, I think would simplify work on host language mapping guides for
things like HTML and SVG as they would be responsible for:
Defining when no mappings would occur (In SVG, unless you apply an ARIA
role or perhaps something like <TITLE> or <DESCRIPTION>) you would not
map the element as SVG is persistent.
Defining restrictions on their use
Defining implied host language semantics in terms of WAI-ARIA. We would
then refer back to the mapping in the ARIA spec.
Defining the actual accessible name computation. This is really host
language specific and we could provide general guidance in the User
Agent Accessibility Implementation Guide but refer to the host language
mapping.
>From then on we could define write module extensions to the User Agent
Accessibility Implementation Guide for say:
Graphics: (general drawing constructs, charts, Connectors, etc.). this
would be applicable to SVG and Canvas
Books like ePub - page, bookmark, page numberd. See the Association for
American Publishers document on ePub accessibility plans:
https://nfb.org/images/nfb/documents/html/aapepub3implementation.xhtml
For these we could define ARIA modules that correspond to them.
With respect to this new User Agent Accessibility Implementation Guide we
would:
Provide more information wrt. events. There are events that get
generated that are not discussed in the ARIA Spec. for example.
Reflect the changes in name computation
Include Mobile Accessibility API mappings
Thoughts from the group on this approach?
Rich