Re: Please vote on the canvas accessibility proposal

Hi Chaals,

Some aspects of your proposal, it would appear, have wide support, since the
idea of using image map on canvas has been raised on a number of occasions
(including a bug report) over the past couple of weeks, and I have yet to
see any argument against.

It would be useful to hear from any of the stake holders, if they have any
serious reservations about the image map approach being at least *part of
the solution* to providing more robust accessible canvas content.

regards
Stevef

On 1 March 2010 00:52, Charles McCathieNevile <chaals@opera.com> wrote:

> 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):
>
> <html>
> <head>
>  <title>maptestx</title>
> </head>
>
> <body>
> <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"
> coords="276,0,276,28,100,200,50,50,276
> ,0">Top Ten</a>
>     </map>
> </object>
>
> </body>
> </html>
>
> (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 not.
>
> ...
>
>
>  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.
>
>
> cheers
>
> Chaals
>
> --
> 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
>
>


-- 
with regards

Steve Faulkner
Technical Director - TPG Europe
Director - Web Accessibility Tools Consortium

www.paciellogroup.com | www.wat-c.org
Web Accessibility Toolbar -
http://www.paciellogroup.com/resources/wat-ie-about.html

Received on Monday, 1 March 2010 07:24:46 UTC