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

HTML AAM: how to handle attributes and aria-* on button/selectedoption within a select #2368

Open
scottaohara opened this issue Oct 31, 2024 · 4 comments
Assignees

Comments

@scottaohara
Copy link
Member

scottaohara commented Oct 31, 2024

Consider the following:

<label for=s>Choose a fruit</label>
<select id=s aria-label="choose a fruit you want to eat">
  <button aria-label="you chose" title="a bit much, no?">
     Choose:
     <selectedoption title=delicious>Fruit name here</selectedoption>
  </button>
  ...
</select>

The visible label/name from the label element is "choose a fruit"

the select's name becomes "choose a fruit you want to eat" from its aria-label.

but the inner button element has the word "choose" within it
the button also has an aria-label of "you chose" and "a but much, no?" as a title/desc
the selectedoption has its own title attr of "delicious"

will someone do all this at once? only if they're sick like me. but people will think they can do these things, individually.
but should they be allowed to?

A select / its button part - in the chromium implementation and how they're going to be described in HTML AAM, are effectively 1 item in the a11y tree. Naming the button part / including text a description for it would be in conflict with anything declared on the select parent. Moreover, there's a possibility that "renaming" or modifying the select's name isn't even the goal of a developer in this instance - but rather, they're adding in content that is superfluous to expose, or is meant to be more of a "hint", extension or overwriting of the chosen value.

IMO, but very curious what others think, I'm not seeing the benefit to respecting aria attributes on the button/selectedoption parts of the select. i do see value in "guessing" that the extra text in the button, as a sibling to the selectedoption, might be a "hint". edit: but in the open ui call, people might also want the entire contents of the button to be the actual value. or, maybe they don't want to have a visible value at all, in which case, no value should be stated? (more in comment below)

if doing something more complex with this, though, we run into some interesting scenarios of needing to decide what takes precedence for naming / describing / changing the value of the select...

@scottaohara
Copy link
Member Author

some interesting use cases came up in the openui meeting today, where there was desire to not use the selectedoption in a customized select at all, and that anything in that button should then become the value of the select. OR, that someone might not want to display the value in the select at all, but rather within a sibling text field, for instance. in which case, maybe no value is returned/announced since there's nothing in the button part to display.

i'm still not so sure about using aria-label / other attributes on the button or selectedoption within a select, since their use would likely be to try to change the value, and not actually modify the 'name' of the select....

more to come on this, i'm sure...

@scottaohara
Copy link
Member Author

scottaohara commented Nov 7, 2024

from today's talk, going to recommend/spec that the aria attributes are ignored on the button / selectedoption elements within the select.

related to the work on #2369 and #2344

@spectranaut
Copy link
Contributor

Discussed last week: https://www.w3.org/2024/11/07-aria-minutes#4b84

@scottaohara
Copy link
Member Author

update: resolution from this issue has been incorporated into #2369
next step to incorporate into #2344

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

3 participants