RE: Canvas and ARIA alternatives

Hi Steve
 
I totally understand and take your point that:
 
It should be understood that the W3C cannot dictate what technologies are
used, but can ensure technologies developed as W3C standards inlcude the
features required for accessibility... 
 
The problem is that there is always a lag between the introduction of a
particular technology by user agents and the inclusion of the technology
into W3C standards and the accompanying support for accessibility. There's
nothing that we can do about this and I actually don't think anything needs
or should be done about it even if it were possible.  
 
But I do feel that maybe we could look at how such technologies are
considered by applicable guidelines in the interim in order to influence
their use / adoption from an accessibility perspective.
 
I'm not saying that this is an easy problem to solve by the way or that
there is a solution to the problem at all. But if we can't establish a new
approach to address this issue we are going to continually be chasing our
tail. 
 
And as you also say, whether developers make use of these features or
techniques is another matter. But 
 
Cheers
Ian
 
  
 

  _____  

From: Steve Faulkner [mailto:faulkner.steve@gmail.com] 
Sent: 06 August 2012 09:23
To: Ramón Corominas
Cc: w3c-wai-ig@w3.org
Subject: Re: Canvas and ARIA alternatives


hi all,



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.


The canvas accessibility effort has been ongoing for the last 3 years, there
has has been some inital implementaions of accessibility related features
[1]
There are further details being hammered out currently [2]. Canvas will be
able to be used accessibility, but as HTML5 is still in progress,
implementations in browsers need to cathc up.


>Maybe, but SVG's accessibility is not necessarily simpler than canvas
accessibility.

This is correct and the current state of SVG accessibility is no more rubust
than canvas accesibility. Work on SVG accessibility is still in progress,
what is required still needs to be defined and implemnted in browsers. That
work is currently occuring in the SVG working group, primarily by
participants from IBM such as Rich Swerdtfeger [3]


It should be understood that the W3C cannot dictate what technologies are
used, but can ensure technologies developed as W3C standards inlcude the
features required for accessibility, and then again whether developers make
use of those features is another matter.

regards
Stevef

[1]
http://www.paciellogroup.com/blog/2012/06/html5-canvas-accessibility-in-fire
fox-13/
[2] http://www.w3.org/html/wg/tracker/issues/201
[3] http://www.w3.org/Graphics/SVG/WG/wiki/Accessibility_Issues


On 6 August 2012 08:51, Ramón Corominas <listas@ramoncorominas.com> wrote:


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.