Re: navsubtree proposal for accessible canvas and Issue 74

On Wed, 03 Mar 2010 01:05:00 +0100, Janina Sajka <janina@rednote.net>  
wrote:

> Chaas and All:
>
> It seems to me this disagreement would benefit mightily from some
> telecon time. So, I'm putting it on the agenda for Thursday's TF call.
> I'm assuming, Chaas, you can make that? Please advise.

I'm not yet sure, and won't know until almost the time of the telecon :( I  
have a pretty heavy schedule for the next two weeks ;( But I will try.

cheers

Chaals

> Janina
>
> Charles McCathieNevile writes:
>> 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
>


-- 
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 Wednesday, 3 March 2010 01:17:20 UTC