Closed Bug 1316965 Opened 8 years ago Closed 5 years ago

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

Categories

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

Product:
Core
Component:
Disability Access APIs
Version:
49 Branch
Type:
defect

Tracking

()

Status:
VERIFIED FIXED
Milestone:
mozilla71
Tracking Flags:
Tracking Status
firefox70 --- verified
firefox71 --- verified

People

(Reporter: vimalan.sakthivel, Assigned: Jamie)

References

(Blocks 1 open bug,
URL
)

Details

(Keywords: access, testcase)

Attachments

(2 files)

FileInput_Label_Not_exposed_to_AT.png
(deleted), image/png
Details
Bug 1316965: Give file inputs an a11y role of GROUPING so screen readers report their label when focus enters them.
(deleted), text/x-phabricator-request
lizzard
: approval-mozilla-beta+
Details
Attached image FileInput_Label_Not_exposed_to_AT.png (deleted) —
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.
Component: Untriaged → Layout: Form Controls
Keywords: access, testcase
Product: Firefox → Core
Version: 38 Branch → 49 Branch
Summary: file input field doesn't expose the associated label to AT → Firefox doesn't expose file input field's associated label to AT
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
Component: Layout: Form Controls → Disability Access APIs
Hi, We have a critical Accessibility issue on our site due to this bug. Could someone look into this ASAP?
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)
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)
hm, what screen readers are affected, VoiceOver only?
NVDA, which is what I reproduced it with.
Jamie, your thinking?
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: needinfo?(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.
Flags: needinfo?(jamie)
(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.
(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.
Voting to fix as high priority.
Assignee: nobody → jteh
Priority: P3 → P1
Pushed by mzehe@mozilla.com: 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

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

Status: NEW → RESOLVED
Closed: 5 years ago
status-firefox71: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla71

Verified fixed in Firefox 71 nightly 20190923215658.

status-firefox71: fixed → verified

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:
Attachment #9093758 - Flags: approval-mozilla-beta?

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.

Attachment #9093758 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
Flags: qe-verify+
QA Whiteboard: [qa-triaged]

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

QA Whiteboard: [qa-triaged]
status-firefox70: fixed → verified
Flags: qe-verify+
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: