- From: Richard Schwerdtfeger <schwer@us.ibm.com>
- Date: Thu, 4 Feb 2010 10:57:49 -0700
- To: Maciej Stachowiak <mjs@apple.com>
- Cc: Anne van Kesteren <annevk@opera.com>, Ian Hickson <ian@hixie.ch>, Jonas Sicking <jonas@sicking.cc>, "public-html@w3.org" <public-html@w3.org>
- Message-ID: <OF3F9527CC.2EE42C84-ON862576C0.00621CF7-862576C0.0062AD0C@us.ibm.com>
Correct. And that is why we want to introduce the ability to select alternative UIs through style sheets to different users. However, many users want to be able to use the canvas implementation directly, where possible so that they may operate side by side their no-impaired user. This is what <accessible> is for. Authors have the choice of having a UI that renders fallback content in the place of <accessible>. That will require the fallback content to ensure a visual rendering of the content using standard HTML and CSS but that is no different than how you would expect fallback content to perform - although the fallback content may not represent the same UI and content structure that is reflected in canvas, unlike <accessible>, as its purpose is to simply to provide equivalent capability just as is intended for a browser which does not support canvas. Rich Rich Schwerdtfeger Distinguished Engineer, SWG Accessibility Architect/Strategist Maciej Stachowiak <mjs@apple.com> To 02/04/2010 11:03 Richard AM Schwerdtfeger/Austin/IBM@IBMUS cc Anne van Kesteren <annevk@opera.com>, Ian Hickson <ian@hixie.ch>, Jonas Sicking <jonas@sicking.cc>, "public-html@w3.org" <public-html@w3.org> Subject Re: Integration of HTM On Feb 4, 2010, at 8:50 AM, Richard Schwerdtfeger wrote: Anne, Seeing as you don't think people to need to hire consultants, I need you to make this directly accessible to a person with: - a cognitive impairment - a person with dyslexia - a user with RP - a mobility impaired user http://www.nysubway.com/map/ Please enlighten us. The map at that link does not use <canvas>. There are definitely challenges of making interactive map content accessible to a wide range of audiences. But this example shows that the mechanisms we invent for this should *not* be specific to <canvas>. They need to be approaches that work for all HTML. Regards, Maciej Rich Rich Schwerdtfeger Distinguished Engineer, SWG Accessibility Architect/Strategist <graycol.gif>"Anne van Kesteren" ---02/04/2010 03:35:51 AM---On Thu, 04 Feb 2010 02:49:56 +0100, Ian Hickson <ian@hixie.ch> wrote: "Anne van Kesteren " < <ecblank.gif> annevk@o To pera.com <ecblank.gif> > "Ian Hickson" <?ian@hixie.ch >, Richard Schwerdtfeger/Austin/IBM@IBM 02/04/20 US 10 03:35 <ecblank.gif> AM cc <ecblank.gif> "Jonas Sicking" <? jonas@sicking.cc>, "?, public-html@w3.org" < public-html@w3.org> <ecblank.gif> Subject <ecblank.gif> Re: Integration of HTM <ecblank.gif> <ecblank.gif> On Thu, 04 Feb 2010 02:49:56 +0100, Ian Hickson <ian@hixie.ch> wrote: > On Wed, 3 Feb 2010, Richard Schwerdtfeger wrote: >> We are calling it the accessible DOM for canvas. It starts and ends with >> the <accessible></accessible> tags and it is not visually rendered. > > I really don't think this is a good idea, as explained in the following > e-mails: > > http://lists.w3.org/Archives/Public/public-html/2010Jan/0488.html > http://lists.w3.org/Archives/Public/public-html/2010Jan/1151.html > http://lists.w3.org/Archives/Public/public-html/2010Jan/0931.html > > I do not think it is necessary to have multiple inline alternatives for > <canvas>, nor do I think it is necessary for widgets that represent the > graphically-rendered widgets on a <canvas> to be marked up separately > from an inline alternative representation. The existing features of HTML > already allow us to have multiple alternatives. Adding more features for > this is IMHO a mistake. I wholeheartedly agree. Making accessibility into something that only consultants can do correctly would be a huge step backwards. -- Anne van Kesteren http://annevankesteren.nl/. (See attached file: pic13043.gif)
Attachments
- image/gif attachment: graycol.gif
- image/gif attachment: pic05750.gif
- image/gif attachment: ecblank.gif
- image/gif attachment: pic13043.gif
Received on Thursday, 4 February 2010 17:58:40 UTC