Re: Helping Canvas Tag Be Accessible

Rich Schwerdtfeger
Distinguished Engineer, SWG Accessibility Architect/Strategist

"Anne van Kesteren" <annevk@opera.com> wrote on 07/30/2009 12:05:19 PM:

> "Anne van Kesteren" <annevk@opera.com>
> 07/30/2009 12:05 PM
>
> To
>
> Richard Schwerdtfeger/Austin/IBM@IBMUS
>
> cc
>
> "Steven Faulkner" <faulkner.steve@gmail.com>, "HTML WG" <public-
> html@w3.org>, "W3C WAI-XTECH" <wai-xtech@w3.org>
>
> Subject
>
> Re: Helping Canvas Tag Be Accessible
>
> On Thu, 30 Jul 2009 18:11:25 +0200, Richard Schwerdtfeger
> <schwer@us.ibm.com> wrote:
> > Actually, we provide the ARIA role="presentation" on a table used for
> > layout and you are done. It is actually quite trivial. There is no need

> > in most cases to provide an elaborate style sheet unless there is some

> > reason the author can't use tables to meet their need.
>
> I'm arguing not abusing tables has become simpler, you're saying the
> opposite. Interesting. I don't think encouraging <table
> role=presentation> is the right idea though. We should encourage
> people to use CSS for layout. (And yes, it would be nice if the CSS
> WG was quicker with defining flex/grid layouts.)
>
Anne, either way works for me. What I am dealing with is IBM and many of
its customers have used tables for layout extensively. For this it is much
easier to use role="presentation." Whichever works for the developer is
fine with me.

>
> > Note: just be cause you provide the API does not mean that the author
> > needs to implement them in all cases. Again, all we are doing is
providing
> > tools to the author.
>
> If you're talking about the supposed accessibility API for <canvas>
> here the case where the author does not use it would be a loss for
> accessibility. I'm saying that might be the majority case and that
> it might therefore be better to provide people with tools at the
> right level of abstraction. Using CSS instead of presentational
> markup was just an example.
>
> But before we start drafting an accessibility API for <canvas> I
> think we ought to study use cases a bit more and figure out what
> authors actually want. E.g. authors of advanced Web applications
> want a generic programmable low-level accessibility API rather than
> one that is DOM-based (WAI-ARIA) or built on top of <canvas>:
>
>   http://rossboucher.com/2009/03/01/limitations-of-the-wai-aria/
>
Yes, the DOM is an ARIA limtation but also a benefit. Making use of the DOM
structure provides
context to objects. It is also representative of most of the applications
that are written today which is
an oversight by this article. Making use of this fact actually reduces the
work that the author is required to do. Consequently,
there I have yet to hear a problem with developers implementing ARIA. It is
a natural progression.

That said we need some way of providing contextual information to ATs and
am open to looking at solutions for this
in the case of canvas.

This article, like many I see offers criticism but now solution.

> That makes sense to me, although from what the examples he cited
> only Bespin is hard to make accessible and it is completely unclear
> whether applications such as Bespin need to use <canvas> in a few years.
>
> My main point is that I think we're way too quick to argue that
> "<canvas> is inaccessible and here is how you solve it". We need to
> carefully consider what people are doing with <canvas>, what authors
> want, whether they might use such an API at all, etc.
>
Unfortunately, ATs don't operate off a wiji board. There needs to be a
vehicle to provide the information from the application
to the assistive technology. Bitmaps, randomly placed text, and polylines
don't do it. We have to capture the intent before shipping it out the door.
That is not
the case now.

That said, we absolutely need to learn how authors are using canvas. I
strongly feel an API is needed. What that will look like remains to be
seen. We have more work to do.

Sorry for not responding quickly. ARIA last call work is keeping me busy.
>
> --
> Anne van Kesteren
> http://annevankesteren.nl/