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

Rich,

 

I do not recall saying that I had already spoken with AT vendors about combobox. I believe I said that I am prepared to do so. You may be thinking about a different issue related to grids that I did discuss with some of the screen reader developers.

 

At any rate, I think these 4 points are primarily authoring concerns that fall into the realm of the APG rather than the spec.

 

Based on what you wrote, I do not see a request to modify the spec text that is currently in the mck-action1490 branch. Please let me know if I have not correctly interpreted any of the following.

 

Rich wrote:

>1. Whatever the combobox launches it must be housed in a modal container. If a user could tab out they would be completely lost. 

> So, if we opened a grid and you could tab out the person would be totally lost. 

 

In ARIA 1.0 comboboxes, the most common behavior upon tabbing out of the popup list is to accept the value that is currently selected/focused in the popup list. I could imagine authors providing the same behavior if the popup is a grid or tree. However, I agree that the user would be really lost if tabbing exited a dialog and pushed a value into the combo input. That wouldn’t be consistent with modal dialog design. And, I agree that it is difficult to imagine how the UX would be very good if you had a combobox that popped up a non-modal dialog.

 

Nonetheless, this seems like something that should be addressed in the APG, not in the spec. Do you agree?

 

>2. Knowing what you are selecting to fill in the combobox is critical. One of the options was to launch a tree. 

>It could not be a multi-selectable tree or listbox as that is really confusing.

 

This is a potential concern with the ARIA 1.0 text as well; it is not a new issue.

 

I think this is also something the APG could address. I see it as a potential concern, but not one that is empirically certain. It is not impossible to imagine a combobox that accepts multiple discrete values as its input. Perhaps that is why ARIA 1.0 didn’t address it. Or perhaps, it was an omission.

 

Do you agree this is an APG issue?

 

>3. What happens when you bring up a dialog box and you launch another dialog box? This could get very confusing.

 

I agree that this is often confusing and something that should be avoided. But, I do not think this issue is unique to dialogs that open from a combobox, and I am not sure this is an issue that disproportionately impacts people with disabilities.

 

I do not see anything in the spec text for dialog or the APG dialog design pattern that addresses this potential concern. It seems to me like this is beyond the scope of either document. Do you agree?

 

 >4. We must tell AT vendors what key gets out of the pop-ups. Otherwise, it is totally confusing. 

 

Indeed, but this not a spec issue, right? ARIA 1.0 does not specify keyboard interfaces. We do this in the APG.

 

The current conventions are escape for cancelling and enter for accepting. This will work equally well for listbox, tree, or grid.

 

In the case of dialog, however, the AT can process it like any other modal dialog. When it closes, regardless of the mechanism, focus returns to the input.

 

Do you agree this falls within the scope of the APG and not the spec text for combobox?

 

Best,

Matt

 

From: Rich Schwerdtfeger [mailto:richschwer@gmail.com] 
Sent: Monday, February 8, 2016 1:50 PM
To: Bryan Garaventa <bryan.garaventa@ssbbartgroup.com>
Cc: 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

 

I should have stated that the modal issue is more than preventing tabbing out. The widget has to suppress keystrokes from going elsewhere when the popup is up. 

Rich Schwerdtfeger

 

 

 

On Feb 8, 2016, at 3:45 PM, Rich Schwerdtfeger <richschwer@gmail.com <mailto:richschwer@gmail.com> > wrote:

 

I followed up with Freedom Scientific today. Matt had indicated that he had spoken to the AT vendors but they had no recollection of speaking with Matt, regarding combobox, so they were very glad I raised the combobox issue up with them.

 

Here are the key issues that were raised:

 

1. Whatever the combobox launches it must be housed in a modal container. If a user could tab out they would be completely lost. So, if we opened a grid and you could tab out the person would be totally lost. 

2. Knowing what you are selecting to fill in the combobox is critical. One of the options was to launch a tree. It could not be a multi-selectable tree or listbox as that is really confusing.

