[webkit-dev] Considering a Touchhover
jcraig at apple.com
Mon Mar 21 12:06:16 PDT 2011
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.
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.
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
> 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.
>> webkit-dev mailing list
>> webkit-dev at lists.webkit.org
More information about the webkit-dev