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

I reply on one bit inline, down near the "practical error" part:

On Tue, Nov 15, 2011 at 12:23 PM, 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.


I think this might be right. Perhaps we should advocate that aria-AD not be
used in these cases and  in addition to your suggestion of an aria
relationship perhaps a polite live region could help.

D



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