- 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 UTC