Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Consider allowing aria-valuetext for combobox role #2382

Open
scottaohara opened this issue Nov 21, 2024 · 6 comments
Open

Consider allowing aria-valuetext for combobox role #2382

scottaohara opened this issue Nov 21, 2024 · 6 comments
Assignees

Comments

@scottaohara
Copy link
Member

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
Copy link
Contributor

spectranaut commented Nov 21, 2024

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

@scottaohara
Copy link
Member Author

#711

@MarioBatusic
Copy link
Contributor

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
Copy link
Member Author

scottaohara commented Nov 29, 2024

@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
Copy link
Contributor

smockle commented Dec 5, 2024

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

@smockle smockle removed the Agenda label Dec 5, 2024
@spectranaut
Copy link
Contributor

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants