As we all know, Accessibility should be no add-on: it’s an assumed.

Building accessibility into the default path that developers would use (e.g. for interactivity) always seems to be the best approach, so having something called ‘accessible DOM’ rings alarm bells..

Take any Flash site where accessibility wasn’t a prime concern and check the tab-order of elements. It is basically random, as people don’t specify it.

Could the structure aspect needed be used for other things as well? Things that people attend to more, e.g. SEO.”

the canvas API provides no means to add focusable content or add semantics, it is only a drawing API. everything must be done using scripting. allowing elements in the canvas subtree to be focusable provides a method for developers to add interaction using html elements which provide the focus, name, role,state and value information to accessibility APIs that would otherwise have to be totally scripted ie not possible, so it will be a method for developers to add interaction for all users, not just for accessibility. Allowing image maps to be defined for canvas also does this, but it does not provide the same scope of interaction. i envisage that for most purposes defining an image map will suffice, but for those cases it does not, adding elements to the subtree will provide that extra richness. the mix of image map and subtree are the closest we can get, considering the limitations imposed by the canvas API.

Perhaps because invisible aspects like this (virtually) never get added.

Take any Flash site where accessibility wasn’t a prime concern and check the tab-order of elements. It is basically random, as people don’t specify it.

Could the structure aspect needed be used for other things as well? Things that people attend to more, e.g. SEO.