RE: Canvas and ARIA alternatives

[Ian Wrote]
> 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.

Yes, I agree.  While my prior email was referring to input elements links
buttons, checkboxes, etc. the technique you describe is similar to what
Google docs does for editing --although I do not believe they are using a
canvas.  They are however, painting a blinking caret into a page area that
does not have contentEditable set to true and therefore there is no input
caret accessibility.  This affects screen reader users, low vision users,
and those who change the caret blink rate as no API exist to expose this
information.  And here lies the challenge of making new technologies
accessible - there is always a gap between when a technique is used and
when accessibility information such as an API can be constructed and
agreed upon and implemented in the user agents for users with
disabilities.  This leads to lag times of at least 6 months and requires
users of assistive technology to run the latest version of AT and the user
agent.

What we really need is an universal API that can be learned dynamically by
AT.  Basically, an author could create their own API that maps to an app
and then also define the public methods and signature and how they should
be interpreted or mapped to standard concepts like states, roles, etc..
The user agent and assistive technology would then be able to take any new
API that contains these definitions and interface and translate it into
the proper platform level properties and events for assistive technology
to user.  At the same time User agent APIs need to be able to share
information about the user's platform accessibility features back to the
app/site so it can then adapt to settings such as high contrast, keyboard
blink rate, etc.

Jonathan

-----Original Message-----
From: Ian Sharpe [mailto:isforums@manx.net]
Sent: Monday, August 06, 2012 6:11 AM
To: 'Ramón Corominas'; w3c-wai-ig@w3.org
Cc: 'WAI Interest Group'
Subject: RE: Canvas and ARIA alternatives

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 13:08:12 UTC