Re: ACTION-1490 proposal says good bye to the "inline" notion for combobox

Hi Bryan,

On 2016-02-11 1:03 PM, Bryan Garaventa wrote:
> The use of aria-controls in this case solves the issue by setting an explicit association, and aria-activedescendant works in identifying the referenced node that is active.

There may still be a problem -- I am investigating.  The Core-AAM 
describes an algorithm associated with aria-activedescendant that user 
agents MUST execute in order to mark the potential active descendants as 
focusable.  In summary, when the user agent encounters a container with 
an aria-activedescendant attribute, the user agent must visit all 
descendants of the container and determine if they could be the target 
of the container's aria-activedescendant.  The user agent must expose a 
focusable state for each such target, and only for those descendants 
that are targets.

Here "descendants" means either a DOM descendant of the container, or 
one referenced by aria-owns.  This procedure won't succeed for combobox 
containers if aria-controls is used instead of aria-owns.

A way to patch this is to run the exact same algorithm but base it on 
aria-controls if aria-owns is not used.  However, that requires buy-in 
from all user agents, and tests cases for the ARIA test harness.

> I'm getting confused by the reference to modal dialogs. This isn't a modal dialog, it's a Listbox, and focus is never meant to leave the element that includes role=combobox. So what does the modal dialog have to do with it?

Matt's new definition of combobox includes drop-downs that contain a 
grid, a treegrid, or a dialog instead of a listbox.  When Rich discussed 
this with Freedom Scientific, they were willing to handle such cases, 
but only if the drop-down was modal.  The thread starts here:
https://lists.w3.org/Archives/Public/public-aria/2016Feb/0151.html

-- 
;;;;joseph.

'Die Wahrheit ist Irgendwo da Draußen. Wieder.'
                  - C. Carter -

Received on Thursday, 11 February 2016 20:11:05 UTC