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