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

Thanks, I understand the logic, especially regarding event bubbling. However in all the tests I've done, I don't remember ever seeing this work where an owned element passed events up to its parent if it wasn't a direct child already.

This really is a problem, because I have clients who have been using components like these for years, referencing controls from one place that are not good to represent as children.

The example that I gave previously was one, where typing into a search field would dynamically populate a list of school chariculum and scoring results, and the user could then press Up/Down while focus was still set on the search field to browse them. Pressing Enter at this point would navigate to a page containing more information about that search result.

However, the search results list contained links that performed the same actions, and in some cases, other active elements for other filtering capability, none of which made any sense as a parent child relationship of the initial search field.

This is a huge problem, and limitting aria-activedescendant in this way is hobbling the actual range of accessible solutions that developers can provide.

Since this already works, I still think an aria-controls relationship is reasonable, as too is redefining aria-activedescendant to cover situations like this when event bubbling is not needed.

-----Original Message-----
From: Joseph Scheuhammer [mailto:clown@alum.mit.edu] 
Sent: Tuesday, February 16, 2016 10:48 AM
To: Bryan Garaventa <bryan.garaventa@ssbbartgroup.com>; Rich Schwerdtfeger <richschwer@gmail.com>
Cc: Matt King <mck@fb.com>; ARIA Working Group <public-aria@w3.org>
Subject: Re: ACTION-1490 proposal says good bye to the "inline" notion for combobox

Hi Bryan,

I wrote:
>
> “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.”
>

You replied:
>
> This is the part that is confusing me, because it already works, I’ve 
> tested this in IE11, Firefox, Chrome using JAWS and NVDA and it works 
> accessibly, and the same implementation is accessible in iOS using 
> VoiceOver in Safari.
>

What's working is the faux-focus that aria-activedescendant provides.  
That's likely working because the browsers are not taking the time to check whether the element that aria-activedescendant references is, in fact, a descendant.  That check is not performant.  The browsers are taking the author at their word.

What can't be working is the procedure for checking all the descendants of the combobox and marking specific ones as focusable. Note the "able".  A focusable state is neither a focused state nor a non-focused state but the ability to take keyboard focus at some point in time. 
AAPIs support a number affordances and being able to become focussed is one of them.

To repeat:  the core-aam defines a procedure that user agents must execute for containers that use aria-activedescendant to determine the focusable descendants within the container.  It won't work given the new combobox specification where the listbox is not a child of the combobox.

Possible solutions:
1. Run the same procedure, but base it on aria-controls.  However, Rich shot this down.
2. Do not use aria-activedescendant in this case.  But, then, I don't see how to get the effect of keeping actual focus in the text entry field while changing the active-descendant focus.
3. Re-write the definition of aria-activedescendant to include things that are not actual descendants.

-- 
;;;;joseph.

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

Received on Tuesday, 16 February 2016 19:45:46 UTC