Re: handling focus

This is easy to solve. What if we excluded input controls from the shadow
DOM. Rather limit the DOM to divs, spans, contenteditable areas, tables,
links and so on?

Rich

Rich Schwerdtfeger
Distinguished Engineer, SWG Accessibility Architect/Strategist


                                                                           
             Alexander Surkov                                              
             <surkov.alexander                                             
             @gmail.com>                                                To 
                                       Richard                             
             11/17/2009 12:34          Schwerdtfeger/Austin/IBM@IBMUS      
             AM                                                         cc 
                                       James Craig <jcraig@apple.com>,     
                                       Steven Faulkner                     
                                       <faulkner.steve@gmail.com>,         
                                       public-canvas-api@w3.org,           
                                       public-canvas-api-request@w3.org    
                                                                   Subject 
                                       Re: handling focus                  
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           




Hi.

Yes, I think it should be a technical problem to pass focus to the
shadow content. However this is not the unique reason I don't like
this idea.

1. It's not good from user point of view. If canvas author puts
control elements inside of shadow tree and do not process the focus
visually in cavas bitmap then we get no focus on the focused window
what is quite strange. If the focus would be always on canvas element
then it's ok even if canvas bitmap is broken by author.

2. On the another hand it might introduce additional problems to
canvas bitmap author rather than help him. The reason is the author
needs to coordinate virtual focus in canvas bitmap with hidden focus
in the shadow tree and this might be a pain because canvas bitmap
author can't control the shadow tree focus entirely. There is one
available way to do this is to control elements order but since
different control elements in different browser have different
behaviour (for example, HTML select is tabable in Safary but it's not
tabable in Firefox) this might be a problem. If author makes control
focusable for AT users by aria-activedescendant and process tab key
presses to draw canvas bitmap focus then he controls both focuses
entirely and this shouldn't be technically harder than @tabindex
usage.

Thank you.
Alex.


On Tue, Nov 17, 2009 at 8:09 AM, Richard Schwerdtfeger
<schwer@us.ibm.com> wrote:
>
>
> Rich Schwerdtfeger
> Distinguished Engineer, SWG Accessibility Architect/Strategist
>
> public-canvas-api-request@w3.org wrote on 11/16/2009 05:47:06 PM:
>
>> James Craig <jcraig@apple.com>
>> Sent by: public-canvas-api-request@w3.org
>>
>> 11/16/2009 05:47 PM
>>
>> To
>>
>> Steven Faulkner <faulkner.steve@gmail.com>
>>
>> cc
>>
>> public-canvas-api@w3.org
>>
>> Subject
>>
>> Re: handling focus
>>
>> On Nov 16, 2009, at 5:27 AM, Steven Faulkner wrote:
>>
>> > at TPAC the provision of a method to draw focus rectangles on a
>> canvas was discussed, and it appeared that this was considered
necessary,
>>
>> In the shadow DOM proof of concept I developed, I just drew the
>> focus ring with the canvas. I don't see any need to have a native
>> focus ring drawn on top of the canvas. I'd say, leave a custom view
>> like canvas for the author to manage.
>>
>
> I agree with this and drawing visible focus on canvas needs to be
> non-standardized. Canvas authors will also have different look and feels.
>
>> > how does this fit in with the use of active-descendent to track
>> focus in a shadow DOM?
>>
>> Only using 'active-descendant' would allow for a shadow DOM as deep
>> as one managed focus widget. This is fine, but a standard focus
>> model inside the shadow DOM is necessary, too. Otherwise you'd need
>> to render a separate canvas element for every complex widget, so
>> something as complex as Bespin could never be achieved by using a
>> single active descendant.
>>
> Mozilla expressed a concern in using tabindex inside the shadow DOM as it
> created issues with the layout engine. Were you suggesting using tabindex
or
> an alternative vehicle? The challenge as I understand it is that the
shadow
> DOM is invisible and focus in Mozilla is tied to a visual rendering.
>
> I am not sure why you saying there is a problem with Bespin. You may in
fact
> need a separate accessible object for each complex object in Bespin to
> convey the accessibility information. When I looked at Bespin it had a
tool
> bar and a text editor with line numbers. I can see having
> aria-activedescendant being able to manage that albeit more work as in
the
> case of the toolbar having a combobox.
>
> A combination of tabindex and aria-activedescendant would work for me too
> but Alex mentioned issues with the layout engine. I would like Alex to
speak
> to that. In my mind the user agent would need to make sure that focused
> shadow DOM elements would be in the tab order but they would also need to
be
> non-visible and present in the accessibility tree.
>
>>
>>
>