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

Rich wrote:
>I am seeing other use cases in IBM where even expandable landmarks are mad “modal”.

Mad modal?

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

I do not understand where modality becomes part of this discussion.
Maybe an example would help.

The new combobox text is not meant to create a new interaction paradigm. It's primary purpose is for ARIA to catch up with what is actually happening on the web.

While there are some comboboxes that open a dialog, most that pop open a listbox or a grid that mimics a list are not changing the conventional interaction model at all. In a conventional combobox, if you open the listbox, down arrow to a particular value, and then press tab, the value that had focus is placed into the combo input and the focus moves to the next element on the page. I am not clear why it would make any difference whether the list is made with a listbox, tree, or grid. The same behavior is equally workable.

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

That is an option that works. And, in that particular case, I agree that it wouldn't make sense to use aria-activedescendant.

Matt

-----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 Sunday, 14 February 2016 17:53:46 UTC