- From: Bryan Garaventa <bryan.garaventa@ssbbartgroup.com>
- Date: Thu, 11 Feb 2016 18:03:29 +0000
- To: Richard Schwerdtfeger <richschwer@gmail.com>, Joseph Scheuhammer <clown@alum.mit.edu>
- CC: Matt King <mck@fb.com>, ARIA Working Group <public-aria@w3.org>
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 18:04:02 UTC