Re: navsubtree proposal for accessible canvas and Issue 74

On Mon, 01 Mar 2010 23:24:24 +0100, Richard Schwerdtfeger  
<schwer@us.ibm.com> wrote:

> Please create a straw poll to discuss on Thursday. The group feels it has
> addressed the adom accessibility compliance confusion with this proposal
> and also the default for keyboard navigation made at the last html task
> force meeting. Members must vote on this by the end of Wednesday so that  
> we can review the results Thursday.

I vote against this (I don't really see how it is different to the adom  
proposal in substance).

I have been reading the draft again, revision $Revision: 1.3865 $.

As I understand it, currently the draft requires the fallback content to  
be navigable when the canvas is being rendered.

[[[
In interactive visual media, if scripting is enabled for the canvas  
element, and if support for canvas elements has been enabled, the canvas  
element represents embedded content consisting of a dynamically created  
image.

In non-interactive, static, visual media, if the canvas element has been  
previously painted on (e.g. if the page was viewed in an interactive  
visual medium and is now being printed, or if some script that ran during  
the page layout process painted on the element), then the canvas element  
represents embedded content with the current image and size. Otherwise,  
the element represents its fallback content instead.

In non-visual media, and in visual media if scripting is disabled for the  
canvas element or if support for canvas elements has been disabled, the  
canvas element represents its fallback content instead.

When a canvas element represents embedded content, the user can still  
focus descendants of the canvas element (in the fallback content). This  
allows authors to make an interactive canvas keyboard-focusable: authors  
should have a one-to-one mapping of interactive regions to focusable  
elements in the fallback content.
]]] - http://dev.w3.org/html5/spec/Overview.html#canvas

Which suffers from the same problem that this proposal and the adom  
proposal suffer: They all assume that the content of the canvas element is  
the appropriate place to include navigation objects required for  
accessibility, whereas I maintain that it may well be the case that some  
fallback content is not relevant where the canvas "represents embedded  
content" (that's spec-talk for "shows the picture") while some content  
outside the canvas element may well form part of the ensemble that makes  
the canvas accessible.

> This also allow for areamap to be used in the future should a proposal
> by Chaals be approved for areamap.

(I tested HTML 5's replacement for the HTML 4.01 image map model - but on  
Mac it fails in Firefox as well as Safari and only works in Opera. I will  
continue with the proposal I had)

> The justification for this change is to provide for a focus navigable
> binding of what is rendered in canvas using standard HTML elements in the
> area currently designated as the fallback content for <canvas> and  
> provides the means for the browser to provide an accessibility API
> binding based on HTML 5 content.

The proposal is an improvement on the current HTML 5 draft, since it  
allows the author to declare whether or not the canvas subtree should be  
navigable (instead of forcing that to be the case, as per the current  
draft).

However, it doesn't (unlike the proposal to use <usemap> and <map>)  
provide a way of having navigable content of the canvas that "disappears"  
if the fallback content is rendered instead.

It also requires a new attribute, when there is better markup that has  
been around for most of the life of the web, and which has already been  
explained in the last decade's efforts at educating authors, coded into  
authoring tools, and coded into browsers (moderately well - Safari is the  
worst implementation I found: it offers the ability to use an image map in  
a canvas, but without block content (or what html5 calls flow content) and  
I can't find out how to navigate any image map by keyboard. Opera 10.50  
and Firefox 3.6 show every sign of already supporting the test cases I am  
working on, and reportedly IE does too)

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 Tuesday, 2 March 2010 19:42:16 UTC