W3C home > Mailing lists > Public > public-html-a11y@w3.org > February 2012

[public-html-a11y] <none>

From: Richard Schwerdtfeger <schwer@us.ibm.com>
Date: Tue, 7 Feb 2012 11:43:30 -0600
To: "Frank Olivier" <Frank.Olivier@microsoft.com>, public-canvas-api@w3.org, public-html-a11y@w3.org
Cc: Charles Pritchard <chuck@jumis.com>, "Cynthia Shelly" <cyns@microsoft.com>, faulkner.steve@gmail.com, dbolter@mozilla.com
Message-ID: <OFA4324C00.39862E0D-ON8625799D.005BB939-8625799D.00615E56@us.ibm.com>


Frank,

I am reviewing your proposal (http://www.w3.org/wiki/Canvas_hit_testing)
and I recommend you add the following methods or your version thereof:

- boolean clearElementPath(in Element element); Disassociates any path
associated with an element in the canvas DOM

The clearElementPath() method disassociates any path associated with an
element in the canvas DOM set using setElementPath().


When clearElementPath() is called, the path associated using setElementPath
is disassociated with the element in the canvas DOM.


User agents should use the information set by clearElementPath() to create
accessible user experiences. For example, a screen reader may read the
fallback element's details when the user indicates interest in that region
of the canvas.


The clearElementPath(element) method, when invoked, must run the following
steps:


1. If the element is not a descendant of the canvas element with whose
context the method is associated, then return false and abort these steps.


2. User agents must remove the path associated with the element using
setElementPath.


3. If supporting an accessibility API, user agents may replace the
associated best fit bounding rectangle in screen coordinates of the
associated accessible object with the best fit rectangle bounding rectangle
in screen coordinates for the canvas element.  The path should be subject
to the clipping region.


4. Return true.


- boolean removePathsFromElements(); Disassociates all paths associated
with elements in the canvas fallback DOM

The removePathsFromElements method disassociates paths associated with
element in the canvas fallback DOM set using setElementPath().


User agents should use the information set by removePathsFromElements to
create accessible user experiences. For example, a screen reader may read
the fallback element's details when the user indicates interest in that
region of the canvas.


The removePathsFromElements() method, when invoked, must run the following
steps:


1. If no descendants of the canvas element with whose context the method is
associated has an associated path set by setElementPath, then return false
and abort these steps.


2. For each descendant element of the canvas element call clearElementPath
(Element) where Element is the descendant Element


3. Return true.


- Note for the first two, and setElementPath, Ian may replace the screen
coordinate text with "optionally inform" the user or assistive technology
of the change in location. I believe this is a better approach as it allows
for some browsers to support built in AT, like ChromeVox. We would simply
modify the accessibility API mapping guide to do the mapping on specific
browsers. So, you might consider this. It is also consistent with his other
modifications for focus rings.


For example:


<change>
3. If supporting an accessibility API, user agents may replace the
associated best fit bounding rectangle in screen coordinates of the
associated accessible object with the best fit rectangle bounding rectangle
in screen coordinates for the canvas element.  The path should be subject
to the clipping region.
</change>


<to>
User agents may optionally inform a user or assistive technology of the new
location of the canvas DOM element.
</to>


The gory details we can place in the accessibility API mapping guide for
HTML 5. This also gives us time to refine the mapping independent of the
main spec. Also, I think it is important that browsers provide some bounds
for canvas DOM elements as having them invalid (as they are in IE now) is
problematic for ATs.


- Please reference the use cases provided here in the Rationale section. It
includes requirements from AISquared for location information.


 http://wiki.whatwg.org/wiki/Canvas#Limitations_of_real-world_use_cases


Ian asked that we place use cases here which we have done.


- Under Positive Effects





I would be explicit about AT benefits:


1. Allows a screen magnifier user to locate and zoom to any element
rendered on canvas
2. Allows a screen reader user with a Braille better fill a refreshable
Braille display by using the coordinates supplied to place rendered objects
on the same line facilitating a determination of what goes on line of
Braille text.
3. Allows assistive reading tools to speak the appropriate content when the
user points to items on canvas.








Rich


Rich Schwerdtfeger
Received on Tuesday, 7 February 2012 17:50:48 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 04:42:53 GMT