Open Bug 1720273 Opened 3 years ago Updated 3 years ago

wrong enumeration in screen readers for role="tab" non direct descendants

Categories

(Core :: Disability Access APIs, defect, P3)

Firefox 89
defect

Tracking

()

People

(Reporter: adilsonsdev, Unassigned)

References

(Blocks 2 open bugs)

Details

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:89.0) Gecko/20100101 Firefox/89.0

Steps to reproduce:

Create a layout with more than one role="tab" elements that are non-direct descendants of role="tablist", for example ul[role="tablist"] > li > button[role="tab"] and use a screen reader to navigate through the tab elements using the keyboard (tested on Windows with Narrator and NVDA).

Test case: https://codepen.io/2alin/pen/jOmqZqJ

Actual results:

The screen reader announces all tabs as "tab 1 of 1".

Expected results:

The screen reader should announce tabs as "tab 1 of {n}", "tab 2 of {n}", ... where {n} is the total amount of tabs under role="tablist" container.

W3C recommendations establishes [1]:

Authors MUST ensure elements with role tab are contained in, or owned by, an element with the role tablist

and owned means any descendant, not necessarily a direct one:

An 'owned element' is any DOM descendant of the element, any element specified as a child via aria-owns, or any DOM descendant of the owned child.

Chromium browser (v91) has no issue.
There's no issue in Firefox (v89) if role="tab" are direct descendant of role="tablist".

[1] https://www.w3.org/TR/wai-aria-1.1/#tab

The Bugbug bot thinks this bug should belong to the 'Core::Disability Access APIs' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.

Component: Untriaged → Disability Access APIs
Product: Firefox → Core

Similar to bug 995064, though in this case, Chrome actually strips the <li> elements from the a11y tree altogether. We might be able to do that, though we definitely can't do that for some of the test cases in bug 995064 (because the intervening elements are focusable and thus must be exposed in the tree). Though it looks like Chrome strips the <li> elements even if you make them focusable, which is... interesting.

Blocks: aria, groupa11y
Severity: -- → S3
Status: UNCONFIRMED → NEW
Ever confirmed: true
Priority: -- → P1
See Also: → 995064
Priority: P1 → P3
You need to log in before you can comment on or make changes to this bug.