W3C home > Mailing lists > Public > public-aria@w3.org > February 2016

RE: ACTION-1490 Updated combobox branch based on Feb 4 ARIA caucus discussion

From: Bryan Garaventa <bryan.garaventa@ssbbartgroup.com>
Date: Mon, 8 Feb 2016 01:23:03 +0000
To: Richard Schwerdtfeger <richschwer@gmail.com>
CC: Matt King <a11ythinker@gmail.com>, ARIA Working Group <public-aria@w3.org>
Message-ID: <SN1PR0301MB1981C1558B0027E788F5F24398D50@SN1PR0301MB1981.namprd03.prod.outlook.com>
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>

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>
Cc: Matt King <a11ythinker@gmail.com>; ARIA Working Group <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>

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>

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 Schwerdtfeger

On Feb 4, 2016, at 6:11 PM, Matt King <a11ythinker@gmail.com<mailto: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

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

Received on Monday, 8 February 2016 01:23:38 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 24 March 2022 20:23:19 UTC