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

Thanks, I had some time to play with this. For those who use JAWS, you can press ‘e’ to jump to the first edit field where this field is located on the test page.

Personally I think we are getting mired in styling versus functionality, where, though it may look like a combobox, it doesn’t intuitively act like one.

I see what you mean by pressing Alt+Down to open the Grid, though this actually doesn’t work when JAWS is running. You need to press Insert+Escape before pressing Alt+Down in order to get the Grid to load and for focus to then move to this location. This would need to support the Down arrow by itself as well in order to allow this to work for JAWS users as well in IE11 for instance.

Even so, this functionality doesn’t really constitute a Combobox, because when focus moves into the Grid, you are interacting with a Grid and not a Combobox. This is actually okay and to be expected though, because an AT can only interface with the element that has focus. This same technique would work if this was a Tree or a Listbox as well, though the user would still need some sort of hint via aria-describedby to convey that this functionality existed.

This technique would not work however if you kept focus on the element that uses role=combobox, and then used aria-activedescendant to control which role=gridcell was being referenced, because when interacting with an editable Combobox, you need to be able to use the Left/Right arrow keys to navigate the text characters in the edit field, and Up/Down to control which option is highlighted, so the Grid metaphor of using Left/Right at the same time is contradictory to this capability. The same is true for Tree, where Left/Right is needed to collapse or expand branch nodes, which cannot be done at the same time as editing the characters in an edit field.

Similarly, when typing into the edit field and pressing Tab, the fact that a dialog opens doesn’t fit a combobox paradigm either, because you have essentially left the Combobox control at that point and are interacting with a different component type, regardless that one is spawned by what is typed into the other.

The way that a Combobox works accessibly is that the role=combobox control defines the role of combobox, aria-autocomplete conveys that it has autocomplete capability, it conveys its expanded or collapsed state using aria-expanded and toggles this between ‘false and ‘true’ accordingly as the user interacts with it, and either moves focus into the referenced control for focus management or uses aria-activedescendant to point to the referenced option when the Up/Down arrow keys are used to switch between listed options. When this is programmed correctly, including the clearing of aria-activedescendant when the Left/Right arrow keys are used to navigate which characters have been typed into the edit field, all of these things actually work as they are mapped.

Personally I do think this can be made to work more accessibly using what we already have, and I think it would be a mistake to redesign all API mappings for Combobox controls to restrict modal dialog functionality and enforce children where this would likely break most implementations that can already be proven to work as they currently exist.

It seems like a simple matter to ensure an explicit association for controls such as these using aria-controls, that would not adversely impact the accessibility tree structure where the referenced structure may include additional active elements that are not compatible as a nested parent/child relationship within one active element such as this.

So basically, I do think we need better design patterns to cover implementations such as these, but I don’t see this as being too difficult as is using the API mappings that we already have for this purpose.






From: James Nurthen [mailto:james.nurthen@oracle.com]
Sent: Friday, February 12, 2016 7:51 PM
To: Bryan Garaventa <bryan.garaventa@ssbbartgroup.com>; public-aria@w3.org
Subject: Re: ACTION-1490 proposal says good bye to the "inline" notion for combobox

The input (<input name="dmoTpl:idInputComboboxListOfValues" class="xer" id="dmoTpl:idInputComboboxListOfValues::content" role="combobox" aria-describedby="dmoTpl:idInputComboboxListOfValues::desc" type="text" value="Blake3">)  is the triggering element. You can open the "combo box" with Alt+Down Arrow. In this case this will launch an aria dialog but visually it looks like a combo box with a grid at the top and a search link underneath.

If you just type a partial value in the combobox field it will not complete from the list but instead pop open the same dialog which would otherwise be launched if you pressed the Search.... link in the original popup.

This may seem complex but controls like these are needed for applications where you need to search across multiple DB fields in order to find a value.

The other button (<button class="p_AFHoverTarget x7j p_AFTextOnly" id="dmoTpl:popupButton" aria-haspopup="true" onclick="return false;" data-afr-fcs="true">Show inputComboboxListOfValues in a popup</button>) simply launches a dialog which contains a similar combo box from which you can perform the same operation.

Regards,
James
On 2/12/2016 5:34 PM, Bryan Garaventa wrote:
Hi James,
Can you explain how to use the control, or where to enter sample data for the demo? I’m having trouble locating the control that is meant by a Combobox.

I see the following two triggering elements:

<input name="dmoTpl:idInputComboboxListOfValues" class="xer" id="dmoTpl:idInputComboboxListOfValues::content" role="combobox" aria-describedby="dmoTpl:idInputComboboxListOfValues::desc" type="text" value="Blake3">

When I enter data into it though, I can’t tell what should be happening, or if specific text needs to be entered to trigger this.

I also see the following triggering element:

<button class="p_AFHoverTarget x7j p_AFTextOnly" id="dmoTpl:popupButton" aria-haspopup="true" onclick="return false;" data-afr-fcs="true">Show inputComboboxListOfValues in a popup</button>

And yes, this does trigger a dialog, but I wouldn’t conceptually think of this button as a combobox.

Please let me know if I’m looking at the wrong controls.

Thanks,
Bryan


From: James Nurthen [mailto:james.nurthen@oracle.com]
Sent: Friday, February 12, 2016 4:56 PM
To: public-aria@w3.org<mailto: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

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