Option list not open when focusing with tab, or using arrow keys

[Finrod927]

Vue3-Select-Component version

0.12.3

Link to minimal reproduction

https://github.com/Finrod927/vue3-select-component-teleport-issues

Steps to reproduce

npm run dev with the reproduction repository

One of my colleagues reported that the list cannot be opened with a keyboard unless you start typing to filter options.

1. Focus the first input
2. Press "tab" to focus the VueSelect > the option list does not open
3. Use "up" or "down" keys > the option list does not open

Usually, focusing the field with tab open the list. At least, using the arrow keys should do it.

What is expected?

The option list is open when focused with tab, or at least can be open with arrow keys

What is actually happening?

The option list stays hidden until you start typing in the search field

Any additional comments?

No response

[TotomInc]

Does v0.13.0 helps with this @Finrod927?

We've shipped implementation with @floating-ui/vue

[thiervoj]

I think it has something to do with the fact that the .dropdown-icon button has tabindex="-1", avoiding users from focusing it using the tab key, since it removes the button from the natural focus flow of the document.

My way to fix this is simply to remove the tabindex attribute from the button programmatically, I'm doing it this way :

<script lang="ts" setup>
const selectRef = ref(null)

watchOnce(selectRef, (target) => {
  const button = target.containerRef?.querySelector('.dropdown-icon')

  button?.removeAttribute('tabindex')
})
</script>

<template>
  <VueSelect
    ref="selectRef"
  />
</template>

The behavior is the same in the 0.12.x and 0.13.0 versions

[TotomInc]

@thiervoj can you take a look at this demo deployment please?

=> https://vue3-select-component-l0i24l9br-tcaweb.vercel.app/demo/single-select.html

I've made a change in a PR that removes all tabindex="-1", this means that indicators (clear & chevron buttons) are now focusable, as well as MenuOption form the dropdown menu.

The ideal behavior, and the most accessible, from my point of view is:

• Input focus doesn't open menu dropdown: this is intended, menu is opening if you start searching for something
  • I'll see what WAI-ARIA recommends in terms of keyboard navigation accessibility.
• Second tab will focus the chevron button: press space or enter to open the dropdown menu

But, again, I'll ensure to research more about recommended WAI-ARIA patterns for keyboard navigation accessibility. 🙂

[thiervoj]

It looks functioning to me, with some caveats still.

I noticed that triggering the Clear button with the keyboard results in the focus being lost by the component.
I think the focus should remain in the component (for example be placed programmatically to the Chevron button) when the Clear button is triggered (whether it has been triggered by a keyboard or a pointer interaction)
Focus is also lost as soon as an option is selected, I don't know if this is an accessibility requirement, but I think that it should

• Input focus doesn't open menu dropdown: this is intended, menu is opening if you start searching for something
  • I'll see what WAI-ARIA recommends in terms of keyboard navigation accessibility.

I think that would be the correct way, but the Arrow/Home/End keys should still open the menu options if the focus is on the search input, or any button

• Second tab will focus the chevron button: press space or enter to open the dropdown menu

This may differ from the WAI-ARIA recommendation : having to press tab twice to be able to open the menu. Perhaps the space/enter keys should be listened to and trigger the opening of the menu in the case where nothing has been typed in the search bar ?

Also, could you try testing this new behavior (with no tabindex) when the isSearchable prop is turned off ?

[Finrod927]

I'm not very familiar with WAI-ARIA recommendations, so I will trust your choices for that :)

I think that would be the correct way, but the Arrow/Home/End keys should still open the menu options if the focus is on the search input, or any button

But I agree with @thiervoj on this point: you usually use those keys to navigate in the list, it will be better if they also open it.

[TotomInc]

This may differ from the WAI-ARIA recommendation : having to press tab twice to be able to open the menu. Perhaps the space/enter keys should be listened to and trigger the opening of the menu in the case where nothing has been typed in the search bar ?

When there is no option selected, first tab will focus the search input. You can then press Enter / Arrow / Page keys to open the menu. You don't need to tab one more time into the chevron to open the menu.

CleanShot.2025-10-29.at.08.47.08.mp4

I think that would be the correct way, but the Arrow/Home/End keys should still open the menu options if the focus is on the search input, or any button

After some research, WAI-ARIA doesn't have examples where there are indicators buttons (e.g. clear or chevron down buttons). This means that buttons are expected to behave like buttons: Space/Enter activate, without any additional event-listener or that may cause confusion and inconsistency.

Also note that, if you focus the search input there is no option selected, pressing Space/ArrowUp/ArrowDown will open the dropdown menu.

---

I've implemented a fix to:

• keep focus on the search input when selecting an option
• keep focus on the search input after clearing an option

Keyboard navigation is now super smooth, this means that the "context" is never lost after interacting with the component:

• First tab to focus the select
• All later interactions with the select keep the context, no more "tab" needed to re-gain focus on the select

CleanShot.2025-10-29.at.09.07.21.mp4

When is-searchable="false", the navigation is smooth too, except when you're removing an option with the clear button. That behavior doesn't seem "fixable", focusing the chevron down right after deleting an option doesn't seem natural.

[TotomInc]

All these fixes have been released officially in v0.14.0

It's best to keep track of a11y in separate issues.