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] 
Sent: Sunday, February 7, 2016 5:23 PM
To: Richard Schwerdtfeger <richschwer@gmail.com <mailto:richschwer@gmail.com> >
Cc: Matt King <a11ythinker@gmail.com <mailto:a11ythinker@gmail.com> >; ARIA Working Group <public-aria@w3.org <mailto: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] 
Sent: Friday, February 05, 2016 4:18 PM
To: Bryan Garaventa <bryan.garaventa@ssbbartgroup.com <mailto:bryan.garaventa@ssbbartgroup.com> >
Cc: Matt King <a11ythinker@gmail.com <mailto:a11ythinker@gmail.com> >; ARIA Working Group <public-aria@w3.org <mailto: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 <bryan.garaventa@ssbbartgroup.com <mailto: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] 
Sent: Friday, February 05, 2016 10:53 AM
To: Matt King <a11ythinker@gmail.com <mailto:a11ythinker@gmail.com> >
Cc: ARIA Working Group <public-aria@w3.org <mailto: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