Re: Please vote on the canvas accessibility proposal

Rich Schwerdtfeger
Distinguished Engineer, SWG Accessibility Architect/Strategist

public-html-a11y-request@w3.org wrote on 02/24/2010 09:57:25 AM:

> "Charles McCathieNevile" <chaals@opera.com>
> Sent by: public-html-a11y-request@w3.org
>
> 02/24/2010 09:57 AM
>
> To
>
> Richard Schwerdtfeger/Austin/IBM@IBMUS>
>
> cc
>
> Andi Snow-Weaver/Austin/IBM@IBMUS, public-html-a11y@w3.org:
>
> Subject
>
> Re: Please vote on the canvas accessibility proposal
>
> On Wed, 24 Feb 2010 15:53:29 +0100, Richard Schwerdtfeger
> <schwer@us.ibm.com> wrote:
>
>
> >> Silvia Pfeiffer <silviapfeiffer1@gmail.com>
> ...
> >> Assuming we have a very clever AT that interprets a canvas, could it
> >> make it accessible without any further (or only little extra) hints?
> >>
> >> Meaning: is the ability of being accessible really a function of the
> >> author? Or rather a function of the actual markup of the canvas
> >> combined with the capabilities of my AT? If it is the latter (and
> >> that's my understanding), then marking the canvas with an attribute
> >> that states that the canvas is accessible is not useful: only if my AT
> >> is capable of making it accessible will it really be accessible.
> >>
> > Silvia, the problems are that:
> >
> > - A test tool needs to assess if canvas is accessible. As is it is not
> > today.
>
> But how does adom provide that? It may be that a canvas is accessible by

> having an image map. It may (in the trivial case like hixie's little
> picture) be possible to make it accessible without even having a map. But

> having an adom only means "the author made some claim that this *might*
be
> accessible".
>
I think I agreed with Hixie and I showed him how.

adom is saying that this is the accessibility subtree to use. It makes no
statement that it is accessible any more than any other accessibility
implementation. I think I have said this in at least 10 emails and there is
no statement regarding that in the proposed change request. It is saying
that this is the accessibility subtree that I (the author) used to make
canvas accessible when it is set. With <canvas> is actually rendered today,
as is, there is no information. It provides absolutely zero accessibility
information.

Nobody, in content, today can state that what they have is accessible. We
don't provide compliance claims. It is the task of testers and test tools
to assess compliance.


> Having seen lots of pages get a DOCTYPE because some testing tools simply

> checked for that and claimed that the page passed the validity
requirement
> of WCAG 1, and seen lots of rubbish alt text for the same reason, I don't

> think that we score any wins by going down this path. If you want to
claim
> your content is accessible, why not add a bit of RDFa that explicitly
says
> why?
>
Please show me where in the change request that it says adom is a
compliance statement.

> > - A test tool needs to know what content to assess if it is to be made
> > directly accessible.
>
> The script that runs the canvas - what it paints and how it informs the
> user, and what input actions it accepts, and what they do.
>
Yes. and the piece of content needs be identified to run the test on.
Currently, <canvas> does not provide this. Now, in Ian's basic example he
can state that <canvas> is acting as an image (<canvas width="blah"
height="blah blah" role="img title="chart" aria-describedby="foo">). The
test tool says, OK. I can handle that. The subtree is irrelevant and the
fact that the author drew it using javascript is irrelevant.

> > - A browser needs to map an accessibility implementation to the
> > accessibility API to work.
>
> Sure, but I believe that adom is unnecessary for this purpose.
>
It is in some cases - yes. The change request states that the subtree is
designed to do the job.

> > - We have been asked to try to make <canvas> directly accessible where
> > possible without having to use alternative renderings as a blind or
> > mobility impaired user may want to sit side by side each other to use
the
> > same visual application.
>
> Yes, this is definitely a goal.
>
ok>

> > - With HTML 5 we are STUCK with having to deal with fallback content
> > (content that runs if you don't support all the HTML 5 features). This
> > content MAY have no correlation to what is being rendered even though
it
> > may be accessible. Try to imagine navigating the Bespin editor and the
> > fallback was a plug-in for emacs or some other editor where where you
> > have different toolbars and a different text editor and the keyboard
> > navigation did not line up. As a sighted user I would be screaming. In
> > this case you would need to render the alternative content entirely.
>
> Sure, but there are other ways around this problem. Using a completely
> invisible map, with a structure described in aria, means you don't see it

> if you don't render the canvas. Using a map containing block content
means
> you can re-use the relevant pieces.
>
Yep. and how do you know that "map" belongs to <canvas>? By default
<canvas> can be anything. I do agree that an image map can be very useful
but I would like to make use of something Ian described a while back and
that would be to use as much of HTML to make <canvas> as accessible as
possible.

Another way to do this would be to bind <canvas> to a another part of the
markup and give adom and id instead of a boolean and I would be supportive
of that if that is less confusing.

> So the use case for adom seems to boil down to a test of whether the
> canvas or its fallback content is rendered, in order to provide different

> user interaction, and the attribute seems instead to force an author to
> provide either accessibility or a fallback - which doesn't strike me as a

> sensible dichotomy to force.
>
> ...
> > adom basically says, as in the proposal, that if it is set to use the
> > <canvas> subtree (between the start and end canvas tags) as the
> > accessible
> > representation of what is being drawn on canvas. When it is set to true
a
> > test tool can analyze the subtree of canvas for accessibility and the
> > browser can include the subtree in the navigation order and map it to
the
> > accessibility API. adom can be computed by web applications simply by
> > assessing if the browser supports canvas and if it can create a direct
> > mapping in the subtree to represent canvas. This is EXTREMELY
important.
>
> But using an image map allows for this, and *also* allows for the
controls
> to be outside the canvas, enabling a cascade of fallbacks to use the same

> controls if you really want to, or for them to be hidden inside the
canvas
> yet navigable and interactive. All without writing a line of new code or

> teaching anyone anything new, which is a bonus.
>
> > So, this is why adom is so important. Without some indication to the
> > browser or a test tool of what is the accessible representation we are
> > casters up. adom is NOT an accessibility compliance statement.
>
> No. But a tool can check aria attributes on the canvas, and usemap. That

> shows something was done. More than that and you have to start analysing

> codepaths - which is possible (in the real world if not in the
theoretical
> general case) to see whether there are corresponding ways to initiate
them
> without a mouse, and to see if there is some feedback to the user that
> doesn't rely on (but mirrors meaningfully in some way) the painting of
the
> canvas itself.
>
So, why not make adom be an id so that it points to content outside the
sub-tree? Then we get out of this true/false confusion around compliance.

> cheers
>
> Chaals
>
> --
> Charles McCathieNevile  Opera Software, Standards Group
>      je parle français -- hablo español -- jeg lærer norsk
> http://my.opera.com/chaals       Try Opera: http://www.opera.com
>