1620311 - Many TouchBar items have no AccessibilityLabel

Status: VERIFIED FIXED

(Core :: Widget: Cocoa, defect, P2)

Description

[Marco Zehe (:MarcoZ)]

STR:

1. Start Nightly and VoiceOver on a MacBook that has a TouchBar, like our MacBook Pros do.
2. Touch the items on the TouchBar.
   • Expected: VoiceOver should say for each item what they do.
   • Actual: VoiceOver speaks only the word "Button" for most of them. Only the Search or Address" and "Share" buttons have labels.

Since all of the TouchBar items get titles in front-end code, pulled in from ftl files in browser/components/TouchBar, I suspect it is something in the TouchBar widget code that causes some titles to properly end up as labels for the buttons, but some not, requiring an additional call to SetAccessibilityLabel or such. I suspect all the items that only have images might be affected, but without visual verification, I cannot be certain.

Putting this in our component for now for triage and proper assignment to the right component.

Comment 1

[Tim Nguyen :ntim]

ni? Harry to get it on his radar :)

Comment 2

[Harry Twyford]

Hm, this isn't as easy to fix as I was hoping it would be. I thought maybe we just weren't setting a label somewhere, but Apple's developer documentation for the Touch Bar (section: Accessibility and the Touch Bar) says that one needs only to set the customizationLabel property for a Touch Bar button to be accessible, which we do.

Marco, you are correct that only the buttons that only have images are affected. The image-only buttons and the buttons with a text label aren't too different programmatically. They both have underlying labels, just the image-only buttons hide the label. Their only differences are that the buttons with a label have this function run on them.

Who is the expert on macOS Accessibility? Perhaps they have some ideas as to what's going on here.

Comment 3

[Harry Twyford]

Fwiw, I ran mozregression on this, and this has been an issue since the patch that originally added Touch Bar support in bug 1313429.

Comment 4

[Morgan Reschenberg [:morgan]]

eitan and I are two halves of a whole expert maybe

:eeejay, looks like chrome does the same-ish as us in setting the attr, and they don't touch it in their mac platform file. Maybe there's some other set of functions we haven't implemented yet?

Comment 5

[Marco Zehe (:MarcoZ)]

(In reply to Harry Twyford [:harry] from comment #2)

Marco, you are correct that only the buttons that only have images are affected. The image-only buttons and the buttons with a text label aren't too different programmatically. They both have underlying labels, just the image-only buttons hide the label. Their only differences are that the buttons with a label have this function run on them.

This hiding of the label for an image worries me. Hidden labels have a tendency to not be exposed by the accessibility engine. Perhaps these buttons with hidden labels need an extra call to a SetAccessibilityLabel function instead that sets a text alternative label for such buttons, which would of course be equivalent to the title from the button objects, AKA the label that has been hidden.

Comment 6

[Marco Zehe (:MarcoZ)]

Attachment: Bug 1620311 - Set an explicit accessibility label for image-only buttons, r=harry

Comment 7

[Marco Zehe (:MarcoZ)]

Moving this to the proper component, since this is actually a case of supporting the a11y APIs from a custom native widget, not creating the API implementations.

Also cancelling NI for Eitan since I figured out the solution.

Comment 8

[BugBot [:suhaib / :marco/ :calixte]]

The component has been changed since the backlog priority was decided, so we're resetting it.
For more information, please visit auto_nag documentation.

Comment 9

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/286dc40ec81b
Set an explicit accessibility label for image-only buttons, r=harry

Comment 10

[Daniel Varga [:dvarga]]

https://hg.mozilla.org/mozilla-central/rev/286dc40ec81b

Comment 11

[Cristian Fogel [:cfogel]]

Confirmed issue with 75.0a1(20200305095541), verified fix with 76.0b6 on macOS 10.15.3.