New issue
Advanced search Search tips

Issue 598417 link

Starred by 1 user

Issue metadata

Status: WontFix
Owner: ----
Closed: Apr 2016
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Mac
Pri: 2
Type: Bug
Team-Accessibility



Sign in to add a comment

Accessible label generated by aria-labelledby does not output a label in VoiceOver

Reported by jesse.r....@gmail.com, Mar 28 2016

Issue description

UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/49.0.2623.87 Safari/537.36

Steps to reproduce the problem:
1. I created a test case pen: http://codepen.io/jessebeach/pen/vGZqgj
2. Turn on VoiceOver
3. Start in the input box, tab focus to the "Wendell Berry" node.
4. Note that the aural output for the node is "Wendell Berry, group", not, as it should be, "To go in the dark with a light is to know light, group"

What is the expected behavior?
The aural output when the "Wendell Berry" node is focused should be "To go in the dark with a light is to know light, group"

What went wrong?
Something changed in OSX between Yosemite and El Capitan. I've attached two screenshots from the Accessibility Inspector for similar nodes across the two OS versions. 

Note that in Yosemite, accessibilityTitle has an empty string and accessibilityLabel has a value. In El Capitan, accessibilityTitle has a value and accessibilityLabel is empty.

Did this work before? Yes In Yosemite

Chrome version: 49.0.2623.87  Channel: stable
OS Version: OS X 10.11.3
Flash Version: Shockwave Flash 21.0 r0
 
yosemite.png
207 KB View Download
el-capitan.png
93.0 KB View Download

Comment 1 Deleted

Chrome is producing the correct label for aria-labelledby at the browser AX Tree level.
el-capitan-vo-bug.png
345 KB View Download
Components: -UI UI>Accessibility
It works as expected if you use a widget role like "button".

What seems to have changed here is that VoiceOver now ignores the accessible label for objects with a Mac role of AXGroup.

I'd highly recommend you use a role other than "group", because this may fail in other screen readers too. It doesn't make sense to have a focusable group.

We can probably fix it for the case where the group is focusable, but it's still an author error.

And roles article and menu as well now, too.

It was a handy way to provide a curated summary of a group of items.

I'll find another hack to produce a summary.

Thank you for looking at this. You can close it. 
Cc: ellyjo...@chromium.org
Status: WontFix (was: Unconfirmed)
[mac triage] closing per #c4

(but also cc elly for "Something changed in OSX between Yosemite and El Capitan.")
The thing that changed is VoiceOver's handling of focusable groups, I think.

Sign in to add a comment