Qwik's handling of preventDefault makes it difficult to create accessible behavior for keyboard events

[shiroinegai]

This problem surfaced in trying to re-create native Select behavior.

Native Tab behavior on a select element activates the currently focused option and moves to the next tabbable element, usually the next form input element. As we have re-implemented the Select component without using native elements in favor of better styling capability, additional keyboard event listeners have to be implemented for accessibility.

However, Qwik currently only works with preventDefault as an attribute to an element like so:

<button preventDefault:onKeyUp>
</button>

and the following does not work:

<button onKeyUp$={(e) => {
    if (e.key === 'Tab') {
        e.preventDefault()
    }
}}>
</button>

This means that in order for us to recreate native Tab behavior for a Select component, we would have to set preventDefault on the element, and then re-implement existing behavior like Enter or Space to activate the element. This is potentially extra tedium or would clash with what users may expect when using Qwik UI in the future to compose their own components.

[tleperou]

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!

[maiieul]

I think this can be closed since we have sync$ now.

cc @thejackshelton