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 >> [email protected] >> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev > _______________________________________________ webkit-dev mailing list [email protected] http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
