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

Simply because the subtree may not accessibly map to the canvas rendering.
It could in fact be an entirely different application and rendering
designed to do the same thing when <canvas> is not supported. There would
be no correlation to the <canvas> rendering.

You would not want to tab through the subtree and have not display the
rendered focus in the canvas. You would also not want an accessibility test
tool analyze the subtree for canvas if the UI and the subtree are not
related accessibly.

So, the simple answer is to just tell the user agent the intent of the
subtree either at run time or statically which ever works for the author.

Rich Schwerdtfeger
Distinguished Engineer, SWG Accessibility Architect/Strategist


                                                                           
             Ian Hickson                                                   
             <ian@hixie.ch>                                                
             Sent by:                                                   To 
             public-canvas-api         Richard                             
             -request@w3.org           Schwerdtfeger/Austin/IBM@IBMUS      
                                                                        cc 
                                       "public-canvas-api@w3.org"          
             02/17/2010 02:30          <public-canvas-api@w3.org>          
             PM                                                    Subject 
                                       Re: Updated proposal round two      
                                       (based on feedback from Monday's    
                                       meeting)                            
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           




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.   `._.-(,_..'--(,_..'`-.;.'