- 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>
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
Received on Monday, 1 March 2010 00:53:22 UTC