3. What happens when you bring up a dialog box and you launch another dialog box? This could get very confusing. 

4. We must tell AT vendors what key gets out of the pop-ups. Otherwise, it is totally confusing. 

 

It does not appear that this was fully vetted by AT vendors as I would imagine NVDA and AISquared would have similar concerns and these were not raised on our call. 

 

Rich

 

Rich Schwerdtfeger

 

 

 

On Feb 8, 2016, at 9:42 AM, Bryan Garaventa <bryan.garaventa@ssbbartgroup.com <mailto:bryan.garaventa@ssbbartgroup.com> > wrote:

 

“I do not think such a combobox is fully accessible. Screen reader users are missing important information. If a list is displayed, and pressing up/down arrow keys is moving a visual indicator in that list, then a screen reader user should be aware of the list and be able to know the position of the indicator in that list. Hiding the presence of the list from screen reader users by keeping the focus in the textbox is not providing equivalent functionality.”

 

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(Simulated,%20Readonly)/demo.htm

 

 

From: Matt King [mailto:mck@fb.com] 
Sent: Sunday, February 07, 2016 11:31 PM
To: Bryan Garaventa <bryan.garaventa@ssbbartgroup.com>; Richard Schwerdtfeger <richschwer@gmail.com <mailto:richschwer@gmail.com> >
Cc: ARIA Working Group <public-aria@w3.org <mailto:public-aria@w3.org> >
Subject: ACTION-1490 proposal says good bye to the "inline" notion for combobox

 

Bryan Garaventa wrote:

>when a Combobox is marked up with aria-autocomplete=’inline’ as an example, where the inline value may be changing as the user presses the arrow keys.

 

I do not think such a combobox is fully accessible. Screen reader users are missing important information. If a list is displayed, and pressing up/down arrow keys is moving a visual indicator in that list, then a screen reader user should be aware of the list and be able to know the position of the indicator in that list. Hiding the presence of the list from screen reader users by keeping the focus in the textbox is not providing equivalent functionality. I addressed this in action 1490 by simplifying the meaning of aria-autocomplete.

 

I believe one of the keys to eliminating the massive confusion around combobox is to stop overloading aria-autocomplete. The proposal is that  is to let aria-autocomplete describe just one thing -- the behavior of the input field when the focus is in the input field and the user is typing. As I mentioned in my earlier note about action 1490, the mck-action1490 branch includes changes to the definitions of the values of aria-autocomplete to achieve this objective. And, it also makes a complementary change to the aria-autocomplete guidance in the combobox role.

 

In a combobox, if characters appear after the caret when typing, then authors should set aria-autocomplete to “both”. That is, the completion is appearing in both the textbox and the list.

 

In a combobox, if characters do not appear after the caret when typing, then authors should set aria-autocomplete to “list”. That is, the completion appears only in the list and “autocompletion” will happen only if the user chooses a value from the list.

 

In a combobox, when up/down arrow keys are pressed, focus should be in the list associated with a combobox. Then, from an ARIA perspective, it does not matter at all whether the input value is changing at the same time. The author may or may not want to do that; it makes no difference.

 

Further, for combobox, aria-autocomplete would never be “none” or “inline”. The “inline” value would be used in a textbox that provides autocomplete but does not display a list.

 

This simplification paves the way for the possibility of ARIA 2.0 to make aria-autocomplete a Boolean that is more closely aligned with HTML autocomplete. More importantly, aria-autocomplete is clearly describing a single UI behavior instead of being overloaded with a wide variety of context-dependent meanings that make it difficult to apply and utilize.

 

Matt

 

 

From: Bryan Garaventa [ <mailto:bryan.garaventa@ssbbartgroup.com> mailto:bryan.garaventa@ssbbartgroup.com] 
Sent: Sunday, February 7, 2016 5:23 PM
To: Richard Schwerdtfeger < <mailto:richschwer@gmail.com> richschwer@gmail.com>
Cc: Matt King < <mailto:a11ythinker@gmail.com> a11ythinker@gmail.com>; ARIA Working Group < <mailto:public-aria@w3.org> public-aria@w3.org>
Subject: RE: ACTION-1490 Updated combobox branch based on Feb 4 ARIA caucus discussion

 

