New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Unexpected keyboard focus of inactive tab in a tablist #8906

scottaohara opened this Issue Nov 1, 2018 · 2 comments


None yet
2 participants
Copy link

scottaohara commented Nov 1, 2018

When interacting with an ARIA Tab widget, it's common to set the currently active tab to have a tabindex=0 and to set the inactive tabs to have a tabindex=-1. When testing various different implementations of Tab widgets, it was noticed that if navigating by the virtual cursor, and then hitting the Tab key, keyboard focus would be set to the first tab in the tablist, regardless of whether or not it was the currently active tab / the tab with the tabindex=0.

Removing the possibility that incorrect JavaScript/focus management could be to blame, a reduced test case continues to display this behavior across browsers.

Steps to reproduce:


  • Navigate by heading elements until "testing from beneath the tablist, heading level 3" is announced.
  • Hit the Shift + Tab keys to navigate backwards in the DOM.

Actual behavior:

The first tab with the accessible name of "Apple" receives focus, even though it has a tabindex=-1.

If navigating backwards from the h3, the last tab with the accessible name of "Orange" is focused, even though it has a tabindex=-1.

Expected behavior:

The tab with aria-selected="true" and tabindex="0" should have been the element that received keyboard focus, regardless of navigating forwards or backwards into the tablist.

Note: if navigating solely via the Tab key, keyboard focus moves to the tab with tabindex=0 as expected. e.g. if Navigating by Tab key from one of the links in the test file, the tab with the accessible name of "banana" will be properly focused, as expected.

System configuration:

NVDA Installed/portable/running from source:


NVDA version:


Windows version:

Windows 10 Pro

Name and version of other software in use when reproducing the issue:

Chrome (latest), Firefox 63.0.1, Firefox 65.0a1, IE11

Does the issue still occur after restarting your PC?


Have you tried any other versions of NVDA?


Note that this same unexpected behavior also occurs when using JAWS 18 and 2018. It does not occur when using VoiceOver.


This comment has been minimized.

Copy link

JackWan commented Nov 26, 2018

Exactly the same issue. If adding tabindex="0" for <ul role="tablist">, then the issue is gone but that seems weird.


This comment has been minimized.

Copy link

scottaohara commented Nov 26, 2018

Right, I'd definitely consider that a work around, creating an extra tab stop, rather than a proper solution :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment