Require user agents to expose a value for combobox elements

[mcking65]

This resolves the simplest use case identified by issue #711 by requiring user agents to expose a value for elements with the combobox role. This will enable combobox to be used to create a custom select.

This PR requires user agents to expose a value to assistive technologies. If the combobox element is anHTML element that has a value, user agents must expose that value. Otherwise, they expose a string that represents descendant content using methods described in accname.

The idea of using valuetext doesn't make sense in the simplest use case because it would just force authors to copy innertext into an attribute. In more complex cases, an aria-valuedby attribute could be use to specified the element or elements that provide the value. However, we can save that for ARIA 1.3; it is not essential for making a custom select.

---

💥 Error: 500 Internal Server Error 💥

PR Preview failed to build. (Last tried on Apr 15, 2020, 2:00 AM UTC).

More

PR Preview relies on a number of web services to run. There seems to be an issue with the following one:

🚨 Spec Generator - Spec Generator is the web service used to build specs that rely on ReSpec.

🔗 Related URL

Navigation timeout of 30000 ms exceeded

If you don't have enough information above to solve the error by yourself (or to understand to which web service the error is related to, if any), please file an issue.

[curtbellew]

I think this makes sense. I do wonder how this would be impacted by comboboxes that include a drop down arrow icon. In our example https://www.w3.org/TR/wai-aria-practices/examples/combobox/aria1.1pattern/listbox-combo.html#ex3_label the drop down icon is a child of the combobox and it does have an appropriate aria-label of "Show vegetable options". In this case would we run the risk of the value being calculated to be something like "Apple Show vegetable options"?

[JAWS-test]

Would it make sense to insert an analogue sentence also for textbox and searchbox?

[mcking65]

@curtbellew commented:

I think this makes sense. I do wonder how this would be impacted by comboboxes that include a drop down arrow icon. In our example https://www.w3.org/TR/wai-aria-practices/examples/combobox/aria1.1pattern/listbox-combo.html#ex3_label the drop down icon is a child of the combobox and it does have an appropriate aria-label of "Show vegetable options". In this case would we run the risk of the value being calculated to be something like "Apple Show vegetable options"?

Perfectly fine risk because ARIA 1.2 makes that a deprecated pattern that checkers will call invalid and that AT don't generally support anyway.

If browsers or AT wanted to do so, they could easily detect the 1.1 implementation and calculate the value strictly based on the value of the textbox, which is what they do now. The revised UA support statement in PR #1223 allows for this.

[mcking65]

@JAWS-test commented:

Would it make sense to insert an analogue sentence also for textbox and searchbox?

Yes. I thought about doing that in this PR but opted for a minimal approach given where we are with ARIA 1.2. I think that can wait till ARIA 1.3 when we take on the rest of #711.

However, since one of the goals of fixing combobox is to make custom selects possible, i.e., a robust equivalent of HTML:select@size=1, we really need this for ARIA 1.2.

In practice, ARIA textbox implementations are usually contenteditables, and they wouldn't be helped by this.

If the browser implementers said to go ahead and add it to textbox and searchbox now b/c it is trivial to do at the same time, then I'd be in favor.

[curtbellew]

@curtbellew commented:

I think this makes sense. I do wonder how this would be impacted by comboboxes that include a drop down arrow icon. In our example https://www.w3.org/TR/wai-aria-practices/examples/combobox/aria1.1pattern/listbox-combo.html#ex3_label the drop down icon is a child of the combobox and it does have an appropriate aria-label of "Show vegetable options". In this case would we run the risk of the value being calculated to be something like "Apple Show vegetable options"?

Perfectly fine risk because ARIA 1.2 makes that a deprecated pattern that checkers will call invalid and that AT don't generally support anyway.

If browsers or AT wanted to do so, they could easily detect the 1.1 implementation and calculate the value strictly based on the value of the textbox, which is what they do now. The revised UA support statement in PR #1223 allows for this.

Thanks for that explanation, Matt. Makes a lot of sense. I think I'm confused by the 1.2 ARIA document though. I was thinking that the document refers to the drop down icon in the following quote.
"Typically, the initial state of a combobox is collapsed. In the collapsed state, only the combobox element and an optional popup control button are visible."

[mcking65]

@curtbellew commented:

Thanks for that explanation, Matt. Makes a lot of sense. I think I'm confused by the 1.2 ARIA document though. I was thinking that the document refers to the drop down icon in the following quote.
"Typically, the initial state of a combobox is collapsed. In the collapsed state, only the combobox element and an optional popup control button are visible."

Yes, the optional popup control button would be the dropdown icon. It is not part of the combobox element; it is a sibling element.

If there is something ambiguous about that text, I'd be happy to make an editorial PR to clarify.

[cookiecrook]

Looking into this. It may be okay, but it would be a change in the way WebKit exposes these to the accessibility APIs on different platforms, so I need to double-check with the API owners.

[cookiecrook]

Trying to clarify the comments @mcking65 made on the ARIA call this morning.

I think this would result in very little change to comboboxes that use the role on native text input elements, like this:

<input type="text" role="combobox" aria-owns"my_listbox">

But it could be different on this type of variant, which we still see a lot of web authors using.

<div role="combobox" tabindex="0"> <!-- focusable parent node uses the role --> 
	<input type="text" role="textbox"> <!-- contains a textbox -->
	… listbox too...
</div>

The way I read the PR is that the text input element’s value will be reflected to the parent div node in the accessibility APIs? Is that what you intended?

Thanks for clarifying.

[aleventhal]

Are we sure this won't result in double speech in some screen readers? For example, NVDA already figures this situation out and reads the value from the combobox's child, IIRC. Aaron

…

On Thu, Apr 2, 2020 at 3:08 PM James Craig ***@***.***> wrote: Trying to clarify the comments @mcking65 <https://github.com/mcking65> made on the ARIA call this morning. I think this would result in very little change to comboboxes that use the role on native text input elements, like this: <input type="text" role="combobox" aria-owns"my_listbox"> But it could be different on this type of variant, which we still see a lot of web authors using. <div role="combobox" tabindex="0"> <!-- focusable parent node uses the role --> <input type="text" role="textbox"> <!-- contains a textbox --> … listbox too... </div> The way I read the PR is that the text input element’s value will be reflected to the parent div node in the accessibility APIs? Is that what you intended? Thanks for clarifying. — You are receiving this because your review was requested. Reply to this email directly, view it on GitHub <#1225 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAKQAZREXB5JIMVCB5FLGS3RKTPC7ANCNFSM4LUMBPVQ> .

[cookiecrook]

@aleventhal wrote:

Are we sure this won't result in double speech in some screen readers?

Not sure at all. I think it's possible this change would result in double-speak for more multiple assistive technologies.

@mcking65 wrote:

Perfectly fine risk because ARIA 1.2 makes that a deprecated pattern that checkers will call invalid and that AT don't generally support anyway.

I believe it's wishful thinking to forego this risk. The conformance checker statement is vague, and unlikely to be implemented in most checkers. Even if it is implemented by some checkers, most authors don't use accessibility-specific conformance checkers.

I'm not sure the "UAs must compute value" statement resolves anything. Whether the UA does or the AT does is an implementation detail IMO, as long as the author markup is valid.

Could this issue be moved from the Spec to the ARIA-AAM?

[jnurthen]

I think this should be deferred to 1.3 - it doesn't seem to fit with the scope of things that can go into 1.2 at this stage.

[mcking65]

cookiecrook commented:

Trying to clarify the comments @mcking65 made on the ARIA call this morning.

I think this would result in very little change to comboboxes that use the role on native text input elements, like this:

<input type="text" role="combobox" aria-owns"my_listbox">

That is correct. This PR does not change anything for implementations like this that use aria-owns, which is the 1.0 pattern. First, the combobox is made from a native input, which has a value attribute. So, the requirement is to give the combobox that value. In addition, however, this PR changes the spec to specify that UA calculate value from content only for combobox elements that implement the 1.2 pattern. If The UA were to calculate value from content for the 1.0 style implementation, that would be an error.

The 1.2 pattern changes the above by replacing aria-owns with aria-controls so there is no child content. And, since the input itself has a value, that value is the value of the combobox.

But it could be different on this type of variant, which we still see a lot of web authors using.

<div role="combobox" tabindex="0"> <!-- focusable parent node uses the role --> 
	<input type="text" role="textbox"> <!-- contains a textbox -->
	… listbox too...
</div>

This PR should not change value calculation for this code, which is invalid BTW. ARIA has never allowed a focusable parent. 1.1 allows a parent container, but it is not allowed to be focusable.

Again, this UA requirement is only for implementations of the 1.2 pattern. So, if the UA were to calculate a value from content for the above, it would be a UA error.

The 1.2 combobox is an input, not a composite. It is not permitted to have interactive descendants. So, the descendants of the above code should not be included in a value calculation.

The way I read the PR is that the text input element’s value will be reflected to the parent div node in the accessibility APIs? Is that what you intended?

I didn't have any intention that would happen, and I am happy to make whatever change necessary to clarify.

My intention is that The UA should only calculate value from content if the combobox is not an HTML text input with a value attribute and if it meets the requirements of the 1.2 specification, ie, it is a focusable element with the combobox role, it does not have any interactive or focusable descendants, and it controls a popup element with role listbox, tree, grid, or dialog. If the element with role combobox is a native input with a value attribute, that value should still be used as the combobox value.

In other words, the requirements in the 1.2 version of the spec only apply to authors implementing ARIA 1.2. If the author is using ARIA 1.1, they should only use requirements in ARIA 1.1. And, if the author is using 1.0, the Author should be following ARIA 1.0 requirements.

Similarly, the user agent should implement combobox requirements in the 1.2 specification only for combobox elements that conform to the the 1.2 specification. This is a new requirement in 1.2. I'd be happy to add some clarifying language to either the paragraph that describes this requirement or to the notes at the end after we come to consensus on #1178. Personally, I think it would be better at the end.

[mcking65]

@cookiecrook commented:

@aleventhal wrote:

Are we sure this won't result in double speech in some screen readers?

Not sure at all. I think it's possible this change would result in double-speak for more multiple assistive technologies.

If UA implement this only for 1.2 comboboxes as intended, there won't be any double speak. Check out this codepen by Sarah. (Ignore the second one with valuetext.):
https://codepen.io/smhigley/full/PoqyRdV

I'm not sure the "UAs must compute value" statement resolves anything. Whether the UA does or the AT does is an implementation detail IMO, as long as the author markup is valid.

It resolves the issue that there is no specification of who should and how should the value of a combobox be coded and computed.

in 1.0, this was also ambiguous. However, in practice, it was implicit that a combobox had to be made from an HTML text input. No one tried to do it any other way. So, browsers just picked up that value because they already did so for native html inputs.

With 1.1, combobox was required to contain a textbox, and again, that provided an implicit source of value even though the spec didn't directly address the issue of how the author should code or the user agent should compute the value.

In 1.2, a combobox does not have to be made from or contain a textbox. This finally aligns the ARIA spec with the way HTML:select@size=1 has been mapped on several platforms since the beginning of ARIA.

This alignment now makes it possible to build custom versions of HTML select with ARIA. However, we can no longer rely on accidental alignment of the stars around the way textboxes have worked in order for AT to get the value of a combobox that is not built from an HTML input. As we work on a custom select for APG, we have discovered that it is essential the spec be explicit about the source of the value.

[mcking65]

@jnurthen wrote:

I think this should be deferred to 1.3 - it doesn't seem to fit with the scope of things that can go into 1.2 at this stage.

This is a pressing issue, and I would like to urge continued effort to arrive at consensus.

This PR resolves a critical oversight in the prior combobox PR. We discovered this gap through the ARIA WG process, which includes developing practices implementations and testing them with browsers and AT.

