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

NEW
Unassigned

Status

()

Core
Disability Access APIs
P3
normal
a year ago
2 months ago

People

(Reporter: Vimalan Sakthivel, Unassigned)

Tracking

(Blocks: 1 bug, {access, testcase})

49 Branch
access, testcase
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(1 attachment)

(Reporter)

Description

a year ago
Created attachment 8809942 [details]
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.
(Reporter)

Updated

a year ago

Updated

a year ago
Component: Untriaged → Layout: Form Controls
Keywords: access, testcase
Product: Firefox → Core
(Reporter)

Updated

a year ago
Version: 38 Branch → 49 Branch
(Reporter)

Updated

a year ago
Summary: file input field doesn't expose the associated label to AT → Firefox doesn't expose file input field's associated label to AT
(Reporter)

Updated

a year ago
Summary: Firefox doesn't expose file input field's associated label to AT → Associated label of file upload field (input type=file) in Firefox is not read by screen reader

Updated

a year ago
Component: Layout: Form Controls → Disability Access APIs
(Reporter)

Comment 1

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

Comment 2

a year ago
Marco, can you check this issue, please.
Flags: needinfo?(mzehe)
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?
Flags: needinfo?(mzehe) → needinfo?(surkov.alexander)

Comment 4

a year ago
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.
Flags: needinfo?(surkov.alexander)

Comment 5

a year ago
hm, what screen readers are affected, VoiceOver only?
NVDA, which is what I reproduced it with.

Comment 7

a year ago
Jamie, your thinking?
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: needinfo?(jamie)

Comment 8

a year ago
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.
Flags: needinfo?(jamie)

Comment 9

a year ago
(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.
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.

Updated

11 months ago
Blocks: 389237

Comment 11

9 months ago
(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.
Priority: -- → P3

Comment 12

2 months ago
Voting to fix as high priority.
You need to log in before you can comment on or make changes to this bug.