W3C home > Mailing lists > Public > public-aria@w3.org > February 2016

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

From: Rich Schwerdtfeger <richschwer@gmail.com>
Date: Thu, 11 Feb 2016 14:58:43 -0600
Cc: Joseph Scheuhammer <clown@alum.mit.edu>, Matt King <mck@fb.com>, ARIA Working Group <public-aria@w3.org>
Message-Id: <DFF2D8D1-3553-4226-91D2-82381BA25B79@gmail.com>
To: Bryan Garaventa <bryan.garaventa@ssbbartgroup.com>
The modal part is very important. 

If you were to include a grid in a web page you can tab out of it. You don’t want that happening with a combobox in this context or definitely not in a dialog box. The popup needs to be associated with the combobox. Yet, it can’t be owned. We don’t want the user navigating in at dialog box associated with a combobox as you would actually be tabbing inside the dialog box anyway. We don’t want the user tabbing out. If we want to associate other widgets with the combobox we need to be consistent here as well. 

Also, as Joseph points out we can’t use aria-activedescendant in a combobox if we have an object associated via aria-controls as it is indeed not a descendant. 

To make things easier on the user the only way we should allow the user to get out of the combobox popup is via an escape. This is why I think whatever container we put the listbox, etc. in we make it modal. We also have to make it clear that aria-activedescendant will not work with an aria-controls relationship to the popup as it will not be a descendant. 


Rich Schwerdtfeger




> On Feb 11, 2016, at 12:03 PM, Bryan Garaventa <bryan.garaventa@ssbbartgroup.com> wrote:
> 
> 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 20:59:12 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 24 March 2022 20:23:19 UTC