- 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