Re: Canvas and ARIA alternatives

Hi, Ian and all

> 1. (...) I would just like to see accessibility moved up the priority
 > list as I'm sure so would everyone else.

And that is what is being done now within the W3C, isn't it? HTML5 is 
still under development, and accessibility issues are being taken into 
account, including the canvas element.

> 2. What's happened to SVG? As far as I am aware, canvas was primarily
> introduced into HTML5 as a more performant graphics rendering surface and so
> can understand why this is important in terms of video games, but SVG would
> seem to offer an obvious, more accessible alternative in a couple of the
> examples you give.

Maybe, but SVG's accessibility is not necessarily simpler than canvas 
accessibility. The real challenge is not usually the type of object or 
technology, but finding usable ways to put the information for the 
screen reader so users can understand it.

For example, a map can be rendered with SVG, but this will not eliminate 
its complexity. We could also render the map using canvas or even static 
images, but in any case we still need to convey complex information to 
the blind user.


> 3. (...) is it not possible to simply provide accessible elements
 > to manipulate / interact with the canvas? This may be a slightly
 > naive question but it would be helpful if I could better
 > understand the issue.

Yes, of course, and this is probably the best approach for many 
applications. This is similar to those accessible interfaces for Flash 
video players where the controls are pure HTML that communicate with the 
Flash player using JavaScript. A similar technique can also work with 
canvas in many cases, although it will depend on the UI and its 
interaction design.


> 4. I think we all agree that innovation will happen whatever we do. I just
> feel that the web, in contrast to proprietary technology, has a
> responsibility to us all to try and limit exclusion where ever possible. And
> given our limited resources, I feel we have a better chance of improving
> accessibility for more people by focusing primarily on the most common
> use-case scenarios.

What do you mean by "focusing on the most common use-case scenarios"? 
Creating new techniques? Education? Documentation? What kind of effort 
would you prioritize?

Most common scenarios have already been covered in terms of specs. Of 
course we can still improve this information or do a lot of education, 
but the techniques for most common content already exist.

But we also need to put effort on canvas accessibility NOW, because if 
we don't do it now, then we will not have the chance to do it in 2014 
when HTML5 will -hopefully- become Recommendation.


> Yes we certainly need to be involved in the development
> of new technology to incorporate accessibility from the ground up, and if
> that's happening great. But it doesn't feel like accessibility is as high up
> the priority stack as I personally feel it should be given the inclusive
> vision.

Yes, accessibility in general is not the priority for most people, and 
this is not different within the W3C. But those few accessibility 
advocates are doing their best to include accessibility in the specs, 
including the canvas element.

Unfortunately, most developers don't know or don't care about the specs 
(even the existing ones), but this is not a problem of the specs 
themselves. We need accessibility integrated into education programs in 
universities and other schools, but this is not the W3C responsibility.


> in the case of the web and standards through W3C, we should be
> starting with the question, how do we provide new functionality in an
> accessible way, rather than let's include new technology and then try
 > and make it accessible.

What do you propose? New techniques? Demos? Examples? What kind of 
things should be done that are not being done now?

As for the "including new technology and then...", the W3C process is 
consensus-based, so it is not easy to include a new technology (or even 
a new HTML element). Indeed, there have been lots of proposals for new 
elements that have been discarded. The <canvas> element is there because 
the need exists. So, once we have decided that there is a need, the next 
step is to define how the element will exactly work and then how to make 
this functionalities accessible.

The problem with canvas is that it is a multipurpose element that can be 
used in many different ways, so it can be hard to predict how developers 
will use it; and therefore its accessibility needs to take into account 
many possibilities. That's what is happening now, and with luck we will 
have an accessible canvas at the end of the process.

Cheers,
Ramón.

Received on Monday, 6 August 2012 07:53:58 UTC