Re: navsubtree proposal for accessible canvas and Issue 74

So, Chaas, can you write up your counter proposal? If I'm not mistaken,
it would require significantly more change to the current HTML spec than
the proposal from the Canvas Subteam. It would be important to have the
specifics formally spelled out.

Janina

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

-- 

Janina Sajka,	Phone:	+1.443.300.2200
		sip:janina@rednote.net

Chair, Open Accessibility	janina@a11y.org	
Linux Foundation		http://a11y.org

Chair, Protocols & Formats
Web Accessibility Initiative	http://www.w3.org/wai/pf
World Wide Web Consortium (W3C)

Received on Wednesday, 3 March 2010 15:39:18 UTC