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

OK.
Hmmm… I really wouldn’t call that a combobox. I can see how it has some characteristics of a combobox, but it seems like a whole other thing to me. That’s probably the core of our disagreement. Would it work if it just had aria-controls pointing to the popup and aria-haspopup, and didn’t use the combobox role?

It doesn’t have the keyboard behavior of a combobox: focusing it and hitting down arrow doesn’t go to the first thing in the list, typing and hitting enter doesn’t present the list of options filtered by what I typed.

That aside, I can see why the search dialog is modal, but it doesn’t seem like part of the combobox. I was completely surprised when typing and hitting enter brought up a dialog. That’s not what comboboxes do, and it looks like a combobox. I didn’t expect that from a thing that looked like a combobox. The same thing happened even when I typed something that was in the list, which is not what comboboxes do.

The dialog can be brought up by clicking the “search” button. That was closer to what I expected, and felt like a fancy combobox. In that case, it closed the combobox, which was what I expected.

I’m curious about the container that has the list/grid and search button in it. Are you thinking of that as a dialog too? Or as a list with a special option that has the search button? It’s not modal, and that makes sense to me.


From: James Nurthen [mailto:james.nurthen@oracle.com]
Sent: Friday, February 12, 2016 4:56 PM
To: public-aria@w3.org
Subject: Re: ACTION-1490 proposal says good bye to the "inline" notion for combobox

Cynthia,
Here is an example.
http://jdevadf.oracle.com/adf-richclient-demo/faces/components/inputComboboxListOfValues.jspx


The Component has a list where you can select data from a grid (note: we should change this to table in the future now we have an aria role of table) as well as a search link which takes you to a dialog where you can do a more complex search.

Regards,
James
On 2/12/2016 4:45 PM, Cynthia Shelly wrote:
Sorry I’m late to the thread. I’ve been digging through this, HTML 5 datalist, and some implementation discussions with my team.

Bryan raises some good points.
Opening a dialog from a combobox seems bizarre to me. Do you have an example of a UI that does that? To me, that’s not a combobox. That’s (maybe) a button that opens a dialog. A combobox is a <em>combo</em> of a text <em>box</em> and a list.  Sometimes, they’re read-only, like the HTML Select element.  I can sort of see the grid and tree as extensions of that model, but not dialog.

Search autocompletes sometime use aria-controls with aria-activedescendant (often aria-owns too). I don’t see why this is a problem.

A modal combobox also seems bizarre to me. A combobox is a fairly simple control. When you tab out of one, it closes, and you go to the next control on the page. This has been true since the earliest versions of Windows (I assume other platforms too). Why does it suddenly need to be modal?

On the auto-complete question, I think the most confusing thing is that we’re using the term auto-complete for two very different things. Autocomplete=inline is an automatic completion of the text being typed. Autocomplete=list is something that we call an “auto-suggest.” They often coexist, but they don’t have to, and they’re quite different. What if we took a page from the html5 book, and had something similar the this @list attribute pointing to the datalist.  This is similar to aria-controls (we actually map it to the same thing in UIA) but is more clear from an authoring perspective. So, you could have something like this

<div role=textbox content-editable=true aria-autosuggest=foo></div>
<div id=foo role=listbox>
<div role=listitem>
…
</div>

That’s pretty much the same as
<input type=text list=foo>
<datalist id=foo>
<option>
  …
</datalist>


We could call it aria-autosuggest or aria-list. Thoughts?

From: Bryan Garaventa [mailto:bryan.garaventa@ssbbartgroup.com]
Sent: Thursday, February 11, 2016 1:37 PM
To: Rich Schwerdtfeger <richschwer@gmail.com><mailto:richschwer@gmail.com>; Joseph Scheuhammer <clown@alum.mit.edu><mailto:clown@alum.mit.edu>
Cc: 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

“Here "descendants" means either a DOM descendant of the container, or one referenced by aria-owns.  This procedure won't succeed for combobox containers if aria-controls is used instead of aria-owns.”

This is the part that is confusing me, because it already works, I’ve tested this in IE11, Firefox, Chrome using JAWS and NVDA and it works accessibly, and the same implementation is accessible in iOS using VoiceOver in Safari.

I get that in the browser you are referring to the mappings, but the web is a weird place, and there are many instances that involve relationships like this that are not necessarily good to represent as trapped modals or as requisite children.

E.G a search field that dynamically updates a region of the page as you type into it, that can announce the first result that is matched while also allowing you to use Up/Down to scroll through the results while leaving focus on the search field. The user will not want to be trapped and to be unable to read the rest of the page if they desire to.

This currently works accessibly using the method I’ve described here, but will be practically useless if trapped in the manner you are describing.

So if the implementation I’ve got here is incorrect, regardless that it is already provably accessible, what will changing it accomplish, and what specifically needs to be changed?

I also am having a hard time understanding the relationship of triggering a dialog from a combobox.

E.G If you are typing into a combobox, at what point would you be navigating a dialog? How could you read back what you have typed if focus is then trapped in a dialog?


From: Rich Schwerdtfeger [mailto:richschwer@gmail.com]
Sent: Thursday, February 11, 2016 1:03 PM
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

using aria-activedescendant for aria-controls would be hugely bad. Think live regions where a checkbox controls the content of the live region.


Rich Schwerdtfeger



On Feb 11, 2016, at 2:10 PM, Joseph Scheuhammer <clown@alum.mit.edu<mailto:clown@alum.mit.edu>> wrote:

Hi Bryan,

On 2016-02-11 1:03 PM, Bryan Garaventa wrote:
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.

There may still be a problem -- I am investigating.  The Core-AAM describes an algorithm associated with aria-activedescendant that user agents MUST execute in order to mark the potential active descendants as focusable.  In summary, when the user agent encounters a container with an aria-activedescendant attribute, the user agent must visit all descendants of the container and determine if they could be the target of the container's aria-activedescendant.  The user agent must expose a focusable state for each such target, and only for those descendants that are targets.

Here "descendants" means either a DOM descendant of the container, or one referenced by aria-owns.  This procedure won't succeed for combobox containers if aria-controls is used instead of aria-owns.

A way to patch this is to run the exact same algorithm but base it on aria-controls if aria-owns is not used.  However, that requires buy-in from all user agents, and tests cases for the ARIA test harness.


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?

Matt's new definition of combobox includes drop-downs that contain a grid, a treegrid, or a dialog instead of a listbox.  When Rich discussed this with Freedom Scientific, they were willing to handle such cases, but only if the drop-down was modal.  The thread starts here:
https://lists.w3.org/Archives/Public/public-aria/2016Feb/0151.html


--
;;;;joseph.

'Die Wahrheit ist Irgendwo da Draußen. Wieder.'
                - C. Carter -


--
Regards, James

[Oracle]<http://www.oracle.com/>
James Nurthen | Principal Engineer, Accessibility
Phone: +1 650 506 6781<tel:+1%20650%20506%206781> | Mobile: +1 415 987 1918<tel:+1%20415%20987%201918> | Video: james.nurthen@oracle.com<mailto:james.nurthen@oracle.com>
Oracle Corporate Architecture
500 Oracle Parkway | Redwood Cty, CA 94065
[Green              Oracle]<http://www.oracle.com/commitment>Oracle is committed to developing practices and products that help protect the environment