Unexpected keyboard focus of inactive tab in a tablist

scottaohara commented 6 years ago

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:

With NVDA and a web browsers (tested with firefox, chrome and IE11), visit: http://bleachedgraphics.com/test/tabs/tests/focus-test.html
Navigate with the virtual cursor, or by heading elements, until "The test, heading level 2" is announced.
Hit the Tab key to navigate into the tablist.

Alternatively

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:

Installed

NVDA version:

2018.3.2 2018.4 2018.4.1

Windows version:

Windows 10 Pro 10.0.17134

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

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

Does the issue still occur after restarting your PC?

Yes

Have you tried any other versions of NVDA?

all versions mentioned

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

JackWan commented 5 years ago

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

scottaohara commented 5 years ago

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

scottaohara commented 5 years ago

Testing again today, this is still an issue with NVDA 2018.4 and 2018.4.1

Adriani90 commented 5 years ago

cc: @leonardder

bbsmooth commented 1 year ago

Still an issue in 2023 using NVDA 2022.4.

Adriani90 commented 5 months ago

@jcsteh, @SaschaCowley maybe you have some feedback for this one, I don't really understand how tab key is really expected to work in browse mode. It should never focus elements with tabindex = "-1" at all i guess. Is there any reason why we reach such elements with the tab key in browse mode?

jcsteh commented 5 months ago

When the browse mode cursor moves away from the focus, browse mode has to override the tab key, since otherwise, the tab key might not move where the user expected it to move. For example, say you have a text box, an h1, a link, an h2 and a button. If the user tabs to the text box but then navigates to the h2, focus is still on the text box (because an h2 isn't focusable). At this point, pressing tab in the browser would focus the link below the h1, but this isn't what the user wants because their (browse mode) cursor is at the h2 below that link. Instead, the user expects the button to get focus.

Because NVDA overrides the tab key, it doesn't have access to all the browser's capabilities for determining precisely what can get focus. All NVDA can do is search for the next focusable element beyond a particular element. Unfortunately, that includes tabindex="-1" because there is no differentiation between tabindex="-1" and tabindex="0" as far as accessibility APIs are concerned.

Even if there were, there would still be problems with tabindex > 0. Fixing that is even harder.

jcsteh commented 5 months ago

This could probably be fixed for tabindex="-1" if accessibility APIs and browsers provided an additional bit of data about things that are programmatically focusable vs keyboard focusable. I don't really see a reasonable fix for tabindex > 0, though.

nvaccess / nvda