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

[scottaohara]

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]

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]

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]

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

[scottaohara]

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

[scottaohara]

closing this issue as the two PRs i mentioned above now both state that global aria/html attributes aren't going to be respected on the button part / selectedcontent elements, since the button part is to be treated as inert.