Re: Comments about the ACTION-165 draft

Hi Henri

The details section of that wiki page [1] is taken from one of Rich's
early drafts.
http://lists.w3.org/Archives/Public/public-canvas-api/2009OctDec/0036.html

It may or may not be the current thinking of the canvas sub group.
http://lists.w3.org/Archives/Public/public-canvas-api/2009OctDec/0060.html

The proposal will no doubt evolve. The action is not due until 25 Feb 2010.
http://www.w3.org/html/wg/tracker/actions/165

Best regards,
Laura

[1] http://www.w3.org/WAI/PF/HTML/wiki/Canvas_Change_Proposal_Action_165

--
Laura L. Carlson

On 12/18/09, Henri Sivonen <hsivonen@iki.fi> wrote:
> 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/
>
>
>
>


-- 
Laura L. Carlson

Received on Friday, 18 December 2009 12:44:37 UTC