Re: handling focus

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.

>
>