1316965 - Associated label of file upload field (input type=file) in Firefox is not read by screen reader

Status: VERIFIED FIXED

(Core :: Disability Access APIs, defect, P1)

Description

[Vimalan Sakthivel]

Attachment: FileInput_Label_Not_exposed_to_AT.png

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/54.0.2840.71 Safari/537.36

Steps to reproduce:

I have a fileinput field (input type="file") and an associated label (for & ID). When I focus on the file input field, the associated label is not read by the screen reader. This code works as expected on google chrome. 


Actual results:

The associated label is not read by the screen reader. 


Expected results:

The label should be read by the screen reader when the focus is on the file input field.

Comment 1

[Vimalan Sakthivel]

Hi, We have a critical Accessibility issue on our site due to this bug. Could someone look into this ASAP?

Comment 2

[Loic]

Marco, can you check this issue, please.

Comment 3

[Marco Zehe (:MarcoZ)]

The problem is that we do associate the label to the parent of the Browse... button, but the accessible we associate this to is an ordinary text frame, not a grouping element. If this were a grouping, like groupbox, screen readers would pick it up automatically when tabbing to the browse button.

In Chrome, the label is directly associated to the button as its accessible name, overriding the default of Browse...

I actually would like our approach better, since it makes clear that the button opens a browse dialog to search for the file.

Alex, any thoughts?

Comment 4

[alexander :surkov (:asurkov)]

I'd say we should reach the AT vendors, since some of the screen readers rely on the accessible tree structure we expose, and thus the bug may be considers as their bug. Alternatively we could put the label on 'Browse' button and concatenate it with 'Browse' text.

Comment 5

[alexander :surkov (:asurkov)]

hm, what screen readers are affected, VoiceOver only?

Comment 6

[Marco Zehe (:MarcoZ)]

NVDA, which is what I reproduced it with.

Comment 7

[alexander :surkov (:asurkov)]

Jamie, your thinking?

Comment 8

[James Teh [:Jamie]]

I agree with comment 3. I think the parent should have a role of grouping instead of text frame. That *should* be fine for all existing AT (in theory), since that's how fieldset/legend is exposed.

Comment 9

[alexander :surkov (:asurkov)]

(In reply to James Teh [:Jamie] from comment #8)
> I agree with comment 3. I think the parent should have a role of grouping
> instead of text frame. That *should* be fine for all existing AT (in
> theory), since that's how fieldset/legend is exposed.

iirc, JAWS had a dependency on a role. We could do the sniffing role substitution for them, if the role change approach is a right thing.

Comment 10

[James Teh [:Jamie]]

If it turns out that this does break some AT, I could live with the method you suggested in comment 4. It's a tiny bit ugly, but so is life... and we only have one focusable child here, so it's not like it's duplicating information too much.

Comment 11

[alexander :surkov (:asurkov)]

(In reply to alexander :surkov from comment #9)
> (In reply to James Teh [:Jamie] from comment #8)
> > I agree with comment 3. I think the parent should have a role of grouping
> > instead of text frame. That *should* be fine for all existing AT (in
> > theory), since that's how fieldset/legend is exposed.
> 
> iirc, JAWS had a dependency on a role. We could do the sniffing role
> substitution for them, if the role change approach is a right thing.

I've got thumb up from them for a change. So we can go with the group role.

Comment 12

[herinnisha]

Voting to fix as high priority.

Comment 13

[James Teh [:Jamie]]

Attachment: Bug 1316965: Give file inputs an a11y role of GROUPING so screen readers report their label when focus enters them.

Comment 14

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/606bb262818f
Give file inputs an a11y role of GROUPING so screen readers report their label when focus enters them. r=MarcoZ

Comment 15

[Oana Pop-Rus]

https://hg.mozilla.org/mozilla-central/rev/606bb262818f

Comment 16

[James Teh [:Jamie]]

Verified fixed in Firefox 71 nightly 20190923215658.

Comment 17

[James Teh [:Jamie]]

Comment on attachment 9093758 [details]
Bug 1316965: Give file inputs an a11y role of GROUPING so screen readers report their label when focus enters them.

Beta/Release Uplift Approval Request

• User impact if declined: Screen reader users won't know the label of a file input field when tabbing to it.
• Is this code covered by automated tests?: Yes
• Has the fix been verified in Nightly?: Yes
• Needs manual test from QE?: No
• If yes, steps to reproduce:
• List of other uplifts needed: None
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): Straightforward patch which only changes the role (a single property) exposed for file inputs for accessibility.
• String changes made/needed:

Comment 18

[Liz Henry (:lizzard) (relman/hg->git project)]

Comment on attachment 9093758 [details]
Bug 1316965: Give file inputs an a11y role of GROUPING so screen readers report their label when focus enters them.

Accessibility fix, verified in nightly, let's uplift for beta 11.

Comment 19

[Daniel Varga [:dvarga]]

https://hg.mozilla.org/releases/mozilla-beta/rev/256e2d1a8ed5

Comment 20

[Rares Doghi, Desktop QA]

Hi, This issue is Verified as Fixed in Firefox Beta 70.0b11 on Windows 7.