- From: Richard Schwerdtfeger <schwer@us.ibm.com>
- Date: Wed, 17 Feb 2010 15:50:21 -0600
- To: Ian Hickson <ian@hixie.ch>
- Cc: Steven Faulkner <faulkner.steve@gmail.com>, "public-canvas-api@w3.org" <public-canvas-api@w3.org>, public-canvas-api-request@w3.org
- Message-ID: <OFA1779F59.6CEB5EC1-ON862576CD.007688D4-862576CD.0077F758@us.ibm.com>
Rich Schwerdtfeger Distinguished Engineer, SWG Accessibility Architect/Strategist public-canvas-api-request@w3.org wrote on 02/17/2010 03:03:01 PM: > Ian Hickson <ian@hixie.ch> > Sent by: public-canvas-api-request@w3.org > > 02/17/2010 03:03 PM > > To > > Steven Faulkner <faulkner.steve@gmail.com> > > cc > > Richard Schwerdtfeger/Austin/IBM@IBMUS, "public-canvas-api@w3.org" > <public-canvas-api@w3.org> > > Subject > > Re: Updated proposal round two (based on feedback from Monday's meeting) > > On Wed, 17 Feb 2010, Steven Faulkner wrote: > > > > > >That makes sense, except I don't understand why we would ever want to > > >turn that behaviour _off_. > > > > if there is focusable content in the canvas sub tree that is fallback, > > why would you want it to be tabbable when the canvas is rendered? > > The same reason as when it's an "accessible DOM" -- to expose it to AT > users. > > (If the author doesn't want this behaviour, it's trivial to empty the > <canvas> of the fallback DOM from script after detecting canvas support.) > We don't have an issue with being able to reload the subtree. The issue is knowing if the subtree that is currently loaded maps to the <canvas> rendering. For example, if it is not you definitely would not want to use the subtree in the keyboard navigation order as you would never see visual rendering of focus. In fact the subtree could have the following HTML content: "canvas not supported - go get a <a ref="http://www.firefox.com">better browser.</a>" It is accessible content but does not make the <canvas> rendering accessible. Consequently, if this would not be something we test for accessibility on <canvas> supporting browsers as it would be pointless to test. This is why we need the adom attribute - or if you have a better name that is fine. Raman mentioned the name and we thought it was short enough. We absolutely agree that the author can load content in the subtree based on the user agent support. So, there is no need for an accessible dom element in the subtree, just an attribute directive to tell a test tool and user agent what to do with what is there. > -- > Ian Hickson U+1047E )\._.,--....,'``. fL > http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. > Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' >
Received on Wednesday, 17 February 2010 21:51:27 UTC