- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Fri, 1 Jul 2011 12:36:57 -0700
- To: Charles Pritchard <chuck@jumis.com>
- Cc: Charles McCathieNevile <chaals@opera.com>, Matt May <mattmay@adobe.com>, Cameron McCormack <cam@mcc.id.au>, public-canvas-api@w3.org, public-html@w3.org, public-html-a11y@w3.org
On Fri, Jul 1, 2011 at 12:00 PM, Charles Pritchard <chuck@jumis.com> wrote: > On 7/1/2011 11:10 AM, Tab Atkins Jr. wrote: >> The only way to do good accessibility is to sneak it in so that the >> author accidentally makes things accessible while making it work well >> for themself or their majority userbase. It's almost impossible to do > > Tab, this is very much the reason why Richard has proposed that Canvas > handle > marshaling of pointer events into the subdom. We don't need event marshaling > to accomplish what we need to accomplish in populating the accessibility > tree. > > Richard asked me to go out and talk to canvas developers. I did. > They all want event marshaling. They do not have a particular attitude > about accessibility, but they all want to set a setElementPath(element) > method in canvas working with the subdom. Ooh, awesome. What were they actually trying to accomplish that would be made easier by something like setElementPath()? As far as I can tell, that function's sole purpose is to connect a region of the canvas to an element in the subtree for accessibility purposes. If I'm missing something, and it actually does something more generally useful for authors, I'm very interested in finding that out. ^_^ > Richard and I need to see that for HTML5, so that subdom elements > have sufficient accessibility metadata for ATs. > > How would you like me to mark that up, in the document I'm preparing? > Is it a "use case", or something else? Ian Hickson has called this > methodology a "stalking horse". > > Am I wrong in my conclusion here? As I understand it, setElementPath > precisely fits the criteria you're describing. > > And as far as things go, developers are all interested in having > setElementPath, drawFocusRing, and a subdom which responds to > pointer and keyboard events. Not because they're looking to > support particular ATs, but because those methods make things > easier on them, to get the results they want to see in their work. What things are made easier, and what results are they trying to achieve? ~TJ
Received on Friday, 1 July 2011 19:37:45 UTC