[Selectmenu] Best practices for autofill and <selectmenu>

[mfreed7]

The <selectmenu> proposal allows for arbitrary HTML within the contained <option>s. Further, it allows the developer to fully replace big chunks of the anatomy including the button and the listbox.

Given the large amount of customization that is possible for <selectmenu>, it would seem that we need fairly clear developer guidance on how to ensure that a given <selectmenu> works well with browser autofill systems. For example, what if an address form's <selectmenu> for choosing a State was implemented like this?

<selectmenu id=state>
  <option>
    <svg><text>Alabama</text></svg><img src=alabama_flag.png>
  </option>
  <option>
     ...

I.e. the <option>s here only contain SVGs and images, and no (non-foreign-context) text nodes. Will the browser's autofill system be able to find the "Alabama" option?

@una @stubbornella @battre

[scottaohara]

per the example you provided, @mfreed7, that markup pattern would not return an accessible name for the option. An alt on the image, or a role=presentation on the svg element would be necessary without changes to how names are computed for such roles.

[battre]

I think that 3 option that come to my mind for consideration would be checking whether the <option> elements have a value attribute, an aria-label, or we could evaluate their node.textContent.

So for example:

<selectmenu id=state>
  <option value="AL" aria-label="Alabama">
    <svg><text>Alabama</text></svg><img src=alabama_flag.png>
  </option>
  <option>
     ...

[gregwhitworth]

This is a great callout and something that the specification for sure is missing. I really want to avoid boiling the ocean and think that we should have an interoperable default and it can be what browsers ship today but I'd wager this should be another primitive that we can swap behaviors on.

cc: @captainbrosset @dandclark

[captainbrosset]

69 is relevant here.

The current behavior of <select> is to concatenate the text content of all text nodes within the <option>. So the above markup example, currently, renders this:

I'm not so certain that <option>s of a <selectmenu> should deviate from this current behavior. The listbox part already allows for custom markup to be added. So, as a developer, I'd actually find it quite OK to create my own divs and such to hold the images, svgs, checkboxes and what not, and make sure I have an option in there too, containing just text.

<selectmenu>
  <div slot="listbox">
    <popup behavior="listbox">
      <div class="item">
        <img src="alabama_flag.png" alt="The Alabama flag">
        <option value="AL">Alabama</option>
      </div>
    </popup>
  </div>
</selectmenu>

[scottaohara]

Being that someone using a screen reader would only be expected to interact with the options of a listbox, while the markup you use @captainbrosset for this example would be 'fine' in that there's nothing of significance that isn't included in the option, it does raise questions of why it could not be recommended to be as the following instead:

<selectmenu>
  <div slot="listbox">
    <popup behavior="listbox">
      <div class="item">
        <option value="AL">
          <img src="alabama_flag.png" alt="">
          Alabama
        </option>
      </div>
    </popup>
  </div>
</selectmenu>

For other situations where content that would be important for all users to access, e.g., 'checkboxes and what not' that seemingly could be siblings to the <option>s, it significantly deviates from how people using AT presently interact with a listbox popup. That's not to say it couldn't or shouldn't be possible... but there's a lot to think about and consider.

[github-actions[bot]]

There hasn't been any discussion on this issue for a while, so we're marking it as stale. If you choose to kick off the discussion again, we'll remove the 'stale' label.

[josepharhar]

I.e. the <option>s here only contain SVGs and images, and no (non-foreign-context) text nodes. Will the browser's autofill system be able to find the "Alabama" option?

In the case that an option is built which doesn't provide basic text context to the browser for autofill, we should probably emit a console warning/error. There are other poor accessibility cases where we are also planning to do this, right?

[github-actions[bot]]

There hasn't been any discussion on this issue for a while, so we're marking it as stale. If you choose to kick off the discussion again, we'll remove the 'stale' label.

[josepharhar]

I'll leave this issue open as a reminder to emit console messages in the case that the author creates an option element with no accessible name, which is also a name that autofill could use.