[webkit-dev] Considering a Touchhover

[Chris Fleizach]

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