1838502 - VoiceOver announces textarea label twice

Status: RESOLVED FIXED

(Core :: Disability Access APIs, defect)

Description

[Liam DeBeasi]

Attachment: Code reproduction

Steps to reproduce:

1. Open the code reproduction in Firefox on macOS.
2. Turn VoiceOver on.
3. Tab to focus the textarea. Observe that VoiceOver reads the label twice.

Other Info:

• This does not reproduce in Chrome and Safari on macOS.
• This does not reproduce if the label and textarea are siblings linked using "for".

Actual results:

The label is read twice.

Expected results:

I expect that VoiceOver only reads the label once.

Comment 1

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

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

Comment 2

[James Teh [:Jamie]]

Is this the AXTitle/AXDescription thing biting us again?

Comment 3

[Morgan Reschenberg [:morgan]]

In a way -- I think we're duplicating the label because we're also exposing the label as the text area's AXTitleUIElement -- webkit's exposesTitleUIElement function is probably the example to follow here, since the only mention of this attr I could find in the spec is an example of what we're doing right now:

Property: AXDescription: <value> if the value is not exposed visually
Property: AXTitle: <value> if the value is exposed visually
Property: AXTitleUIElement points to accessible node matching IDREF, if there is a single referenced element that is in the accessibility tree

Comment 4

[Morgan Reschenberg [:morgan]]

blah -- upon further investigation this is actually because we're (correctly?) giving the <label> element its own AXDescription, which Safari doesn't do. The title UI element thing is also inconsistent between browsers, but it doesn't seem to be causing a/this problem :)

:Jamie dare I ask how we're supposed to do name computation on label elements...? Is giving the <label> a name equiv to its text content appropriate here?
I guess VO just doesn't want it exposed..?

Comment 5

[Eitan Isaacson [:eeejay]]

I'm going to take this as well because I think it is the same/similar to bug 1901324.

Comment 6

[Eitan Isaacson [:eeejay]]

I just tried to reproduce this on a bunch of browsers.

Steps I used:

1. Blur textarea, if it is focused
2. Put VO cursor on "Textarea label"
3. VO next into textarea

Here are the results:

• Firefox says: "Textarea label, edit text"
• Safari and Safari Tech Preview say: "Textarea label Textarea label, edit text"
• Chrome says: "Textarea label, edit text"

So it seems that this bug is in Safari but not in Chrome or Firefox.

Note: If the VO cursor is out of the doc and tab is pressed to focus the textarea Firefox will announce "Textarea label, edit text, Textarea label, group". This might be what the reporter observed. The reason VO says this is because the label element is made into a group with an AXTitle of "Textarea label".

In other browsers this group doesn't have an AXTitle. We could morph this bug to have label groups not have AXTitles, but I don't know how feasible that is.

Comment 7

[James Teh [:Jamie]]

In other browsers this group doesn't have an AXTitle. We could morph this bug to have label groups not have AXTitles, but I don't know how feasible that is.

I feel like this issue of a label having a name has come up before for Mac, but I can't recall the specifics. Even on Windows, <label>s in Chromium don't get a name. This always struck me as a bit odd, but I guess when you're poking at a label, you either care about its text content or the thing that it's labelling, so it's less useful for the label itself to have a name.

Comment 8

[Eitan Isaacson [:eeejay]]

Attachment: Bug 1838502 - Don't expose a title for labels. r?morgan

THis is what VO expects, we apparently knew that but decided it wasn't worth fixing in the past

Comment 9

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/61bf45248980
Don't expose a title for labels. r=morgan

Comment 10

[amarc]

https://hg.mozilla.org/mozilla-central/rev/61bf45248980

Comment 11

[Simona Badau, Desktop QA, PTO 13-25aug]

When verifying this issue using the latest Nightly 140.0a1 and Firefox 139.0b4 on macOS 15, I noticed the following VoiceOver announcement when focusing the Textarea label field using VO commands:

• “Textarea label, Textarea label, edit text”

This differs from what is read in Chrome and Safari, where VoiceOver announces:

• “Textarea label, edit text” - please see the recording with the behaviours of the Firefox, Safari and Chrome browsers here.

Eitan, is the repeated reading of the Textarea label in Firefox expected behavior?

Comment 12

[Eitan Isaacson [:eeejay]]

Yes. I see this too. The reason it is being read twice is different this time, and more similar to bug 1901324. I'll open another bug to address this.

Comment 13

[Simona Badau, Desktop QA, PTO 13-25aug]

(In reply to Eitan Isaacson [:eeejay] from comment #12)

Yes. I see this too. The reason it is being read twice is different this time, and more similar to bug 1901324. I'll open another bug to address this.

In this case, can we consider this as fixed? Is there anything else I can do to confirm the fix for this bug specifically?