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

Re: Canvas and ARIA alternatives

From: Steve Faulkner <faulkner.steve@gmail.com>
Date: Mon, 6 Aug 2012 09:23:15 +0100
Message-ID: <CA+ri+V=B=1W9ms7ibzhWvo35aEOoFiOiMgrYsMWWOMm=Y2E99A@mail.gmail.com>
To: Ramón Corominas <listas@ramoncorominas.com>
Cc: w3c-wai-ig@w3.org
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-firefox-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.
>
>
Received on Monday, 6 August 2012 08:24:24 UTC

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