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

Re: Please vote on the canvas accessibility proposal

From: Richard Schwerdtfeger <schwer@us.ibm.com>
Date: Thu, 25 Feb 2010 09:40:33 -0600
To: Ian Hickson <ian@hixie.ch>
Cc: public-canvas-api@w3.org, "public-html-a11y@w3.org" <public-html-a11y@w3.org>, public-html-a11y-request@w3.org, Silvia Pfeiffer <silviapfeiffer1@gmail.com>
Message-ID: <OFB946A38A.FCD035FB-ON862576D5.00544CCA-862576D5.00561C54@us.ibm.com>

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

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

             Ian Hickson                                                   
             Sent by:                                                   To 
             public-html-a11y-         Silvia Pfeiffer                     
             request@w3.org            <silviapfeiffer1@gmail.com>         
             02/25/2010 03:58          "public-html-a11y@w3.org"           
             AM                        <public-html-a11y@w3.org>           
                                       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.   `._.-(,_..'--(,_..'`-.;.'

(image/gif attachment: graycol.gif)

(image/gif attachment: pic06671.gif)

(image/gif attachment: ecblank.gif)

Received on Thursday, 25 February 2010 15:41:15 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:05:09 UTC