There are many people out there who have been struggling to make custom selects that work with AT. This is the final change required to make that feasible. The value of arriving at common understanding of how to do this now is very significant.

[sinabahram]

I also would like to see this resolved in 1.2

[carmacleod]

I think it's important that we resolve this in 1.2 because I can't imagine telling people that the combobox spec is different in 1.0, 1.1, 1.2 AND 1.3 - that would just be a nightmare.

I don't know whether it belongs in the spec or the AAM.
If we are adding this to the spec, then I am fine with @mcking65's words in this PR (only one nit to fix).
Yes, there are 3 instances of UA MUST, but if we switch them to SHOULD for easier 1.2 merging, with the intent of changing to MUST in 1.3, then we are just back to the nightmare mentioned above. (I believe we have 1 implementor already - see below - and maybe @aleventhal can ensure that Chrome will implement, which would make 2).

I gathered a bit of data using @smhigley's select-only combobox example (NOTE: just the first one: "Choose a fruit, with text content") that @mcking65 mentioned.

• FF, Chrome, Edge don't set MSAA accValue or IA2 Value. UIA has ValuePattern, but Value is not set.

  • JAWS and NVDA don't say value in FF or Chrome
  • Narrator doesn't say value in Edge
  • VoiceOver doesn't say value in Chrome

• Safari doesn't show AXValue in devtools, but Accessibility Inspector does show AXValue set to combobox content.

  • VoiceOver does say value

@cookiecrook Can you confirm that Safari/WebKit is already setting the value for this combobox? (i.e. verify that Apple already conforms to the words in this PR).

@aleventhal You said:

For example, NVDA already figures this situation out and reads the value
from the combobox's child, IIRC.

Can you confirm that NVDA is not actually reading the value? I am running 2019.3.1, which I believe is the latest, and NVDA is not reading the value of this combobox in either FF or Chrome.

@joanmarie Sorry that I'm not set up to test Linux. Can you give us any data on whether or not Orca reads the value of this combobox?

[joanmarie]

@carmacleod Here are my results:

Orca master + Firefox Nightly:

• "Choose a fruit, with text content combo box. Apple. opens listbox"
• "Choose a fruit, with valuetext combo box. Apple. opens listbox"

Orca master + Chromium (locally built):

• "Choose a fruit, with text content combo box. Apple. opens listbox"
• "Choose a fruit, with valuetext combo box. Apple. opens listbox"

Orca master + Epiphany (WebKitGtk) 3.34.4:

• "Choose a fruit, with text content combo box. Apple."
• "Choose a fruit, with valuetext combo box. Apple."

So in all cases Orca is speaking "Apple".

EDIT1: Orca was double-speaking "Apple" in the case of Chromium. That is now fixed in Orca. Executive summary is that Chromium exposes static text leaf nodes that Gecko and WebKit do not. Orca works hard to ignore them but every once in a while it misses one.

EDIT2: The above is what happens when the combo box first gets focus. When you arrow within the expanded list:

• Orca DOES present the selected item in the "with text content" example.
• Orca DOES NOT present the selected item in the "with valuetext" example.

Does that answer your question? If not, please let me know. And thanks for asking!

[carmacleod]

@joanmarie Wow - is Orca being very smart and figuring the value out? Or are the nightly and locally built user agents actually making the value available? Or maybe Orca is being smart and Chromium has implemented very recently, resulting in the Chromium double-speak?

[joanmarie]

@joanmarie Wow - is Orca being very smart and figuring the value out? Or are the nightly and locally built user agents actually making the value available? Or maybe Orca is being smart and Chromium has implemented very recently?

Orca goes looking for the value/displayed text in a combobox. It always has. Because authors, differences in native toolkits, etc.

I was multi-tasking at the time I responded to your comment and had the nightly/locally-built versions running. So that's what I reported to you. 😄 But I get the same results with Firefox stable (v74.0.1) as I do with Firefox nightly. And the same results with Chrome stable (80.0.3987.162) as I do with Chromium built today.

