Re: HTML 5 canvas accessibility

Rich Schwerdtfeger
Distinguished Engineer, SWG Accessibility Architect/Strategist

Doug Schepers <schepers@w3.org> wrote on 08/14/2009 04:40:42 PM:

> Doug Schepers <schepers@w3.org>
> 08/14/2009 04:40 PM
>
> To
>
> Richard Schwerdtfeger/Austin/IBM@IBMUS
>
> cc
>
> David Singer <singer@apple.com>, Cynthia Shelly
> <cyns@exchange.microsoft.com>, Steven Faulkner
> <faulkner.steve@gmail.com>, David Bolter <david.bolter@gmail.com>,
> cooper@w3.org, Sam Ruby/Raleigh/IBM@IBMUS, janina@rednote.net, Sue E
> McNamara/Rochester/IBM@IBMUS
>
> Subject
>
> Re: HTML 5 canvas accessibility,
>
> Hi, Rich-
>
> Just a couple of high-level thoughts:
>
> 1) I don't believe that including a DOM (at least the W3C DOM) is a
> workable solution.  The whole reason to use Canvas vs. a retained-mode
> format like SVG is that maintaining a DOM is CPU- and memory-expensive,
> and slows down the browser.  Instead, maybe canvas should be treated as
> a typical GUI runtime.
>
Doug,

A W3C DOM is CPU intensive if you load all your content into it. I am not
suggesting that
is necessary as you will find out. All accessibility frameworks are
dependent on the ability
to have an object model to provides a hierarchy that provides context to a
user and which
can provide interfaces to an assistive technology. If you would like I am
happy to give a presentation
I give to IBM engineers on WAI-ARIA and accessibility to help explain this.

All GUIs frameworks today have an object model hierarchy coupled with a
transport layer to communicate to assistive technologies - D-Bus, Corba,
COM, etc. I could tell you what Apple is but I am just now learning about
it. My reason for choosing the DOM is it makes no sense to create an
entirely new
object model that we have to implement and force people to learn.

In the case of Bespin you may, in fact, on only need a small set of DOM
objects - one of which exposes
an accessibility API interface for rich text to represent the editor.

I was part of the team that created the first GUI screen reader for the
team. If you are suggesting that the industry go back to the screen
scraping as we did in the early to mid-90s that will not happen. That is a
loss of access. Both Flash and Silverlight are taking an approach that
binds APIs to objects with visual rendering. There is no reason this cannot
be done with canvas. Also, new accessibility legislation is requiring
programmatic interoperability vs. reverse engineering through screen
scraping.

Finally, there are applications like a first person shooter whose
developers don't feel a business need to make it accessible and
consequently don't need to add the DOM model and they will not feel any
performance hits.

In short, I think we can make this work. I also think it is important to
allow for canvas to provide equivalent alternatives for content as opposed
to making something directly accessible. For example, 2-D charts (Pie, Bar,
etc.) could be replaced by an HTML table with headers. A google map could
be replaced with driving directions in basic HTML. If a 2D chart has
dynamically changing data it could be replaced with an HTML table marked as
a live region or even a grid.


> 2) I am glad to be included in this list of folks, but just as I feared,
> the lack of a clear mandate for a dedicated list means that people are
> going underground, into totally unarchived conversations (this is the
> second such private email CC list I've been included on).  The
> insistence on working in the HTML list has had exactly the opposite
> effect as is intended.
>
> May I suggest that we instead use the list I set up for Canvas
> discussions a while back?
>    public-canvas-api@w3.org
>    http://lists.w3.org/Archives/Public/public-canvas-api/
>
> This is a public list, but is not widely trafficked: there have only
> been a handful of messages, and only 35 subscribers.

Sure. that is fine with me. AT the moment I am just trying to arrange a
meeting. If everyone else is supportive of using this list I am happy with
that.


>
> Regards-
> -Doug Schepers
> W3C Team Contact, SVG and WebApps WGs
>
> Richard Schwerdtfeger wrote (on 8/14/09 5:12 PM):
> > Per the HTML working group discussion Thursday, I would like to start
> > having discussions about canvas accessibility. For those of us who have
> > worked on making rich graphical technologies accessible, the canvas
> > solution is not new. It requires an understanding of how people use
> > primitive drawing calls, etc. to create rich GUI applications but more
> > importantly doing so for applications that are important to people with
> > disabilities. I believe the combination of:
> >
> >     * A DOM
> >     * WAI-ARIA
> >     * A limited set of accessibility API that can be supported by a
> >       script author that can be mapped to accessibility API on each
> >       browser for their supported platform
> >     * The use of aria-activedescendant to manage focus for the DOM in
> >
> >
> > I started covering my thoughts on the Wiki here:
> >
> > http://esw.w3.org/topic/HTML/AddedElementCanvas?
> action=show#head-7417bcc86e63e6a528872dd1ab93576887e6208d
> >
> > I would like you or members of your organization to attend who are
> > familiar with:
> >
> >     * Platform accessibility API support of web content in your browser
> >     * Strong understanding of accessibility infrastructure as supported
> >       by your browser
> >     * An understanding of assistive technologies
> >     * Familiarity with the HTML 5 specification
> >     * Familiarity with canvas applications
> >
> >
> > I would like to know your availability or the availability of the
> > appropriate people in your organizations. David, in addition to your
> > accessibility API mapping support on Windows and Linux in Firefox I
> > would like to know if you could either in this meeting or a follow-on
> > who has worked on Bespin at Mozilla.
> >
> > Mike, Sam, Janina, I am copying you so that you aware we are proceeding
> > on this effort to address canvas accessibility.
> >
> > Sue, would you please work with David, Cynthia, Steve, Doug and David
to
> > coordinate a time for the call. We will have W3C supply the irc channel
> > and the call-in numbers. Mike Cooper has agreed to help with that.
> >
> >
> > Thank you,
> > Rich
> >
> >
> >
> > Rich Schwerdtfeger
> > Distinguished Engineer, SWG Accessibility Architect/Strategist