Re: Agenda: HTML 5 Canvas Accessibility Meeting February 22, 2010

Rich Schwerdtfeger
Distinguished Engineer, SWG Accessibility Architect/Strategist

James Craig <jcraig@apple.com> wrote on 02/22/2010 11:53:09 AM:

> James Craig <jcraig@apple.com>
> 02/22/2010 11:53 AM
>
> To
>
> Steven Faulkner <faulkner.steve@gmail.com>
>
> cc
>
> Richard Schwerdtfeger/Austin/IBM@IBMUS, David Bolter
> <david.bolter@gmail.com>, cooper@w3.org, janina@rednote.net, Charles
> McCathieNevile <chaals@opera.com>, cyns@exchange.microsoft.com,
> Frank Olivier <franko@microsoft.com>, "public-canvas-api@w3.org"
> <public-canvas-api@w3.org>, surkov.alexander@gmail.com
>
> Subject
>
> Re: Agenda: HTML 5 Canvas Accessibility Meeting February 22, 2010
>
> On Feb 20, 2010, at 12:20 AM, Steven Faulkner wrote:
>
> > how is having this accessible to AT and keyboard only users betterfor
them?
> > <canvas>
> > your browser does not support canvas get a better <a
> href="firefox.html">browser</a>.
> > </canvas>
>
> A spec will never stop authors from writing bad markup, but an
> author could just as likely include this:
>
>
> <canvas>
>    <img src="graph.png" alt="Graph demonstrating increasing rainfall
> over the past five years.">
> </canvas>
>
> And forcing AT to look for an @adom flag would mean that this real
> alternative text would be rendered completely inaccessible.
>
Yes, and when you test this with a screen reader it would fail which most
developers do.
>
> > What can be predicted (with some confidence I think) is that users
> will encounter this sort of subtree much more that they will
> encounter a subtree that is designed to take into account their needs.
>
> And so the proposal is to make all content (well-crafted or not)
> completely inaccessible by default, just in case it's not useful for
> the user? I don't follow that logic.
>

I think that is a gross assumption on your part. Assuming adom is set to
true fails for all cases you have today.
Furthermore, a test of this with an assistive technology would show that it
fails miserably.

So, what you are saying is do nothing and hope for the best. Right of the
bat your approach fails for ALL existing canvas
content today. For authors that wish to produce an accessible canvas we
have provide direction in the HTML 5 spec to do so (which your code snippet
would fail):

This is why I put the wording in the proposal that I did:

MUST synchronize the accessible sub-tree elements, semantics, and structure
with the canvas rendering.
MUST render and maintain visible focus of the canvas subtree element on the
rendered canvas
MUST render and maintain the keyboard caret insertion cursor of the canvas
subtree element on the rendered canvas
SHOULD ensure that the canvas rendering reflects the user settings for
font, color, and zoom

Part of accessibility test procedures that go with the new rule sets we are
putting together for the Accessibility Test Tool vendors requires a degree
of manual testing. Your approach also fails WCAG 2 compliance on multiple
levels. WCAG 2 Robust requires that the author convey semantically what the
author intended to be directly accessible.

In short, the adom approach is covered by WCAG 2 and new rule sets that are
being created today.