02.09.2014, 16:21, "Steve Faulkner" <faulkner.steve@gmail.com>:
On 2 September 2014 13:40, Domenic Denicola
<domenic@domenicdenicola.com> wrote:
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.
Answering this specific comment at this time, If you have a look at
http://rawgit.com/w3c/aria/master/html-aam/html-aam.html, where available the ARIA abstraction of a role/state or property is listed. acc implementation engineers need to know what acc platform APIs HTML feature x maps to. Thats what is used in the browser, not ARIA abstractions
The acc mapping spec has buy in from browser acc implementers and they are involved in its development, so I am a little unclear what the concern is?
The obvious one would be that instead of working from a spec we know, we're asking a new browser developer (such as those who announced the new Raspberry Pi browser yesterday?) to replicate work based on accumulated knowledge about a bunch of different (and as far as I know not very clearly specified) APIs and how they work.
Likewise, it assumes that all accessibility functionality in existing browsers will be handled by the people who connect them to Assistive Technology and APIs. This seems to run counter to a general preference for "built-in" accessibility - not just at the content level, but making browsers themselves reasonably accessible.
The alternative seems to mean pushing users off bare browsers and forcing them to use the vast range of assistive technologies, extensions, etc that are out there. Which in turn actually means developers need to work out how to handle an ever-increasing range of users with tools they have a diminshing hope of even knowing, or simply ignore more of those users.
While the abstraction layer of ARIA seems like overhead, it also provides an important safety net for development IMHO.
cheers
Chaals