Addition: selectedoption element

[scottaohara]

I recreated the original HTML AAM repo PR

The <selectedoption> element is part of the customizable select feature and is being added to HTML here.

Implementation

• WPT tests: Implement <selectedoption> for StylableSelect web-platform-tests/wpt#45096
• Implementations (link to issue or when done, link to commit):
  • WebKit: TODO
  • Gecko: TODO
  • Blink: https://chromium.googlesource.com/chromium/src/+/18b5eac27b14b409503aa8047cf9358082a0e0df

Co-authored-by: Joey Arhar @josepharhar

[netlify]

✅ Deploy Preview for wai-aria ready!

Name	Link
🔨 Latest commit	d1c9f9d
🔍 Latest deploy log	https://app.netlify.com/sites/wai-aria/deploys/66f6e9b714f64800084362ee
😎 Deploy Preview	https://deploy-preview-2344--wai-aria.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site configuration.

[spectranaut]

@jcsteh we need to discuss the mappings for this new element, if you wanted to take a look now and share your initial thoughts?

[jcsteh]

I'm finding it challenging to fathom mappings for this because I don't quite understand some of the use cases here.

1. If this were just about visual styling, I'd suggest that the button and its contained selectedoption should just be mapped to the value of the combobox accessible node, as this is the closest mapping to existing combo boxes. However, this might not work so well if there is something other than visual styling here.
2. If there is a button containing a selectedoption, what happens regarding focus? I assume the select/button/selectedoption get a single unified tab stop?
3. What's the split button use case? I looked at the explainer, but I still don't really get it. It seems like we might need to map selectedoption differently in that case, since it's outside the combobox. That could be problematic because it's then unclear what to expose as the value of the combobox.

[scottaohara]

hey @jcsteh, thanks for the questions.

Right now, it's generally assumed that this would be a generic or presentational element by default, it's meant to be the visual representation of the chosen option / value for the select.

In the HTML spec, the only valid place this element can be used is as a descendant of a button that is the first child of a select element. So in many cases it should just represent the chosen value.

But, the reason I wanted to get people to have a think on this is because HTML does allow all global attributes on this element, and being an element now, rather than just a text string, I'm not entirely sure what should happen, if anything, if developers were to use additional global attributes or even ARIA attributes on the element.

For instance,

<label for=s>example</label>
<select id=s>
  <button><selectedoption></selectedoption></button>
  <option>One</option>
  <option selected><img src=# alt=two></option>
</select>

If someone were to do the above, this should be exposed no differently than the current mappings for the select element. The chosen option's content would be rendered in the selectedoption element - this being the img alt=two. So a select with the name "example" per its label and a value of "two" per the alt text of the image within the option.

But what should happen if someone were to do:

<label for=s>example</label>
<select id=s>
  <button>
    <selectedoption aria-label="2 apples" title="2 is less than 4" tabindex=0></selectedoption>
  </button>
  <option>One</option>
  <option selected><img src=# alt=two></option>
</select>

Should any of the attributes be respected? Should they be used to modify the value that the select/combobox exposes? Should the value that's exposed by the select change if someone were to alter the visible children of the selectedoption - either adding content that wasn't part of the option element's label/value, or removing content that was?

At first I thought maybe this would be fine to treat similar to the slot element, but slot isn't consistent in how it's treated between browsers (some allowing it to be focused, or have the title update it's accname, though aria-label at least seems ignored in firefox and chrome). So, just being like "oh it can be like slot, that'll be fine" seemed like maybe not the best assumption to make.

So, that hopefully answers some of your questions / provides some more context to why I wanted others to weigh in on this, as just mapping this to 'generic' or 'none' would seem like the thing to do here for the default state - but if people start modifying the element / its contents, that's where I'm realizing there hasn't been any real discussion on that, that I'm aware of.

To more directly answer your 3 points, to make sure nothing's left out:

1. Generally speaking yes, the button > selectedoption within the select element would just be mapped to the value of the combobox. But, per the "that might not work so well..." that doubt is exactly why I wanted to get feedback on this / all the above rambling.

2. Yes, the seletedoption should not receive focus as its a child of the button and the button in this case is really just the styleable node for the customized select. So one single focus stop..... well, maybe unless someone puts a tabindex on that selectedoption element? Or maybe, like at least Chrome does with the slot element, tabindex should be ignored for selectedoption.

3. The split button use case seems like it'll be invalid at this point, since the spec has been updated to say that the selectedoption needs to be a child of the button used in the customizable select. I don't think we should spend time on that now, since it doesn't appear it's a valid use case anymore.

[jcsteh]

hey @jcsteh, thanks for the questions.

Thanks for the comprehensive answers. :)

But, the reason I wanted to get people to have a think on this is because HTML does allow all global attributes on this element,

Ah interesting. My understanding is that <selectedoption> should always be a clone of the content of the selected option. So even if HTML does allow all global attributes, semantically, the content should be the same. That suggests that aria-label shouldn't override the content, for example, which also implies that aria-label shouldn't be exposed. The title attribute in particular is a little unclear, though, because it might be rendered as a tooltip visually when the user mouses over the <selectedoption>.

Should any of the attributes be respected? Should they be used to modify the value that the select/combobox exposes?

Per the above, I don't think so.

