Skip to content

Unexpected keyboard focus of inactive tab in a tablist #8906

@scottaohara

Description

@scottaohara

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:

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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    p3https://github.com/nvaccess/nvda/blob/master/projectDocs/issues/triage.md#prioritytriagedHas been triaged, issue is waiting for implementation.

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions