W3C home > Mailing lists > Public > public-html-a11y@w3.org > February 2010

Re: Please vote on the canvas accessibility proposal

From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
Date: Thu, 25 Feb 2010 10:35:00 +1100
Message-ID: <2c0e02831002241535p6a8949a6x28fb5d38c010f04a@mail.gmail.com>
To: Richard Schwerdtfeger <schwer@us.ibm.com>
Cc: Ian Hickson <ian@hixie.ch>, Steven Faulkner <faulkner.steve@gmail.com>, public-canvas-api@w3.org, "public-html-a11y@w3.org" <public-html-a11y@w3.org>, public-html-a11y-request@w3.org
On Thu, Feb 25, 2010 at 2:08 AM, Richard Schwerdtfeger
<schwer@us.ibm.com> wrote:
>>> Ian Hickson <ian@hixie.ch>
>> Sent by: public-html-a11y-request@w3.org
>> The one <canvas> I use on a regular basis (not a demo) has accessible
>> fallback and no adom="" attribute. Which is more common is essentially
>> impossible to tell from purely anecdotal evidence.
>>    http://www.whatwg.org/issues/data.html?period=1

Seeing this example and comparing it to the spec at
http://dev.w3.org/html5/2dcontext/#focus-management makes me wonder if
we are in fact dealing with two different types of accessibility
information for <canvas>:

* there is canvas accessibility information (like in Ian's example)
that can easily stand by itself if the canvas is not rendered, i.e. it
will also work in legacy browsers as fallback content

* there is canvas accessibility information (like the example in the
Focus Management section) that is not relevant to be displayed without
the canvas, i.e. it is not relevant fallback content

In Ian's example, there is basically no difference between fallback
content and accessibility replacements for <canvas>. Therefore, it is
easy to add it inside the <canvas> as fallback and at the same time
let it be available for AT. (maybe with the added improvements
recommended by Richard).

However, where the accessibility information doesn't make sense to be
also fallback - namely when drawFocusRing is used, which only makes
sense when the <cavas> is actually displayed - there is no means to
decide for a legacy browser if this should be displayed or not. The
proposed <usemap> seems to make a lot of sense in this situation. Then
anything outside the <usemap> element can continue to be fallback
content, but the stuff inside <usemap> is just for accessibility

> adom basically says, as in the proposal, that if it is set to use the
> <canvas> subtree (between the start and end canvas tags) as the accessible
> representation of what is being drawn on canvas.

I am skeptical about absolute statements like this. To me,
accessibility is not a boolean - there are many shades of
accessibility. What if the Web developer thinks they have made the
subtree accessible, but have in fact forgotten to add aria attributes
and such? Or take Ian's example - Ian thought his example was
accessible, but you pointed out how it could still be improved. I am
under the impression that most of the time that is a typical

I think a tool that needs to evaluate whether something is accessible
cannot rely on an attribute but has to do the hard work of actually
walking through the DOM tree and identifying whether there is actual
effort done in providing accessibility markup.

Anyway - just my 2c as an curious onlooker (and hoping we won't run
into similar issues with media elements).

Received on Wednesday, 24 February 2010 23:35:57 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:05:09 UTC