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

Bryan wrote:
> When focus is kept on the element that includes role=combobox however, 
> and uses aria-activedescendant to manage focus in the accessibility tree when the arrow keys are pressed, 
> then this paradigm is in conflict with the native editing capability of standard Comboboxes, 
> because you need to be able to use the Left/Right arrow keys to navigate the characters that have been entered within that edit field, 
> regardless whether the Combobox controled component is rendered or not. 
> So any control type that uses Left/Right for this functionality such as Tree and Grid directly contradict this behavior when focus remains on the Combobox.

The choice of how various keys behave, including left/right,  is a design decision. The choice of whether or not to use aria-activedescendant is an implementation decision. Isn't it the case that You could create either behavior of left/right with or without aria-activedescendant?

As you point out, if the popup were a tree or multi-column grid, then left/right could not change the caret position in the text field if the "visual" focus is in the popup. The author would need to employ other common conventions for returning the "visual" focus to the text input field, such as Enter, Escape, Up from the first popup element, or alt+up. Just like typical comboboxes made of a text input and listbox, the author can implement these types of interaction models with or without aria-activedescendant.

I used the term "visual" focus to mean either type of focus:
A. * DOM focus if aria-activedescendant is not present 
B. focus created by aria-activedescendant.

Matt

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

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

The problem here is the misconception that focus is always moved into the associated control, which is not the case.

It's true that if you move focus away from the element with role=combobox, you can put focus into any other control type such as a Listbox, Tree, or Grid with no problem, arrow to the option you want and press Enter to make your selection and return focus back to the Combobox.

When focus is kept on the element that includes role=combobox however, and uses aria-activedescendant to manage focus in the accessibility tree when the arrow keys are pressed, then this paradigm is in conflict with the native editing capability of standard Comboboxes, because you need to be able to use the Left/Right arrow keys to navigate the characters that have been entered within that edit field, regardless whether the Combobox controled component is rendered or not. So any control type that uses Left/Right for this functionality such as Tree and Grid directly contradict this behavior when focus remains on the Combobox.

This is important, because when aria-activedescendant is set on role=combobox, it causes the focusable element to change in the accessibility tree to point to whatever element is being pointed to, making it appear to ATs that this referenced element is the one that has focus, even though this is not actually true in the DOM.

You can test this at
http://whatsock.com/tsg/Coding%20Arena/ARIA%20Comboboxes/ARIA%20Comboboxes%20(Native%20Inputs,%20Editable%20and%20Readonly)/demo.htm

Tab down to the State field, type ‘c’, and check the accessibility tree to see which control has focus, and you will see this is the Combobox. However, when you press the Down arrow to cause aria-activedescendant to be set, you will see that now the accessibility tree shows that the Option node for California has focus, even though actual keyboard focus has never left the role=combobox element.

E.G When you check the Value property for the focused control before aria-activedescendant is set, you will see ‘c’ as the value. However if you do the same after aria-activeDescendant is set, you will see that there is no Value property in the accessibility tree because the focused element appears to now be the Option node instead.

This is why this contradiction is such an issue, and why it is necessary to clear aria-activedescendant on editable Combobox controls when the Left/Right keys are pressed so that the accessibility tree shows that the Combobox is the control that has focus, and not whatever aria-activedescendant is pointing to.

If you use BX, you can verify this in the MSAA or UIA maps by pressing Control+F to set focus to the control that has focus in the accessibility tree.

-----Original Message-----
From: Matt King [mailto:a11ythinker@gmail.com] 
Sent: Sunday, February 14, 2016 9:53 AM
To: 'Richard Schwerdtfeger' <richschwer@gmail.com>; 'Joseph Scheuhammer' <clown@alum.mit.edu>
Cc: Bryan Garaventa <bryan.garaventa@ssbbartgroup.com>; 'ARIA Working Group' <public-aria@w3.org>
Subject: 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 Wednesday, 17 February 2016 10:04:08 UTC