RE: ACTION-1490 proposal says good bye to the "inline" notion for combobox from Matt King on 2016-02-18 (public-aria@w3.org from February 2016)

From: Matt King <a11ythinker@gmail.com>
Date: Wed, 17 Feb 2016 16:59:18 -0800
To: "'Bryan Garaventa'" <bryan.garaventa@ssbbartgroup.com>
Cc: "'ARIA Working Group'" <public-aria@w3.org>
Message-ID: <015a01d169e7$98aea800$ca0bf800$@Gmail.com>
Bryan, one point I don’t understand is why ALL implementation patterns for combobox have to support aria-activedescendant. 

 

Is there a problem with having a particular implementation pattern where aria-activedescendant is not useful? We have other properties where applicability depends on factors other than the role.

 

Matt King

 

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

 

Well, I think this is a very valid concern, because if we say role=combobox ‘supports’ Dialog, it is subject to the following in the spec:

 

To be  <https://www.w3.org/TR/wai-aria-1.1/#dfn-keyboard-accessible> keyboard accessible, authors SHOULD manage focus of descendants for all instances of this  <https://www.w3.org/TR/wai-aria-1.1/#dfn-role> role, as described in Managing Focus <https://www.w3.org/TR/wai-aria-1.1/#managingfocus> .

 

Where it then states in Managing Focus:

 

When the container or its active descendant has focus, the user may navigate through the container by pressing additional keys, such as the arrow keys, to change the currently active descendant. Any additional press of the main navigation key (generally the TAB key) will move out of the container to the next widget.

 

And role=combobox has always supported aria-activedescendant as an option for managing focus within a Combobox.

 

So if we are going to say that a specific role supports another role, then the supported role needs to be conceptually compatible with the originating role, and for me, Combobox supporting Dialog is not, because it is impossible to manage focus like this using aria-activedescendant from role=combobox.

 

I also don’t see how this discussion is strictly limited to Combobox. What happens if role=searchbox spawns a Dialog, or role=link, or role=button, or role=checkbox, or the same on all of them?

 

Why is this case different from all of these other roles?

 

From: Rich Schwerdtfeger [mailto:richschwer@gmail.com] 
Sent: Wednesday, February 17, 2016 12:25 PM
To: Cynthia Shelly <cyns@microsoft.com <mailto:cyns@microsoft.com> >
Cc: Bryan Garaventa <bryan.garaventa@ssbbartgroup.com <mailto:bryan.garaventa@ssbbartgroup.com> >; Matt King <a11ythinker@gmail.com <mailto:a11ythinker@gmail.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

 

Well except that Matt wants it to launch a dialog box and if the tab ring is not working the user will be lost in the weeds. 

Sent from my iPhone


On Feb 17, 2016, at 11:38 AM, Cynthia Shelly <cyns@microsoft.com <mailto:cyns@microsoft.com> > wrote:

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 -
Received on Thursday, 18 February 2016 00:59:56 UTC