Qwik's handling of preventDefault makes it difficult to create accessible behavior for keyboard events about qwik-ui HOT 1 CLOSED

Interesting thought @shiroinegai you put in here.

Indeed; taking over the accessibility of the native Select if a tough challenge.

Many states have to be taken in account:

• closed, no value or withe a selected value
• open to the selected value
• open & focused; close & focused
• active and close / open (being clicked)
• open and press space
• open and press enter
• etc

I presume there're browsers and devices (e.g screen reader) specific behaviours as well to consider.

So, here're my thoughts: the closer to the native, the happier integration.

I suggest to explore

• using an HTML list of labels (ul / li)
• with checkbox for multiple selection
• or radio for single select

Aligned with both the native a11y support and devices native controls, that approach handles with no effort the states of disabled, selected, required and focused.

Additional considerations

• using fieldset for per group options
• using fieldset and input text for auto completion
• using under-engineered approach (see Roselli).

I'm happy to give a shot on this one!

from qwik-ui.