[Bug 13176] The bounds of canvas fallback content, as rendered on the canvas, are not provided by the user agent to an assistive technology.

http://www.w3.org/Bugs/Public/show_bug.cgi?id=13176

--- Comment #17 from Charles Pritchard <chuck@jumis.com> 2011-09-22 16:29:17 UTC ---
(In reply to comment #15)
> Zooming is handled already by the focus ring APIs.

Zooming is -partially- handled by the focus ring APIs. It's counter to WCAG to
require that an AT focus on an element prior to the user confirming their
intent to activate that focus. While authors could plausibly loop through every
interactive element, to share that information, such as solution is rather
inefficient and also seems counter-indicative of current practices. Generally,
when an element loses focus from drawFocusRing, I'd think that the
accessibility tree would also remove its "focus" dimensions.

Let me know if that's unclear.

> In general, however, using <canvas> for something that can be sanely interacted
> with in non-visual mediums is completely counter to the point of <canvas>. If
> your content is media-independent, then use HTML, that's what it's for.

Begging your re-evaluation here: the purpose is for canvas to be sanely
interacted with as a spatial medium. "Non-visual" is a much more broad term.

Canvas is very much a spatial language. Yes, it has paint servers. But most of
the data passed around is data about spatial coordinates. These bug reports
relate current defects on various ATs relating to spatial navigation. I do not
think it's practical to tell AT vendors that they are "wrong" in their
implementations. All accessibility trees share this spatial information as part
of their data set.

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

Received on Thursday, 22 September 2011 16:29:19 UTC