In general, an accessibility implementation guide seems useful. Looking at the details a bit:
- For WebKit's purposes in particular, we generally map elements to a cross-platform concept of role which matches ARIA roles whenever possible, and then map that cross-platform role to a platform-specific role depending on the specific accessibility API. So for elements where there is a natural ARIA role mapping, it is more useful to us to have a mapping from the element to the ARIA role, and then a mapping from ARIA role to the various native accessibility APIs. It's unhelpful to also have the direct table from element to native role; I suspect we wouldn't use it, and it would just make it more complicated to figure out the right mapping.
- For elements that do not have a natural ARIA role mapping, a guide on how to map them to native accessibility APIs is helpful. We'd have to invent our own cross-platform role name in such cases.
- The table as it stands seems awfully incomplete. It's hard to evaluate the quality of the information until more of it is filled in.
- We often apply heuristics to adapt inaccessible content, and firm rules about how to map elements could go against that. So it would be better if any native API mapping requirements were suggestions or SHOULD-level requirements instead of MUST-level.
I'll ask our more accessibility-knowledgable folks for their input.
Regards,
Maciej
On Jan 15, 2011, at 7:41 AM, Steve Faulkner wrote:
> A number of people including myself , Cynthia Shelly, Dave Bolter and Rich have started working on HTML to Platform Accessibility APIs Implementation Guide. It is currently intended as a informative reference produced by the W3C HTML WG.
>
>
> The editor of the HTML5 specification has provided some feedback [1] on this document.
>
> I would appreciate some feedback from involved in the accessibility implementation space in regards to the usefulness of documenting the mapping between HTML elements and attributes and the roles states and properties in the various platform accessibility APIs. And what sort of information should be provided, if any.
>
> If as the HTML5 editor states;
>
> "the proposed document is unnecessary. Vendors have not shown an inability to read the existing normative specifications"
>
> then it would be good to know that is not needed and will not be useful to its target audience, so those involved can use their time on more productive pursuits.
>
>
> [1] http://wiki.whatwg.org/wiki/Objections_against_CP_for_ISSUE-129#The_HTML_to_Platform_Accessibility_APIs_Implementation_Guide
>
> --
> with regards
>
> Steve Faulkner
> Technical Director - TPG
>
> www.paciellogroup.com | www.HTML5accessibility.com | www.twitter.com/stevefaulkner
> HTML5: Techniques for providing useful text alternatives - dev.w3.org/html5/alt-techniques/
> Web Accessibility Toolbar - www.paciellogroup.com/resources/wat-ie-about.html
>
>