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

Rich Schwerdtfeger
Distinguished Engineer, SWG Accessibility Architect/Strategist

public-canvas-api-request@w3.org wrote on 02/21/2010 04:37:47 PM:

> Ian Hickson <ian@hixie.ch>
> Sent by: public-canvas-api-request@w3.org
>
> 02/21/2010 04:37 PM
>
> To
>
> Steven Faulkner <faulkner.steve@gmail.com>
>
> cc
>
> "public-canvas-api@w3.org" <public-canvas-api@w3.org>:
>
> Subject
>
> Re: Agenda: HTML 5 Canvas Accessibility Meeting February 22, 2010
>
> On Sun, 21 Feb 2010, Steven Faulkner wrote:
> > >
> > >This is non-conforming anyway.
> >
> > This statement is effectively meaningless as it has not stopped and
will
> > not stop people including exactly this sort of thing within canvas.
>
> If we're talking about authors who write non-conforming content, then we
> definitely want to make things as trivial as possible -- if they're
> sometimes ignoring the requirement to add accessible alternatives, then
> they will also sometimes ignore the requirement to put adom=""
> appropriately, and so forth.
>
If we want to address trivial then we need to target test tools and ATs.

What happens today is the author uses commercial or free open source
accessibility test tools to test their web application and they use an
assistive technology to make sure that it works. This is typically done
with a screen reader.

<canvas> is inherently inaccessible, so ...

If you are a test tool and you run into the <canvas> element you need to
know what to test to see if it is accessible.

If the author replaces canvas with alternative accessible content it will
simply test the content for accessibility. Also, the content will be mapped
to the accessibility API for testing with a screen reader. If either fails
the author knows there is a problem. This scenario requires no change to
the HTML spec.

If you want to make <canvas> directly accessible (use it as is) then the
test tool needs to know what content is used to make it accessible and it
needs to know where that content is to execute the test. When it comes to
direct accessibility adom indicates that the subtree is what should be used
as the accessibility mapping for <canvas>. It also tells the browser to
process the subtree as the HTML accessibility mapping. If the author fails
the accessibility test, which the author will if we don't tell the test
tool what the content is to be tested for the directly accessible canvas
they know there is a problem. IF the screen reader does not read what is on
the canvas correctly they also know there is a problem. adom will tell the
AT and the browser what content to map to the accessibility API for a
directly accessible canvas. It really can't be any more trivial than that.

Without the adom approach we have no way of providing a directly accessible
solution for canvas that is testable for compliance. If the author does not
set adom to true and does not replace <canvas> with alternative content
HTML 5 will fail accessibility compliance. If the author sets it and the
test tool tests the subtree and it does not meet compliance criteria it
fails. If it does not work with the AT it fails.

Not all authors will want to replace the content entirely if it is at all
possible to make it directly accessible. Microsoft has asked that we
provide a means to make the rendered canvas directly accessible.

Rich



> --
> Ian Hickson               U+1047E                )\._.,--....,'``.    fL
> http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
> Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
>