The Value on the HTML input+type=’text’ is no problem, since this is automatically exposed as part of the native control type.

 

You can see the same thing by adding role=”spinbutton” on a standard input+type=’text’ field, where the value of that element will automatically map to the Value property in the accessibility tree.

 

Similarly, in the case of a Spinbutton, the following markup actually does map correctly to the Value property in the accessibility tree as well. (Verified in Firefox and Chrome)

 

<span tabindex="0" aria-label="Choose Time" role="spinbutton" aria-valuetext="12:00 PM" aria-valuemin="0" aria-valuemax="24" aria-valuenow="13" aria-readonly="true">

<span id="valueChild">12:00 PM</span>

</span>

 

Where the Name is “Choose Time, and the Value is “12:00 PM”.

 

I agree that in real world examples the labels would be visible, but this same issue will occur even when using aria-labelledby.

 

So, in the case of the Spinbutton, when the Value property changes, it causes an event to fire so that ATs can do something with this new value. This is the same behavior that we see on Slider controls too, so that the new string can be announced by screen readers for example.

 

Here is where role=’combobox’ differs, in that there is no way to do the same as shown above for the Spinbutton, to set an explicit Value in the accessibility tree for ATs to do something with, which comes into play when a Combobox is marked up with aria-autocomplete=’inline’ as an example, where the inline value may be changing as the user presses the arrow keys.

 

Also, the problem with relying on inline content for this purpose, is that it doesn’t take into account that some implementations may render the referenced Listbox control within the same container that includes role=’combobox’ and use CSS to float this near the control that has focus, which would then cause the Value property to include all of the values at the same time, which would be really confusing.

 

From: Richard Schwerdtfeger [ <mailto:richschwer@gmail.com> mailto:richschwer@gmail.com] 
Sent: Friday, February 05, 2016 4:18 PM
To: Bryan Garaventa < <mailto:bryan.garaventa@ssbbartgroup.com> bryan.garaventa@ssbbartgroup.com>
Cc: Matt King < <mailto:a11ythinker@gmail.com> a11ythinker@gmail.com>; ARIA Working Group < <mailto:public-aria@w3.org> public-aria@w3.org>
Subject: Re: ACTION-1490 Updated combobox branch based on Feb 4 ARIA caucus discussion

 

So, isn’t the value simply exposed through the accessibility api? Do you need a value? I am pretty sure the contents of the input field are exposed. 

 

In the second example we could change the spec. or what might work would be to include namefrom content. 

 

Where you would:

 

<p id=“foo">Choose language:</a>

 

<span id=“baz” tabindex="0" aria-labelledby=“foo baz" class="button" role="combobox" aria-expanded="false" aria-activedescendant="" aria-autocomplete="list" aria-readonly="true">

<span id="langChild">English</span>

<sup id="arrowSymbolId" aria-hidden="true">?</sup>

</span>

 

If you really need a label on the combobox it should be visible to everyone. in this case you should see an accessible name of "Choose language: ?"

 

 

 

On Feb 5, 2016, at 1:09 PM, Bryan Garaventa < <mailto:bryan.garaventa@ssbbartgroup.com> bryan.garaventa@ssbbartgroup.com> wrote:

 

As requested during the meeting as well, I wish to elaborate on the need for adding an attribute for setting a Value property in the accessibility tree. Below are two examples that show why this discrepancy is important.

 

Here is an example of a Combobox control on a standard input element, which if you examine the Name in the accessibility tree, you will see that the Name reflects the aria-label attribute value according to the naming calculation, and the Value property reflects the value of the input field.

 

<input aria-label="Search for author" name="author-input-value" role="combobox" aria-expanded="false" aria-autocomplete="list" type="text" value="Bill Bryson" />

 

