- From: Richard Schwerdtfeger <schwer@us.ibm.com>
- Date: Wed, 17 Feb 2010 16:59:43 -0600
- To: Ian Hickson <ian@hixie.ch>
- Cc: "public-canvas-api@w3.org" <public-canvas-api@w3.org>
- Message-ID: <OFEC2A1703.C23CC554-ON862576CD.007C6FAF-862576CD.007E5139@us.ibm.com>
Yes and no. First, we really know nothing about the fallback content. - As the canvas will still be rendered and the fallback will not be by default in <canvas> supporting browsers. - The fallback content could be as simple as what I had indicated. - We don't know that the fallback is even intended to be an accessible alternative. Now, if authors wants to, in their UI, they may allow the user to pick the fallback content as the alternative content they can as it it is an alternative view. It will then be up to an accessibility test tool to determine if the newly rendered fallback content is accessible and up to a procurement person, who knows accessibility, to assess whether the fallback content provides equivalent facilitation to what is provided in <canvas>. If it is not (the disabled user can't perform the same task) then the content would be deemed inaccessible by say U.S. 508. What we are trying to say with adom is simply that the <canvas> subtree (at the time it is set to true) is designed to be bound to the canvas UI rendering and to use it to support your accessibility infrastructure and be included in the keyboard navigation. The author is to have done the job of drawing visible focus on the canvas drawing area. What the group has asked is to provide the ability for the author to make <canvas> directly accessible as you would see it rendered on the screen. If that is not possible (author does not have time to do it, too technically challenging, etc.) the author can offer an option to show the fallback content, or something else entirely. Rich Schwerdtfeger Distinguished Engineer, SWG Accessibility Architect/Strategist Ian Hickson <ian@hixie.ch> To 02/17/2010 04:26 Richard PM Schwerdtfeger/Austin/IBM@IBMUS cc "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, Richard Schwerdtfeger wrote: > > Simply because the subtree may not accessibly map to the canvas > rendering. It could in fact be an entirely different application and > rendering designed to do the same thing when <canvas> is not supported. > There would be no correlation to the <canvas> rendering. > > You would not want to tab through the subtree and have not display the > rendered focus in the canvas. You would also not want an accessibility > test tool analyze the subtree for canvas if the UI and the subtree are > not related accessibly. > > So, the simple answer is to just tell the user agent the intent of the > subtree either at run time or statically which ever works for the > author. So in the case where the author has failed to provide an accessible subtree, but _has_ provided an alternative mode for people without <canvas>, you're saying it's better for accessibility for AT users to get just the canvas with the AT not providing anything than for them to get the canvas on the screen and the AT reading the fallback? -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/, U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Attachments
- image/gif attachment: graycol.gif
- image/gif attachment: pic30337.gif
- image/gif attachment: ecblank.gif
Received on Wednesday, 17 February 2010 23:00:43 UTC