W3C home > Mailing lists > Public > public-html-bugzilla@w3.org > December 2011

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

From: <bugzilla@jessica.w3.org>
Date: Tue, 13 Dec 2011 04:23:59 +0000
To: public-html-bugzilla@w3.org
Message-Id: <E1RaJuJ-00087z-8Q@jessica.w3.org>

--- Comment #31 from Charles Pritchard <chuck@jumis.com> 2011-12-13 04:23:56 UTC ---
(In reply to comment #30) 
>    http://wiki.whatwg.org/wiki/Canvas#Limitations_of_real-world_use_cases

The whatwg wiki to be restricted from accepting new users. Here is a summary
from Tab, based on the conversations he and I had on the public-canvas-api
list. He is simply summarizing, not advocating any position in this summary. He
is acting more as an editor in this case, trimming down the long discussions I
had with him -- the "I" in this writing is referring to me.

Platform accessibility APIs only need a fairly limited amount of
information to communicate with the user.  The information we can
currently expose with a combination of the subtree, drawFocusRing, and
scrollPathIntoView fill in *almost* all of that information.  The only
remaining hole is the location of "active" regions.

This can be somewhat obtained post-facto by focusing everything in the
subtree and seeing what geometry is exposed by drawFocusRing.  This
could, unfortunately, have other side effects (such as actually
drawing focus rings), and amounts to polling, with all the undesirable
details that entails, as the clickable regions may change over time.
Actively declaring the regions up-front produces a much better story
for accessibility and performance purposes.

As with drawFocusRing and scrollPathIntoView, we can attach useful
functionality to this so that authors will use it to help themselves,
and the a11y benefits just come along for the ride.  Specifically, if
you associate a clickable region of the canvas with an element in the
subtree via setClickableRegion(element), we can make clicks within
that region dispatch to the associated element instead of the canvas,
making it easier to listen for clicks on "objects" in the canvas.  I
believe that anything authors would want to use this functionality for
is a useful thing to expose to the AT API.

Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
Received on Tuesday, 13 December 2011 04:24:38 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:02:10 UTC