Now, do the same using the following example of a simulated readonly Combobox as pasted below, and you will see that the Name is set correctly in the accessibility tree, but there is no evidence of a Value in the accessibility tree, nor is there any way to assign one.

 

<span tabindex="0" aria-label="Choose language" class="button" role="combobox" aria-expanded="false" aria-activedescendant="" aria-autocomplete="list" aria-readonly="true">

<span id="langChild">English</span>

<sup id="arrowSymbolId" aria-hidden="true">?</sup>

</span>

 

Both are valid, however the second is not possible to fully map correctly in the accessibility tree. This is why I propose adding aria-valuetext as a supported attribute for role=”combobox”.

 

 

From: Rich Schwerdtfeger [ <mailto:richschwer@gmail.com> mailto:richschwer@gmail.com] 
Sent: Friday, February 05, 2016 10:53 AM
To: Matt King < <mailto:a11ythinker@gmail.com> a11ythinker@gmail.com>
Cc: ARIA Working Group < <mailto:public-aria@w3.org> public-aria@w3.org>
Subject: Re: ACTION-1490 Updated combobox branch based on Feb 4 ARIA caucus discussion

 

Thank you Matt. This is better. 

 

I am running these by Freedom Scientific. 

 

One observation is that you have added a reference to the ARIA authoring practices guide in a number of places. This is a non-normative spec. for which we have linked to and it can change. Would it not be better to put a more global reference to it in the ARIA specification?  I am sure there are other places where we could reference the ARIA authoring practices and do not. 

 

Rich

 

Rich Schwerdtfeger

 

 

 

On Feb 4, 2016, at 6:11 PM, Matt King < <mailto:a11ythinker@gmail.com> a11ythinker@gmail.com> wrote:

 

Based on today's lively discussion, I have revised my proposal for action 1490[1], which  is in branch mck-action1490[2].

 

The revisions include:

1. Remove implicit value of aria-orientation for combobox.

2. Remove combobox note about XForms.

3. Change combobox aria-autocomplete authoring requirements to state that aria-autocomplete be set to either "both" if autocomplete is provided in the textbox or "list" if it is not.

4. Restored token values for aria-autocomplete and clarified their definitions.

 

As previously described, the objectives of action 1490 are:

1. Allow combobox to popup grid, tree, and dialog in addition to listbox.

2. Allow aria-controls instead of aria-owns so the pop-up is not a child of the single line text input. This enables screen readers to include a rendering of the pop-up outside of the text input in their reading view or buffer.

3. Remove ambiguities from the spec to improve understanding and simplify authoring.

4. Do it all without breaking any existing implementations.

 

Note: the changes included in action 1490 have little or no effect on browser implementations and require only minor adjustments in the logic of some screen readers to support the aria-controls relationship when processing the escape key.

 

The changes in the mck-action1490 branch (as compared to master) are:

1. Reworded the combobox definition.

2. Added normative statement saying the popup must be one of listbox, tree, grid, or dialog.

3. Added normative MUST statement requiring authors to associate the input with the pop-up.

4. Specified that authors SHOULD use aria-controls but MAY use aria-owns to specify the relationship between the input and the popup.

5. Added normative author MUST statement requiring correct use of aria-expanded.

6. Reworded and simplify the focus management language.

7. Eliminated confusing language about aria-autocomplete and specified that authors SHOULD use either "both" if the text input provides suggestions or "list" if it does not.

8. Updated the example code to match the new authoring requirements.

9. Added a reference to the APG.

10. Changed the superclass to input.

11. Remove the required owned elements.

12. Clarified the value definitions for aria-autocomplete.

 

[1] Action 1490:  <https://www.w3.org/WAI/aria/track/actions/1490> https://www.w3.org/WAI/aria/track/actions/1490

 

[2] mck-action1490 branch:  <http://rawgit.com/w3c/aria/mck-action1490/aria/aria.html> http://rawgit.com/w3c/aria/mck-action1490/aria/aria.html