[webkit-dev] Considering a Touchhover

[Charles Pritchard]

I neglected to include the two relevant bug reports:

Fallback content in canvas element not focusable
https://bugs.webkit.org/show_bug.cgi?id=50126

VoiceOver does not work well with Canvas in mobile safari
https://bugs.webkit.org/show_bug.cgi?id=63463

-Charles

On 3/21/2011 12:06 PM, James Craig wrote:
> 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