[carmacleod]

Orca goes looking for the value/displayed text in a combobox. It always has. Because authors, differences in native toolkits, etc.

Orca is a very wise screen reader. 😄

I assume that, were the browsers to provide a value through their accessibility API, Orca would stop looking and go with that? i.e. Orca would not actually need to make any changes if browsers implement the words in this PR? (Did you figure out the double-speak? I'm assuming it's just some nit, and does not actually indicate that Chromium is providing a value... since it doesn't provide one in Windows Chrome...)

[joanmarie]

I assume that, were the browsers to provide a value through their accessibility API, Orca would stop looking and go with that?

If that is the consensus, yes.

i.e. Orca would not actually need to make any changes if browsers implement the words in this PR?

Not necessarily correct. The proposed change to the spec states that user agents need to calculate a value. But it doesn't state how that value should be exposed (does it?).

In fact, at the platform-independent / pure-ARIA level, where is the calculated value going to go?

• aria-valuetext
• name of the listbox?
• someplace else?

The answer to the above question determines what mappings will be needed (if any) in the Core-AAM.

Right now, Orca is not looking at AtspiObject attributes for any value (which is what it would need to start doing should aria-valuetext be the place where exposure is done).

Potentially-related aside, I initially only tested what happened when the combo box got focus; not what happened when you arrow in the expanded list box. I have just updated my earlier comment to reflect that when the "with valuetext" example is expanded, Orca does not present anything. Things work just fine for the "with text content" version.

(Did you figure out the double-speak? I'm assuming it's just some nit, and does not actually indicate that Chromium is providing a value... since it doesn't provide one in Windows Chrome...)

Yeah, fixed that a while ago. (And had updated the comment above to reflect that. I figure that there should just be one place where current results should go.)

[joanmarie]

When I up and down arrow in the "with valuetext" version, I am not getting any accessibility events. Are we missing an aria-activedescendant change?

[carmacleod]

When I up and down arrow in the "with valuetext" version, I am not getting any accessibility events. Are we missing an aria-activedescendant change?

We're only looking at the "with text content" one (the valuetext one is just an experiment) - sorry for the confusion!

Will get back to you about the other questions - just thinking things through...

[aleventhal]

Can someone provide me with 1 or more reasonable examples that authors might actually do, and where the combobox value should be computed by the UA? I'm not sure we're all working on the same thing. For example, one of the examples above had 2 items in the tab order, which wouldn't be very usable. @joanmarie what markup were you testing with?

[joanmarie]

I'm still somewhat bothered by the fact that we're telling user agents to calculate a value without associating an ARIA property with it.

Is everyone opposed to creating a new ARIA property that would initially be supported just on comboboxes, but later might be expanded to other things?

[carmacleod]

@joanmarie

I'm still somewhat bothered by the fact that we're telling user agents to calculate a value without associating an ARIA property with it.

User agents are already doing this for textbox value, so it's not a new thing... I guess the only new bit about it is that we're telling them to do it. (We should tell them to do it for textbox also, just to close the gap. ).

[JAWS-test]

I also prefer to allow aria-valuetext for more ARIA roles. Reason: #711 (and #721)

[jnurthen]

@JAWS-test expanding the roles which support aria-valuetext is not under consideration in this issue. Please only add comments relevant to this issue here so we don’t get sidetracked. If you want to comment about aria-valuetext being allowed on more roles #711 would be a more appropriate place.

[aleventhal]

Hi all, this morning's Canary (84.0.4110.0) has an implementation of this. I tested with JAWS, NVDA and VoiceOver and it seems to work on. Feel free to let me know of any issues you notice.
I tested with this codepen: https://codepen.io/aleventhal/full/MWaWpbb

[carmacleod]

Confirmed that in @aleventhal 's Chrome Canary, with focus on the "Select-only" combobox:

• In DevTools Accessibility panel, Computed Properties for the combobox has Value: "Banana"
• In Inspect.exe for the combobox, MSAA has Value: "Banana"
• In Accessibility Insights for the combobox, the UIA ValuePattern's Value = "Banana"
• NVDA, JAWS, and Narrator all read the newly-available Value 🎉

Here's the detailed screen reader output for typing tab key to give focus to combo, 3 down arrows to expand list and move down 2 items, enter key to choose item, close list and return focus to combo.
(Note: Narrator only expands on alt+down arrow. It closes on enter but does not choose option).

NVDA output

Choose a fruit combo box Banana collapsed
expanded
list
Apple not selected 1 of 8
Banana 2 of 8
Cherry not selected 3 of 8
Durian not selected 4 of 8
Choose a fruit combo box Durian collapsed

JAWS output

Choose a fruit Combo box
Banana
To change the selection use the Arrow keys.
List box
Banana
2 of 8
To move to an item press the Arrow keys.
Cherry
3 of 8
To move to an item press the Arrow keys.
Durian
4 of 8
To move to an item press the Arrow keys.
Choose a fruit Combo box
Durian
To change the selection use the Arrow keys.

Narrator output

Choose a fruit Banana combo box collapsed
Banana 2 of 8 selected
3 of 8 Cherry
4 of 8 Durion
Command Not available
Choose a fruit Banana combo box collapsed

Will test Chrome+VO on Mac next.

[joanmarie]

Hi all, this morning's Canary (84.0.4110.0) has an implementation of this. I tested with JAWS, NVDA and VoiceOver and it seems to work on. Feel free to let me know of any issues you notice.
I tested with this codepen: https://codepen.io/aleventhal/full/MWaWpbb

I just modified Orca to look for the valuetext object attribute for comboboxes and fall back on its normal figure-out-the-value handling. It works with Chromium built locally (which has Aaron's change) and Chrome Unstable (which lacks it). Linux apparently still isn't yet cool enough for Canary. 😀

[carmacleod]

Nice, @joanmarie !

I can confirm that VoiceOver works (but only if you use VO key navigation to operate the combobox. Not sure if it we expect combobox to be operable with simple arrow keys or not.)

VoiceOver output

Banana, Choose a fruit, collapsed, button
You are currently on a button, inside of a frame. To display a list of options, press Control-Option-Space. To exit this web area, press Control-Option-Shift-Up Arrow.
Control-Option-Space
Banana, Choose a fruit, expanded, button
Control-Option-Right Arrow
List box 1 item selected. Banana (2 of 8)
You are currently on a list box, inside of a frame. To begin interacting with the items in this list, press Control-Option-Shift-Down Arrow. To exit this web area, press Control-Option-Shift-Up Arrow.
Control-Option-Shift-Down Arrow
In list box 1 item selected. Banana (2 of 8) Banana (2 of 8) [says item twice for some reason]
Control-Option-Right Arrow
Cherry, (3 of 8)
You are currently on a text element, inside of a list box.
Control-Option-Right Arrow
Durian, (4 of 8)
You are currently on a text element, inside of a list box.
Control-Option-Space
Durian, Choose a fruit, collapsed, button

---

I can also confirm that Accessibility Inspector shows the Value (I'm guessing that's the AXValue I outlined in red in this screen snapshot? @cookiecrook ? It used to say "AXValue", but now it just says "Value".)

[JAWS-test]

@jnurthen
My comment refers to #1225 (review) and it concerns exactly the topic discussed here: How can the value of a combobox be determined. The idea is to use the text content. I don't think this is a good idea, because there are HTML elements without text content. The argument was already mentioned in the other issue and that's why I linked it.

[jnurthen]

@JAWS-test please stop. #711 was already linked in the first comment. This is adding nothing but noise to this issue.

[mcking65]

@joanmarie, @cookiecrook, I revised the language to remove the word "compute".

[joanmarie]

I like this version much better. Thanks for making these changes Matt!

[carmacleod]

Looks good to me!
+1

[jnurthen]

Previews failing due to spec-generator being down
w3c/spec-generator#292