New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 687621 link

Starred by 5 users

Issue metadata

Status: Assigned
Owner:
Last visit > 30 days ago
Components:
EstimatedDays: ----
NextAction: ----
OS: Mac
Pri: 2
Type: Bug
Team-Accessibility



Sign in to add a comment

Accessibility - Select Label not being read out when voiceover enabled

Reported by aba...@salesforce.com, Feb 1 2017

Issue description

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

Steps to reproduce the problem:
1. Create a select element with the corresponding label. Be sure to include the "for" attribute in the label element with the corresponding "id" attribute in the select element.
2.  On Mac, make sure "Voiceover" is on.
3.  Tab to the select element, and notice that the label is NOT read

What is the expected behavior?
When tabbing to the select element, the label should be read.

What went wrong?
On the left I have Chrome open, and on the right, I have Firefox open. You'll notice when I tab to the select element in Chrome, voiceover displays "Amsterdam, Menu item". When I tab to the select element in Firefox, voiceover displays "Amsterdam, Choose your favorite city? pop-up button".

The problem is that Google Chrome is not reading out the label, so an impaired user is told which option is selected, but doesn't have any context on what the menu is for.

Did this work before? N/A 

Does this work in other browsers? Yes

Chrome version: 56.0.2924.76  Channel: stable
OS Version: OS X 10.11.6
Flash Version: Shockwave Flash 24.0 r0

I've also tried adding "aria-labelledby" and "aria-describedby" to the select element, setting those equal to the id of the label, which did produce the desired effect.

 
bugreport.mov
7.8 MB Download
selectLabel.html
837 bytes View Download

Comment 1 by tkent@chromium.org, Feb 1 2017

Components: -Blink>Forms UI>Accessibility
Owner: nek...@chromium.org
Status: Untriaged (was: Unconfirmed)
nektar@, what do you think?
Clarification: My last line in the initial message should have read: 
"I've also tried adding "aria-labelledby" and "aria-describedby" to the select element, setting those equal to the id of the label, which did **NOT** produce the desired effect."
Took a quick look.

If you navigate to the select element via VoiceOver keys (Ctrl+Option+Left/Right) it works fine. So the bug isn't with <label> or with <select>, it's with the event that Chrome fires when you press Tab to focus a select element.

It looks like Chrome is firing the focus event on the menu item rather than on the select element, and that's confusing VoiceOver.

The fix may be to ignore activedescendant tracking on the browser side when a pop-up button is collapsed.

This is *probably* Mac-specific.

Tabbing to selects in Chrome on Windows with NVDA is also behaving a bit 
strangely. Not sure if it is related.


On 2/2/2017 3:52 PM, dmazz… via monorail wrote:
Status: Assigned (was: Untriaged)
Labels: NewComponent-Accessibility-Compatibility
Labels: NewComponent-Accessibility
Components: UI>Accessibility>Compatibility
Components: -UI>Accessibility
Labels: -newcomponent-accessibility-compatibility -newcomponent-accessibility
can you try adding role="combobox"? I didn't try it on MAC but it solves the same Narrator issue on Windows.

Comment 12 Deleted

Status: Available (was: Assigned)
I'm seeing this issue on Windows, as well.

Screen reader + browser combinations I've tested:
- NVDA 2017.3 + Chrome 62.0.3239.84 (Windows): reads label as expected
- JAWS 18 + Chrome 62.0.3239.84 (Windows): doesn't read label
- VoiceOver + Chrome  62.0.3202.94 (OS X, 10.12.6): doesn't read label

Here is the CodePen I've been using for testing:
https://codepen.io/cordelia/pen/bYPYrj
Labels: a11y-secondary
Status: Assigned (was: Available)

Sign in to add a comment