refactor(sbb-select): avoid to move the the trigger element (combobox) to the light DOM

[DavideMininni-Fincons]

To allow screen readers to properly interpret the state of our select component, we had to create an invisible focusable element in the light dom, which serves as the combobox role.
The idea is to follow the material WC select aria structure that apparently works without any light dom element.

[DavideMininni-Fincons]

A test has been done with the following actions:

• the logic that moves the trigger element in the light dom has been removed
• the trigger element itself has been removed
• its attributes have been added to the element that displays the value

Using Voiceover, it sometimes reads the full element, like label, placeholder, combobox etc, and sometimes it skips the first two and it announces only the combobox.
This behavior is similar on what happens with the select at link https://material-web.dev/components/select/

However, when the panel is open in Lyne, the screenreader never reads the options when they are selected via arrow, while it does on the compared library.
While we handle the options panel by using the aria-activedescendant on the selected option and we keep the focus on the select element, the material WC moves the focus on the options, changing the tab-index accordingly. This allows the options to be read.
This does not fit for our case, so I think we have to stick with the actual behavior.
@kyubisation @jeripeierSBB @TomMenga

[kyubisation]

Thanks for the investigation!

Thinking out loud here; Could we adopt this logic for sbb-select, but keep the other logic for sbb-autocomplete (etc.)? From my understanding, the necessary logic can be handle by the respective parent of sbb-option instances?
Thoughts?

[TomMenga]

I'm not sure I understood @kyubisation suggestion, but another negative aspect of not using the 'active-descendant' approach is that we would lose some a11y reading features (like the "1 of n" on the option and the grouping).

The ideal solution would be to separate the trigger from the "select menu". This way, the focusable element would be in the light-dom and the screen readers should still be able to handle the grouping.

<sbb-form-field>
  <sbb-select-input role="combobox" ... />
</sbb-form-field>

<sbb-select-menu>
  ...
</sbb-select-menu>

[kyubisation]

I would like to avoid separating into two different elements as our current html API is aligned with the upcoming select feature: https://developer.chrome.com/blog/rfc-customizable-select

[TomMenga]

Fair point 😐

[DavideMininni-Fincons]

I thought I answered this but maybe I didn't click on comment after writing the message:
as Tommaso mentioned, if we move the focus on options we lose the information about the group and the list (x element on n).
:|