- From: Steven Faulkner <faulkner.steve@gmail.com>
- Date: Thu, 25 Feb 2010 15:45:32 +0000
- To: Richard Schwerdtfeger <schwer@us.ibm.com>
- Cc: public-canvas-api@w3.org, "public-html-a11y@w3.org" <public-html-a11y@w3.org>
- Message-ID: <55687cf81002250745y2d97a0a1k25bfa7ffebca0370@mail.gmail.com>
+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
Attachments
- image/gif attachment: ecblank.gif
- image/gif attachment: graycol.gif
Received on Thursday, 25 February 2010 15:46:25 UTC