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

I agree it's a bit confusing, and the reason for not using aria-owns again goes back to the inability of ATs like some screen readers in some browsers to properly render the Listbox content when referenced using aria-owns.

E.G The Listbox disappears when aria-owns is used, because the AT can render a Combobox, or a Listbox, but not both at the same time within the same control when only one is being interacted with.

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.

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?



-----Original Message-----
From: Richard Schwerdtfeger [mailto:richschwer@gmail.com] 
Sent: Thursday, February 11, 2016 9:07 AM
To: Joseph Scheuhammer <clown@alum.mit.edu>
Cc: Bryan Garaventa <bryan.garaventa@ssbbartgroup.com>; 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

Good point Joseph. One of the things I have been wrestling with is the fact that what is being launched (if it is not a descendant - hence aria-activedescendant) is the fact that what gets launched must indeed be a modal window. 

This would get us away from having to apply aria-activedescendant on a combobox in these instances however it needs to be clear that if aria-controls is these are housed in modal windows that are controlled by combobox. 

I am seeing other use cases in IBM where even expandable landmarks are mad “modal”. I think we need to discuss modality in this scenario. Clearly aria-activedescendant will not work in these scenarios (pop up control) as it is not a descendant. This really is not any different that having a live region controlled by another part of the page. If it is not owned then the focus must be determined by the modal window or object with in the window/container. 

Another option is to place these things in a dialog box where the combobox launches a dialog box with objects within. The dialog box MUST be modal. 

Rich

> On Feb 11, 2016, at 10:19 AM, Joseph Scheuhammer <clown@alum.mit.edu> wrote:
> 
> On 2016-02-08 10:42 AM, Bryan Garaventa wrote:
>> 
>> That is not true. This is why we support aria-activedescendant on role=”combobox”. Please test the following implementation that uses this technique.
>> 
>> http://whatsock.com/tsg/Coding%20Arena/ARIA%20Comboboxes/ARIA%20Comboboxes%20(Simulated,%20Readonly)/demo.htm <http://whatsock.com/tsg/Coding%20Arena/ARIA%20Comboboxes/ARIA%20Comboboxes%20%28Simulated,%20Readonly%29/demo.htm>
>> 
> 
> Warning: sarcasm, ahead.
> 
> You have implemented a combobox that uses aria-activedescendant without aria-owns.  What is the active descendant a descendant of? Not the combobox, actually.
> 
> Does this mean we need to re-write the definition of aria-activedescendant?
> 
> :-)
> 
> -- 
> ;;;;joseph.
> 
> 'Die Wahrheit ist Irgendwo da Draußen. Wieder.'
>                 - C. Carter -
>

Received on Thursday, 11 February 2016 18:04:02 UTC