Re: Bug 14320 as discussed in Re: [aapi] UAI TF Meeting Minutes, November 8, 2011

Hi, Joseph.

I'd say it's neither grid nor tabbed page, it's something else.

We have relatively close widgets:
1) Comboboxes
Perceived focus is always either on combobox or on combobox option.
Autocomplete looks like combobox except the focus might be perceived
differently.
2) Menus
If the user activates menu while text edit is focused then I'd say
perceived focus is on menu item however caret is blinking on the text
edit. Until the user leaves the menu he can't interact with text edit.
That a difference from autocomple widget.
3) Command prompt navigation
Perceived focus is always on command prompt, it might look the same as
autocomplete widget except the user gets additional information, for
example what options are and which option is currently traversed.
Autocomplete widgets that doesn't update text entry on navigation
through options don't look much like command prompts.

Anyway we have following alternatives:
1) Expose active descendant state on the option accessible and fire
active descendant change events
I'm not sure that every accessibility APIs supports that. But those
ATs who use suitable API will pick up this sooner or later. On the
other hand that makes aria-activedescendant is unique known case for
that. At least I'm not aware about other examples and Firefox doesn't
use this state and event currently. That could mean that browsers and
ATs should have special support for aria-activedescendant.
2) Map into focus concept.
That's what I suggested. Firefox has awesome bar widget which is
autocomplete. This widget is exposed similar to combobox, i.e. user
actions are mapped into focus events. The focus is a concept very well
supported by ATs and it looks AT are happy with this approach.
3) Make ARIA widget authors take care about that.
For example, use live regions to make AT announce the selected option.
But it's more pain for ARIA widget developers. I'd say the widget
creation should be easy as possible and the browser should help on
this way.

Thank you.
Alex.


On Wed, Nov 16, 2011 at 2:23 AM, Joseph Scheuhammer <clown@alum.mit.edu> wrote:
> All:
>
> This thread began as a comment by Matt King that he hasn't found a useable
> ARIA combobox.  The general feeling is, I think, that this is related to the
> use of aria-activedescendant, and how it affects focus.
>
> IMHO, the current example of the autocomplete combobox suggests that there
> is a subtle difference in the meaning of aria-activedescendant compared to
> its original purpose.  Using Larry's concept of "perceived focus", let me
> try to flesh that out.
>
> Consider another common example where one might use aria-activedescendant:
>  a grid.  As the user arrows around the grid, a cell is visually marked with
> a focus ring to show the user which one has focus.  And, the user perceives
> that cell as focussed.  Under the hood, however, DOM focus is on the grid
> container element and remains there.  The code tracks the cell that the user
> has navigated to, and styles it to appear as if it has focus.
>
> This case is what aria-activedescendant was designed for.  Instead of using
> the roving tabindex technique, where DOM focus *is*moved among the cells,
> DOM focus stays on a parent container, and it keeps track of the perceived
> focus using aria-activedescendant.
>
> Compare that with the autocomplete combobox example.  For me (and maybe it
> is just me) perceived focus stays on the text input always.  I don't
> perceive focus ever moving to the list even when using up and down arrows.
>  The input caret is clearly blinking in that text field, and I know that if
> I type any characters, they will end up there.  The highlighting of list
> items with up/down arrows is undoubtedly useful feedback, but I don't
> perceive focus moving to the highlighted item.
>
> Perhaps it is a practical error to use aria-activedescendant in this case.
>  Since highlighting list items is extra information, perhaps it is better
> handled by an aria-controls relationship.  By way of comparison, consider a
> tabbed pane.  Here, the DOM focus and the perceived focus remains on the
> tabs as the user navigates among them, but the visible tab-panel keeps
> switching according to which tab has focus.  Users do not perceive the
> tab-panel as the focussed object (if aria-activedescendant were used),
> rather, they see it as the relevant panel associated with the tab that
> currently has focus (the object identified by aria-controls).
>
> Is a combobox more like a tabbed pane, or more like the grid example?
>
> --
> ;;;;joseph
>
> 'I had some dreams, they were clowns in my coffee. Clowns in my coffee.'
>                     - C. Simon (misheard lyric) -
>
>

Received on Wednesday, 16 November 2011 07:53:09 UTC