Consider allowing aria-valuetext for combobox role

[scottaohara]

In attempting to decide upon a way for the customizable select element to calculate the value to expose to users, use cases arose where allowing an author to set aria-valuetext on the select element (role=comobox) instead of having to fiddle with the returned markup from the select element's chosen option, seemed like a good idea.

Consider the following:

<!-- this option was specifically marked up so that the value would be "smile icon 1" rather than something like "smile smile icon 1" -->
<option>
  <span role=img aria-label="smile icon 1">🙂</span>
  <span class=description aria-hidden=true>smile icon 1</span>
</option>

In the collapsed state, the description is set to display none so that only the emoji is displayed.

The following is a lot easier for a developer to do to get the option to announce in the intended way - but the returned content to the selectedoption element will only be the emoji, not the aria-label

<option aria-label="smile icon 1">🙂</option>

so, if someone could do

<select aria-valuetext="smile icon 1">
  <button><selectedcontent>🙂</selectedcontent></button>
  ...
</select>

that'd be a lot nicer than having to fiddle with very specific markup patterns, ensuring that every bit was marked up properly to convey the intended value when interacting with the collapsed select and when reviewing individual options.

cc @smhigley @aleventhal

[spectranaut]

We should find the existing issues related to aria-valuetext before discussing this in a meeting.

[scottaohara]

#711

[MarioBatusic]

For me it sounds peculiar that an author has to use ARIA (in this case aria-valuetext) in a native new HTML element to enable its accessibility. That was up to date never the case. Every native element has its in-built accessibility and that should stay so further on. I don't know how to get it correct in the case of stylable select. But hopefully not using ARIA that should only enable authors to code semantics where it is not possible with the markup of the underlying markup language.

[scottaohara]

@MarioBatusic you misunderstand. aria-valuetext wouldn't be necessary by default. but it would be a useful tool to have for developers who need to do more complicated things with the presentation of the chosen selected value (which can now have content beyond just text) which can still be done with HTML alone, but might take far more markup to accomplish.

[smockle]

We discussed this in today’s ARIA WG meeting, so I’m going to remove the “Agenda” label.

[spectranaut]

Discussed in today's meeting: https://www.w3.org/2024/12/05-aria-minutes#4b53

[aleventhal]

From the minutes: "Rahim: there was some internal discussion on this; consensus was that behaviour like described in the issue would be the right behaviour".

@scottaohara Do you have time to work up the appropriate PRs? The Chromium issue is https://issues.chromium.org/issues/392649975 — I can work on the implementation when the PR is up.

[scottaohara]

writing to acknowledge the ping. I'll hopefully have time to work on finalizing the select PRs tomorrow. Which is also what i had hoped to be able to do yesterday and today....

but yeah... on the todo list....