Re: Proposal: move accessibility implementation requirements from HTML to HTML acc mappings spec

This proposal worries me, since it means expressing HTML's accessibility semantics not in terms of ARIA, but instead directly in terms of platform APIs.

I would much rather see a two-tier separation, where HTML expresses its accessibility semantics in terms of ARIA, which itself provides a platform-independent interface to platform accessibility APIs.

This would guarantee that HTML does not grant itself any "magic powers" that are not accessible to web developers when building their own custom elements, which is important to us on the Blink team. We recognize that currently HTML does have such magic powers, but we would like to reduce them (presumably by expanding ARIA?), and not codify them as an intrinsic part of HTML.

I am still pretty new to this space, so I am not sure if I have the particulars right, or if this is even a feasible approach. But I think an example of this would be, for example, expanding ARIA to include a "caption" role, with the platform API mappings given in [1], and then saying that <figcaption>s accessibility features are defined entirely by having aria role of "caption."

I am curious whether you think this approach is feasible, and if so, what it would mean for your proposal.

[1]: http://rawgit.com/w3c/aria/master/html-aam/html-aam.html#el-figcaption

Received on Tuesday, 2 September 2014 12:41:11 UTC