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

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 Tuesday, 15 November 2011 17:23:36 UTC