Should the value that's exposed by the select change if someone were to alter the visible children of the selectedoption - either adding content that wasn't part of the option element's label/value, or removing content that was?

Interesting. So the spec guarantees that <selectedoption> will update its content to clone the selected option if it changes in any way, but it doesn't guarantee that the author can't make changes to the <selectedoption> after that clone occurs but before any subsequent change causes another clone? Practically speaking, I'm guessing most authors won't rely on this because it's fragile: any change to the selected option could obliterate their changes to <selectedoption>. I think (hope) that means we can reasonably ignore this and always expose the value of the selected option.

All of that said, now I'm more puzzled about how we should handle a <button> inside a select that does not contain <selectedoption>, or perhaps contains <selectedoption> along with other things. Should that content be exposed as the value? But it might not be a value at all.

[aleventhal]

Regarding #2, the way it works in Chrome right now, is that focus goes to the button instead of the select, when the button exists. As a result the A11y tree in Chrome has to have code that remaps focus from the button to the select object in the a11y tree. We likewise remap actions like default action / click and focus requests from the select to that button, if it erxists.

Regarding #3, if the split button use case is no longer valid, then we should suggest to folks working on this that this is just about styling, and that pseudo elements would be a better way to style the button and possibly visible value within. If we do that, then I believe issue #1 and #2 go away.

[josepharhar]

Interesting. So the spec guarantees that <selectedoption> will update its content to clone the selected option if it changes in any way, but it doesn't guarantee that the author can't make changes to the <selectedoption> after that clone occurs but before any subsequent change causes another clone? Practically speaking, I'm guessing most authors won't rely on this because it's fragile: any change to the selected option could obliterate their changes to <selectedoption>. I think (hope) that means we can reasonably ignore this and always expose the value of the selected option.

It sounds reasonable to me to ignore this and always expose the value of the selected option.

If there is a button containing a selectedoption, what happens regarding focus? I assume the select/button/selectedoption get a single unified tab stop?

Regarding 2, the way it works in Chrome right now, is that focus goes to the button instead of the select, when the button exists. As a result the A11y tree in Chrome has to have code that remaps focus from the button to the select object in the a11y tree. We likewise remap actions like default action / click and focus requests from the select to that button, if it erxists.

Yes, this is the way. I also added code in chrome to set delegatesFocus on the select element when there is a child button which is what makes the focus go to the button element instead of the select element.

Regarding 3, if the split button use case is no longer valid, then we should suggest to folks working on this that this is just about styling, and that pseudo elements would be a better way to style the button and possibly visible value within. If we do that, then I believe issue 1 and 2 go away.

Without the author provided button and selectedoption element, then you don't currently get elements cloned into the button, only text content, and there's no way to style the option and button differently. So if you want your img element to be copied into the button without using script, this is the only way. Cloning all the "rich" content into the button without this would require us to clone content into the user-agent ShadowRoot of the select element and providing a way for authors to have full styling capabilities into the ShadowRoot, both of which are problematic technologies that may or may not ever exist.

[aleventhal]

What happens if the selected option has a child button or link? Will that also get cloned into the selectedoption's subtree? Will they also be focusable?

[josepharhar]

What happens if the selected option has a child button or link? Will that also get cloned into the selectedoption's subtree? Will they also be focusable?

Yes that will get cloned because the algorithm doesn't discern between what kinds of elements it clones. I suppose it will be focusable assuming that nested buttons/links are individually focusable.

However, putting interactive content inside an option element like this is already against the content model, so I don't see how this makes the situation any different or worse.

[aleventhal]

However, putting interactive content inside an option element like this is already against the content model, so I don't see how this makes the situation any different or worse.

That's a use case that I'd eventually like to support for buttons and links. We'll be able to make it accessible with an update to screen readers, and if it's the reason people will need to use a JS-based solution, we'll be losing an opportunity for better accessibility. IMO what should happen from a practical POV is that any descendant buttons and links are stripped out of the subtree when it's copied to the selectedoption.

[josepharhar]

any descendant buttons and links are stripped out of the subtree when it's copied to the selectedoption.

I suppose thats something we could try to change later when we get to the eventual support of buttons and links, but right now the algorithm is very simple and just clones everything.

[smhigley]

I think we discussed the need for a way to set the human-readable-text value of options separately from the text content of <option> and <selectedoption> elements to enable type-to-find behavior.

Assuming we figure that out at some point, would that attribute also carry over to the selectedoption element and be used to set the calculated value of the <select> separately from the text content when present?

I dunno if that's in scope for this PR, especially since neither HTML AAM nor Core AAM spec how to calculate the value for combobox/select. Though with the more complicated <select>, what do you think of actually adding explicit value calculation steps somewhere?

[scottaohara]

However, putting interactive content inside an option element like this is already against the content model, so I don't see how this makes the situation any different or worse.

the important thing to note about this though is that visually these items can be seen, they can be focused, but they will not be announced by screen readers - at least in my testing with JAWS/NVDA and Chrome/Edge.

Unlike nesting links/buttons within options, where common use cases for that are performing an action on/related to the option, while the popup is open - I cannot think of a single instance of ever seeing these commands returned along with the chosen value to a custom combobox/select.

i wonder, if it's out of scope to change the cloning algorithm at this time, should there at least be important UA styles to display none instances of elements that don't adhere to the content model, if rendered within a selectedoption?