W3C home > Mailing lists > Public > w3c-wai-ig@w3.org > July to September 2012

RE: Canvas and ARIA alternatives

From: Ian Sharpe <isforums@manx.net>
Date: Mon, 6 Aug 2012 11:11:26 +0100
To: "'Ramón Corominas'" <listas@ramoncorominas.com>, <w3c-wai-ig@w3.org>
Cc: "'WAI Interest Group'" <w3c-wai-ig@w3.org>
Message-ID: <159E1ECA47454486B248381DA0501776@BLACKBOX>
Cheers Ramón and thanks for the clarification. I think most of my comments
are more a result of my ignorance in relation to what is already happening
"behind the scenes" and also due to my assumption from the original message
in this thread that the canvas was being used for user input, as a
replacement of textboxes etc.

I think you hit the nail on the head though when you say:

"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."

My point is really that in such scenarios, I feel we should focus our
efforts on ensuring that an element is accessible in the use case for which
it is primarily intended - the reason for it's inclusion in the HTML5 spec.
I just don't think we can predict how such an element might be used and
hence shouldn't try to facilitate it's potential use in all possible
scenarios from an accessibility perspective. And I definitely don't believe
we should be encouraging it's use in such scenarios when perfectly
reasonable alternatives exist.

In the case of canvas, while I appreciate it could be used for more or less
anything, it is primarily a graphical rendering surface and as such, we
should focus on ensuring that the most likely use case(s) for such an
element is accessible. We should not (in my view) for example be trying to
ensure that a canvas element is made accessible for say the purpose of text
input when a perfectly reasonable accessible alternative exists. This is
what I mean by the abuse of an element.

I don't think that is what the original email was suggesting though with
hindsight or what you are saying either, but just wanted to explain myself.

I do also feel however,  that we are in a position, through the adoption of
WCAG by governments in legislation, to at least influence how certain
elements should be used to ensure accessibility but get the impression that
you do not feel the same way? Obviously I appreciate the sensitivities
around how this might happen but I personally feel it is a debate worth
having.

I also get the impression that you are resigned to the fact that
accessibility is not the priority for most people. I totally understand
where you're coming from and wouldn't try to disagree with the fact that it
isn't the priority for most people. But I do believe that particularly in
the case of the web, I, and given the inclusive vision, it should be and
that this argument could perhaps be used to try and move accessibility up
the priority list within W3C. 

It's only natural that developers will use technology and techniques with
which they are more familiar to perform a given task, even if it isn't the
"best" way to achieve this task, even if it involves significantly more
effort and ultimately results in a poor implementation. And this doesn't
have anything to do with the web or accessibility. 

However, in terms of the web, accessibility and the presentation of content,
it is extremely important that developers / authors use the most appropriate
"semantic" markup to perform a given task and I feel we should be focusing
our efforts on this rather than dealing with the fall out from the abuse of
any given element or technology. 

Hope that helps.

Cheers
Ian



   


 



 

-----Original Message-----
From: Ramón Corominas [mailto:listas@ramoncorominas.com] 
Sent: 06 August 2012 08:52
To: w3c-wai-ig@w3.org
Cc: 'WAI Interest Group'
Subject: 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 10:12:03 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 5 February 2014 07:13:30 UTC