Comments about the ACTION-165 draft

Comments about http://www.w3.org/WAI/PF/HTML/wiki/Canvas_Change_Proposal_Action_165 :
> 	• Modify the canvas element to support aria-activedescendant where the id refers to a valid id in a shadow DOM.

Why is aria-activedescendant necessary compared to requiring that focus must traverse into the <canvas> subtree as if <canvas> weren't a replaced element?

As an editorial matter, please refer to the subtree rooted at <canvas> using a term other than "shadow DOM", because "shadow DOM" already means something different (in XBL).

> 	• The canvas element shall support zero or more child access elements representative of alternative views.

Why does <canvas> need multiple alternative representations when the rest of HTML doesn't have such alternative views on the markup level (and, in theory at least, has them on the CSS level)?

> 	• The mode content attribute values for access would be:
> 		• default - Representing the shadow DOM for the complex visual rendering of canvas
> 		• textual - Here we could place a long description or an alternative accessible UI renderable using HTML 5 standard markup, including ARIA.
> 		• auditory - An audio alternative. Some users may prefer this.
> 		• visual - This is really an alternative for audio but it would address things like sign language

Is there a reason to expect content providers to develop auditory and sign language alternatives instead of developing a textual alternative and leaving it to AT to generate auditory and sign language representations via synthesis?

> The e-book may be rendered with a plug-in. We can choose a subset of these if necessary. At this point this is for discussion purposes.

How is an e-book different from general document-oriented HTML content? Why would we (as a WG developing HTML) want to rely on a plug-in-based e-book solution when we are developing a non-plugin format that among other things can represent book content?

>  The shadow DOM is also optional.

Does this mean accessibility support is optional?

> 	• The canvas tag shall include a script method to set the bounding rectangle for a given valid id in the shadow DOM. This would allow the browser to provide the bounding rectangle for the id in the shadow DOM when it receives focus. The rectangle should be relative to the location of the canvas element and would be converted to screen coordinates in the accessibility API and would allow the canvas to move without changing the location of the shadow DOM element. This will allow screen magnifiers to determine the visible focus.

Please clarify that the script driving <canvas> painting is responsible for drawing the focus outline.

> (Ideally it would be nice to also do this via XPath statements vs. id)

But if the subtree of the <canvas> element is not rendered on the visual medium, it presumably wouldn't have a CSS box tree constructed for it and, thus, the DOM nodes wouldn't correspond to any particular coordinates in the coordinate space of the <canvas> element (or the CSS formatter canvas).

-- 
Henri Sivonen
hsivonen@iki.fi
http://hsivonen.iki.fi/

Received on Friday, 18 December 2009 12:07:45 UTC