1838502 - VoiceOver announces textarea label twice

Status: UNCONFIRMED

(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 1838502.