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.
>
>>
>>
>

Received on Tuesday, 17 November 2009 06:35:07 UTC