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

Re: Please vote on the canvas accessibility proposal

From: Charles McCathieNevile <chaals@opera.com>
Date: Mon, 01 Mar 2010 01:52:36 +0100
To: "Richard Schwerdtfeger" <schwer@us.ibm.com>, "Silvia Pfeiffer" <silviapfeiffer1@gmail.com>
Cc: "Ian Hickson" <ian@hixie.ch>, public-canvas-api@w3.org, "public-html-a11y@w3.org" <public-html-a11y@w3.org>
Message-ID: <op.u8u51yotwxe0ny@widsith.local>
On Thu, 25 Feb 2010 16:19:13 +0100, Richard Schwerdtfeger  
<schwer@us.ibm.com> wrote:

> Silvia Pfeiffer <silviapfeiffer1@gmail.com> wrote on 02/24/2010 05:35:00
>> On Thu, Feb 25, 2010 at 2:08 AM, Richard Schwerdtfeger
>> >>> 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

Yes, I think we are.

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

Under the proposal (to reinstate the HTML 4.01 version of image maps) you  
can actually have some of the accessibility content rendered as fallback  
where there is no canvas, and some of it not rendered. You can also have  
fallback content in the canvas which is not relevant to accessibility See  
below for the current state of affairs in reality (which is better than  
what the HTML5 spec offers today). You can always have  
accessibility-related content outside the canvas as well - for example,  
buttons which activate some functionality, or where the canvas is  
responding to a form. I have a demo of this if anyone wants, but it's a  
reasonably obvious thing to do.

> The usemap approach does not allow the author to use standard HTML  
> element

Actually, it does in the proposal at  
http://www.w3.org/html/wg/wiki/ChangeProposals/Map4NotAdom (which requests  
the HTML 4.01 version of image maps instead of the HTML 5 version). An  
example, using the object element instead of canvas (since it saves me  
 from having to write a script that puts something on a canvas):


<object type="image/jpg" data="miel.jpg" usemap="#map1">
<map name="map1">
        <p>Navigate the site:
        <a href="guide.html" shape="rect" coords="0,0,118,28"><img  
src="rect.png" alt="access"></a> |
        <a href="shortcut.html" shape="rect" coords="118,0,184,28">Go</a> |
        <a href="search.html" shape="circle" coords="184,200,60">Search</a>  
        <a href="top10.html" shape="poly"  
,0">Top Ten</a>


(This works fine in Opera and Firefox, but Safari shows the HTML content  
since apparently it can't handle a JPG object?)

Oddly enough, neither Firefox nor Safari (I am testing on a Macintosh  
today) manage to handle a mixture of block content and area elements -  
they seem to have missed the HTML 4.01 upgrade that allows this - although  
it dates from december 1999, so is far older than either browser.

This means that apparently the HTML 4 version of image maps is reasonably  
interoperably implemented. (Which makes me wonder why HTML 5 tries to get  
rid of it). So right now, with no work at all, we can allow authors to  
either use area elements, and add aria information to them, which will  
only have an effect if the canvas is rendered, or they can use structured  
HTML inside the canvas element, which will be rendered if the canvas is  


> I believe the opera approach is great for many implementations but let's
> not make this harder for the author. The Opera approach has limitations.

The limitations are pretty few, I think. I'd be interested to learn what  
you think they are.

The proposal to reinstate the HTML 4.01 version of image maps requires  
some tweaking to some browsers. That removes the only limitation I can  
think of: that you can't have some of your imagemap be visible structure  
included in the fallback where canvas is not rendered, and some of it only  
available where the canvas is rendered. If we were happy to accept that  
limitation, then whatever the specification draft *says* now, the reality  
is that we have this already in actual shipping browsers (I haven't tested  
IE yet, but I assume )

Under my proposal, you can't test for the presence of an adom attribute to  
determine whether there is an accessible navigation fallback. I consider  
that a feature of the proposal - the presence of the attribute doesn't  
provide any meaningful information about whether the canvas really is  
accessible, but it is almost certain to be used as a proxy for testing  
that. At the same time, there is no reason I can see to assume that the  
only way to make a canvas accessible requires placing the accessibility  
features inside the canvas, and many use cases I can think of where this  
is not the case.



Charles McCathieNevile  Opera Software, Standards Group
     je parle français -- hablo español -- jeg lærer norsk
http://my.opera.com/chaals       Try Opera: http://www.opera.com
Received on Monday, 1 March 2010 00:53:25 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:55:32 UTC