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

Re: Comments about the ACTION-165 draft

From: Laura Carlson <laura.lee.carlson@gmail.com>
Date: Fri, 18 Dec 2009 06:43:08 -0600
Message-ID: <1c8dbcaa0912180443n30ce2a1ag38cc9bcb7ad54128@mail.gmail.com>
To: Henri Sivonen <hsivonen@iki.fi>
Cc: "public-html@w3.org WG" <public-html@w3.org>, Richard Schwerdtfeger <schwer@us.ibm.com>, Steve Faulkner <sfaulkner@paciellogroup.com>, "Gregory J. Rosmaita" <oedipus@hicom.net>
Hi Henri

The details section of that wiki page [1] is taken from one of Rich's
early drafts.

It may or may not be the current thinking of the canvas sub group.

The proposal will no doubt evolve. The action is not due until 25 Feb 2010.

Best regards,

[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

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:15:55 UTC