New issue
Advanced search Search tips

Issue 868589 link

Starred by 1 user

Issue metadata

Status: Available
Owner:
Components:
EstimatedDays: ----
NextAction: ----
OS: Windows
Pri: 2
Type: Bug
Team-Accessibility



Sign in to add a comment

Chromium's accessibility implementation is choosing to ignore children of ARIA role="tab"

Reported by matthew....@gmail.com, Jul 27

Issue description

UserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/64.0.3282.140 Safari/537.36 Edge/17.17134

Steps to reproduce the problem:
1. Create a page with accessible tabs, where the elements with role="tab" have focusable children elements. Example: see attached zip for an example
2. Use a screen reader (NVDA for example) while tabbing through the page
3. Get to the child elements

What is the expected behavior?
The screen reader reads descriptions of the child elements

What went wrong?
Nothing is said

Did this work before? N/A 

Chrome version: 64.0.3282.140  Channel: stable
OS Version: 10.0
Flash Version: 

I opened up an issue against NVDA when I first found this, but one of their devs said it is Chrome's/Chromium's accessibility tree which is causing the issue: https://github.com/nvaccess/nvda/issues/8560
 
tabs-with-buttons.zip
4.1 KB Download
Components: UI>Accessibility>Compatibility
Labels: Needs-Milestone
Owner: aleventhal@chromium.org
Status: Available (was: Unconfirmed)
Reporter@, can you try with a recent Chrome? Even the beta? Like Chrome 70.
Summary: Chromium's accessibility implementation is choosing to ignore children of ARIA role="tab" (was: Chromium's accessibility implementation is choosing to ignore children of tabs)
Also, I would recommend using a <div> instead of a button. It's unusual to have something focusable inside something else that's focusable, with the exception of frame/iframe.

Alternatively, you could also use aria-activedescendant to point to the child item within. 

Sign in to add a comment