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

I agree, which is why I’m confused…

From: Cynthia Shelly [mailto:cyns@microsoft.com]
Sent: Wednesday, February 17, 2016 9:38 AM
To: Bryan Garaventa <bryan.garaventa@ssbbartgroup.com>; Rich Schwerdtfeger <richschwer@gmail.com>; Matt King <a11ythinker@gmail.com>
Cc: ARIA Working Group <public-aria@w3.org>
Subject: RE: ACTION-1490 proposal says good bye to the "inline" notion for combobox

But, keyboard trapping is NOT required for comboboxes. Tab should close them and move to the next control.

From: Bryan Garaventa [mailto:bryan.garaventa@ssbbartgroup.com]
Sent: Wednesday, February 17, 2016 9:33 AM
To: Rich Schwerdtfeger <richschwer@gmail.com<mailto:richschwer@gmail.com>>; Matt King <a11ythinker@gmail.com<mailto:a11ythinker@gmail.com>>
Cc: ARIA Working Group <public-aria@w3.org<mailto:public-aria@w3.org>>
Subject: RE: ACTION-1490 proposal says good bye to the "inline" notion for combobox

Hi,
Just to make sure I’m not misunderstanding, we are talking about making aria-modal a general property for any modal element container where focus trapping is needed, right?

I can see that as being beneficial, especially since it removes the necessity for role=dialog.

If you have focus set on an input+type=’text+role=’combobox’ though, and you are using the arrow keys to read the text written and browse the attached options referenced by aria-activedescendant, how would aria-modal come into play in this case? What is the desired effect meant to be?

I’m not trying to be a pain, but I need to understand because this is going to affect how I program these components in the future.

From: Rich Schwerdtfeger [mailto:richschwer@gmail.com]
Sent: Wednesday, February 17, 2016 6:50 AM
To: Matt King <a11ythinker@gmail.com<mailto:a11ythinker@gmail.com>>
Cc: ARIA Working Group <public-aria@w3.org<mailto:public-aria@w3.org>>
Subject: Re: ACTION-1490 proposal says good bye to the "inline" notion for combobox

Yes. That is what I mean.

aria-modal was added to ARIA 1.1 and I believe its scope must be expanded. If we are going to supply this property this is an excellent indicator that ATs can trigger off of to state this restriction (in a human consumable way) to users (when set to “true”).

Rich

Rich Schwerdtfeger



On Feb 17, 2016, at 1:03 AM, Matt King <a11ythinker@gmail.com<mailto:a11ythinker@gmail.com>> wrote:

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

Rich, I am getting the feeling that by "modal" you mean that the tab ring is dynamically restricted to a specific section or DOM node.

Is that your intention?

Matt

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

On Feb 14, 2016, at 11:53 AM, Matt King <a11ythinker@gmail.com<mailto:a11ythinker@gmail.com>> wrote:

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

Mad modal?

made

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.
Matt, it is extremely important to know that if you are in a region where keyboard navigation is isolated to that modal area unless you escape out of it.

So, one thing we are looking at is to have expandable search areas where you hit a button that expands out a search box with a lot of option within in it.
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.

Matt if you are going to launch a dialog box from a combobox then you have broken what people expect a combobox to do. As Cynthia said, this does not sound like a combobox.

What you are doing is launching a modal dialog box and the user needs to know this as you can put anything in it. They don’t know what to expect. They don’t know what combination of functions you are going to operate on to deliver a value to the combobox and they need to be assure that in the middle of it you don’t tab outside of it when you are half way through operating it.
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.

So, we can’t deal with most. We need to let people know what to expect. They typically don’t expect you to navigate a grid and then leave the combobox. It is confusing. Knowing whether it is modal or not is very important. However, the fact that you can launch a dialog box should indicate to ATs what guidance to give the user. For example, It would be good, to know that when you opened the combobox that your keyboard navigation is limited to within the (whatever you launched). We need to be consistent and the ATs need to provide guidance to the user as to what quagmire they just walked into.
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.
ok

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<mailto:clown@alum.mit.edu>>
Cc: Bryan Garaventa <bryan.garaventa@ssbbartgroup.com<mailto:bryan.garaventa@ssbbartgroup.com>>; Matt King <mck@fb.com<mailto:mck@fb.com>>; ARIA Working Group <public-aria@w3.org<mailto: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<mailto: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 -