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

Re: Please vote on the canvas accessibility proposal

From: Steven Faulkner <faulkner.steve@gmail.com>
Date: Thu, 25 Feb 2010 15:45:32 +0000
Message-ID: <55687cf81002250745y2d97a0a1k25bfa7ffebca0370@mail.gmail.com>
To: Richard Schwerdtfeger <schwer@us.ibm.com>
Cc: public-canvas-api@w3.org, "public-html-a11y@w3.org" <public-html-a11y@w3.org>
+1 Rich!

On 25 February 2010 15:40, Richard Schwerdtfeger <schwer@us.ibm.com> wrote:

>  So, perhaps what would be easier for all of you is to simply have an
> attribute that says include the subtree in the navigable document structure
> when canvas is rendered? This is not the case now. This way you can't twist
> the definition of adom around to say that it is a compliance statement.
> After this we provide direction on how ensure the subtree supports
> accessibility.
>
> Right now HTML 5 has a whopper hole in it in that you can't use what is in
> the subtree to navigate the canvas rendering.
>
> something like navigatesubtree. I would not call it fallback because it may
> not me.
>
>
>
>
>
>
> Rich Schwerdtfeger
> Distinguished Engineer, SWG Accessibility Architect/Strategist
>
> [image: Inactive hide details for Ian Hickson ---02/25/2010 03:59:30
> AM---On Thu, 25 Feb 2010, Silvia Pfeiffer wrote:]Ian Hickson ---02/25/2010
> 03:59:30 AM---On Thu, 25 Feb 2010, Silvia Pfeiffer wrote:
>
>
>      *Ian Hickson <ian@hixie.ch>*
>             Sent by: public-html-a11y-request@w3.org
>
>             02/25/2010 03:58 AM
>
>
> To
>
> Silvia Pfeiffer <silviapfeiffer1@gmail.com>
>
> cc
>
> public-canvas-api@w3.org, "public-html-a11y@w3.org" <
> public-html-a11y@w3.org>
>
> Subject
>
> Re: Please vote on the canvas accessibility proposal
>
>  On Thu, 25 Feb 2010, Silvia Pfeiffer wrote:
> >
> > So, are we also saying that fallback inside the <canvas> should always
> > function as accessibility markup? If that is the case, then it means
> > that as soon as there is markup inside the <canvas>, we have support for
> > accessibility. End of story. don't read any further. :-)
>
> That's more or less what I'm saying, yes, though more specifically, when
> there is content in the DOM inside <canvas>, rather than markup on the
> wire. What's important for ATs is what the DOM contains, and that can be
> different from what's on the wire -- a hopefully common case in the future
> will be for the page to have markup with legacy fallback, then the script
> detects <canvas> support and replaces it with focusable/accessible
> content. (This isn't done today since no browser actually supports this.)
>
> Hence why adom="" is redundant -- the element's contents always fall into
> one of these buckets, all of which should be read to the user by ATs:
>
> - content is empty (reading has no effect)
> - content is accessible augmentation of <canvas>
> - content is the only accessible alternative to the <canvas>
> - there is no accessible alternative and the content says so
>
> --
> Ian Hickson               U+1047E                )\._.,--....,'``.    fL
> http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
> Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
>
>
>


-- 
with regards

Steve Faulkner
Technical Director - TPG Europe
Director - Web Accessibility Tools Consortium

www.paciellogroup.com | www.wat-c.org
Web Accessibility Toolbar -
http://www.paciellogroup.com/resources/wat-ie-about.html


ecblank.gif
(image/gif attachment: ecblank.gif)

graycol.gif
(image/gif attachment: graycol.gif)

Received on Thursday, 25 February 2010 15:46:26 GMT

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