Re: hit testing and retained graphics

Richard's proposals have described the secondary purpose of setElementPath as marshaling pointer events directly to the subtree where they would then bubble up as normal. This is constant with keyboard events bubbling up from the subtree. It's also controversial, as the elements in the subtree would retain path information to be used by the UA in delegation of onmouse and onclick events. Vendors would likely re-use hit testing from svg code paths.

That seems to be the controversy anyway. I don't see any controversy in using setElementPath to send bounding information into the accessibility tree... That one is straightforward, though some vendor developers working in canvas/svg may be confused about it, as they are not familiar with IAccessible.

-Charles



On Jul 1, 2011, at 12:36 PM, "Tab Atkins Jr." <jackalmage@gmail.com> wrote:

> 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:52:45 UTC