Re: Updated proposal round two (based on feedback from Monday's meeting)

hi ian,

>That makes sense, except I don't understand why we would ever want to turn
>that behaviour _off_.

if there is focusable content in the canvas sub tree that is fallback, why
would you want it to be tabbable when the canvas is rendered?

regards
stevef


On 17 February 2010 20:30, Ian Hickson <ian@hixie.ch> wrote:

> On Wed, 17 Feb 2010, Richard Schwerdtfeger wrote:
> >
> > So, the purpose of the adom attribute is to say that when it is set to
> > "true":
> >
> > - Direct the browser to include whatever is in the subtree in the
> keyboard
> > navigation order as it is currently
> > being used to represent what is in the UI.
> > - Direct the browser to map what is in the the subtree to the platform
> > accessibility API as it is the author's intent to use
> > it as the accessibility subtree.
> > - Direct an accessibility test tool to analyze the subtree for
> > accessibility support when it <canvas> is being rendered
>
> That makes sense, except I don't understand why we would ever want to turn
> that behaviour _off_. The spec right now requires the UA and AT to assume
> that the "adom" behaviour is always enabled. Why is this a bad thing?
>
> --
> Ian Hickson               U+1047E                )\._.,--....,'``.    fL
> http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
> Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
>
>


-- 
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 Wednesday, 17 February 2010 20:37:09 UTC