W3C home > Mailing lists > Public > public-canvas-api@w3.org > January to March 2010

Re: Updated proposal round two (based on feedback from Monday's meeting)

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

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                                                   
             02/17/2010 04:26          Richard                             
             PM                        Schwerdtfeger/Austin/IBM@IBMUS      
                                       Re: Updated proposal round two      
                                       (based on feedback from Monday's    

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.   `._.-(,_..'--(,_..'`-.;.'

(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

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:31:49 UTC