689841 - Sort out focus management for autocompletes

Status: NEW

(Core :: Disability Access APIs, defect)

Description

[alexander :surkov (:asurkov)]

Menus are UI element that doesn't get DOM focus, I don't see a reason why ARIA menu must be different. Getting this as a start point we should allow aria-activedescendant to change the focus when menu doesn't have DOM focus.

Use case of this behavior is http://hanshillen.github.com/jqtest/#goto_autocomplete. DOM focus stays on autocomplete textbox while autocomplete menu menuitems are managed by active-descendant.

As far as I can see it doesn't break "must section" of ARIA spec 
(http://www.w3.org/TR/wai-aria-implementation/#keyboard-focus_aria-activedescendant)

However takeFocus section doesn't allow us to set menuitem focused in this case
(http://www.w3.org/TR/wai-aria-implementation/#keyboard-focus_at) because we must focus container and if successful to change aria-activedescendant. In this case menu is container and it's not focusable.

I filed bug to w3c http://www.w3.org/Bugs/Public/show_bug.cgi?id=14320

Comment 1

[James Teh [:Jamie]]

Because aria-activedescendant specifies the active descendant of a given element, authors may not expect it to suddenly gain focus when they set it. For example, when creating a list (but not focusing it), the page might set aria-activedescendant to the first list item so that this item will receive focus when the list is focused. Therefore, if this is implemented, I think it should be restricted to menus.

One further issue is demonstrated by the following (admittedly unlikely) scenario where there are two visible menus:
1. menu1 appears. aria-activedescendant on menu1 is set to menu1item1. The page sets focus to menu1, which causes menu1item1 to receive focus.
2. menu2 appears. aria-activedescendant on menu2 is set to menu2item1, but this is only so that menu2item1 will gain focus when focus is set to menu2. However, focus remains on menu1 for now.
If this bug is implemented, the AT will be informed that menu2item1 has the focus, even though the keyboard focus is still on menu1.

Comment 2

[alexander :surkov (:asurkov)]

That should be restricted to visible menus, if menu is visible then we might want to not require it be focused.

Taking into account second scenario (event it's sort of crazy because only one menu should be visible at a time) it doesn't sound that the guess about focus on our side is really good idea and it's quite possible it's better to require the author to deal with focus explicitly. But I wonder what should have DOM focus in case of ARIA context menus?

Comment 3

[alexander :surkov (:asurkov)]

We might want to say that menus suggestion is wontfix but we should figure out how to make ARIA autocomplete widgets accessible.

Suggestion would be is that autocomplete popup is allowed to manage the focused item via aria-activedescendant when it doesn't have DOM focus but its autcomplete widget has. The ARIA widget is autocomplete popup if it has ARIA menu role and contained by autocomplete widget or pointed by aria-owns. Sounds reasonable?