w3c / aria

Accessible Rich Internet Applications (WAI-ARIA)
https://w3c.github.io/aria/
Other
654 stars 125 forks source link

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

Open scottaohara opened 3 weeks ago

scottaohara commented 3 weeks ago

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 commented 3 weeks ago

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 commented 2 weeks ago

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 https://github.com/w3c/aria/pull/2369 and https://github.com/w3c/aria/pull/2344

spectranaut commented 1 week ago

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

scottaohara commented 1 week ago

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