[webkit-dev] Considering a Touchhover

[James Craig]

The canvas "sub-DOM" proposal should allow some of this, but AFAIK, it is not implemented in WebKit yet. I believe we were the first to propose it, though to date I think it is only implemented in IE9. I have not checked IE to verify support, but they have claimed support in IE9. Basically the ARIA-enhanced subtree is accessible to the keyboard and assistive technology, and the DOM structure mimics the UI visible in the canvas. It requires a focus model change to WebKit because the canvas subtree was not originally intended to be accessible in any modality.

http://lists.w3.org/Archives/Public/public-canvas-api/2009OctDec/0026.html

I'm not sure I agree with the need for a touchhover event, but I'd be interested to hear how you think it should work.

James


On Mar 11, 2011, at 3:30 PM, Chris Fleizach wrote:

> 
> There's no established API to handle this, but we are working on a W3C proposal 
> 
> http://lists.w3.org/Archives/Public/wai-xtech/2010Aug/att-0079/UserInterfaceIndependence.html
> 
> to address this.
> 
> In the meantime, VoiceOver on iOS will call .focus() every time it "hovers" on an item, so you can use that monitor where VO is at any moment.
> 
> If that doesn't work with <canvas> tags please file bugs at bugs.webkit.org and CC me
> 
> On Mar 11, 2011, at 9:43 AM, Charles Pritchard wrote:
> 
>> Recently, while working on code review / accessibility for a large canvas application, I found that the iOS VoiceOver AT
>> does not play well with the html canvas element. It can work, but it's not a natural transition from html to
>> canvas (with "buttons" in it). Using transparent [button] tags work, but it is rather awkward.
>> 
>> It occurred to me that, when VoiceOver is on, on these mobile devices, that a new "touch" type is active.
>> For the time being, I'm proposing calling it "touchhover".
>> 
>> Currently, VoiceOver AT captures touch events, waiting until the user has set virtual focus to an element,
>> then tapped twice, to set event focus on that element. It works quite well for html elements.
>> 
>> My thinking is that this state, where it's not passing touchstart/touchmove/touchend events, is
>> very much like the traditional "hover" events we've used with mice.
>> 
>> If touchhover events were passed through Mobile Safari, I'd be able to use hit detection on canvas
>> elements, and set the canvas element to the appropriate title matching whatever the user has focus upon.
>> 
>> Does this make sense? Should I provide more examples? The purpose here is to enable UI elements
>> in Canvas to work appropriately with touch-based AT, such as the iOS VoiceOver extension.
>> 
>> 
>> -Charles
>> 
>> 
>> _______________________________________________
>> webkit-dev mailing list
>> webkit-dev at lists.webkit.org
>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>