1661923 - The label and aria-describedby properties of an input[type="file"] don't get picked up by screen-reader software, although this works in other browsers (e.g., Chrome).

Status: RESOLVED FIXED

(Core :: Disability Access APIs, defect)

Description

[pmawhorter]

Attachment: Report details + reproduction demo.

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:79.0) Gecko/20100101 Firefox/79.0

Steps to reproduce:

Load the attached minimal example.
Summary:

1. Create a <label> associated with an <input type="file">.
2. Set "aria-describedby" on the input pointing to another element w/ some text.
3. Use a screen reader and use Tab to focus the input element, or navigate normally to the input element.

Actual results:

Neither the text of the associated label nor the text of the aria-describedby element are read by the screen reader, and in the Accessibility inspector the input element does not have a description.

Interestingly, the input element is part of a grouping with the "no file selected text" and that grouping appears to have picked up the description... but navigating to the grouping delegates to the input element, so the description of the grouping is not read out. Also, the grouping and its child pushbutton (in the accessibility auditor terms) each have a warning implying that the selectability is disjoint from the interactivity. This is very likely the cause of this bug.

Expected results:

When the file input is selected, its description and associated label should both be read out by a screen reader. This works in Chrome.

Ironically, this bug would affect the "Attach a file" input in this form, except that that input has neither an associated label nor an aria-describedby property...

Note that this might be a regression of #526915, which was itself a regression. This might also be related to #1640033.

Comment 1

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

Bugbug thinks this bug should belong to this component, but please revert this change in case of error.

Comment 2

[Asa Dotzler [:asa]]

Confirming report. Firefox+NVDA does not read the "Label text (not read)." in the attached testcase while Chrome+NVDA does.

Comment 3

[Alice0775 White]

Regression window(The problem was reproduced for the first time):
https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=72cf0adcfb2796c1e7b439e1851144fb818e1469&tochange=3ec29dee6402e578254adf74c0e700c9cab3f1c4

Comment 4

[James Teh [:Jamie]]

The label is read as expected if the label is associated using <label for=...> (fixed in bug 1316965), but not if it wraps the element. The reason for that failure is probably the same as bug 1656769 comment 1 and probably has the same fix.

Note that exposing the file input as a grouping containing a button (as opposed to Chrome's single button) is a deliberate choice and is not a bug. Screen readers should read the grouping ancestor when focus moves inside a grouping. That said, I notice NVDA does have a bug where it won't read the description of a grouping ancestor in browse mode, though this works fine in focus mode.

Comment 5

[pmawhorter]

I can verify that adding an ID to the input element and putting that ID into the for= attribute of the label (even without changing the structure so the label still contains the input element) does cause the label text to be read correctly. However, the associated aria-describedby value is still not read, because it's placed on the group, not on the button.

I can also confirm that in VoiceOver, this behavior is also different between modes: when using Tab to navigate to the button, the behavior described above happens, but when using the arrow keys to navigate onto the button, the group is hit first, and when the group is selected, both the label text and the aria description are read.

Given that apparently neither NVDA nor VoiceOver pick up the grouping description when navigating onto the button, even if there's a standard that specifies it should, that standard doesn't seem to be reliable and/or widely implemented? In particular, when navigating with VoiceOver from the label forwards, if the grouping has a name attribute in the accessibility inspector, the navigation pauses on the group and reads out the name and the description. But if it doesn't have a name attribute, even when a description is present, navigation goes straight inside to the button, and the group is not treated as a stopping point for reading at all.

I wonder if it might be useful to do one or more of:

1. Give the generated grouping a default name value if none is provided via a label, such as "file upload". In particular, with no labeling or ARIA tags, the default button text is simply "Browse," which does not go very far towards suggesting what the button actually does. Giving the grouping a name value might also prompt NVDA and/or VoiceOver to stop on that node during traversal and actually read out the aria-describedby property.
2. Duplicate the description property from the group and apply it to the button as well. That way, when navigating via tab, users will hear the description. As far as I can tell, at least in VoiceOver, the actual implementation of "read the grouping ancestor" reads only the name attribute, not the description attribute, and if that's true, then there's currently no way in FF to apply a description to a file input element that will be read out when navigating to it via tab.
3. Place the description for an input element, but not the name, onto the button itself inside the group instead of onto the group. If screen readers aren't going to read the description of the group when the button is focused using tab, it would seem to be safer to put the description on the button. And someone navigating without tab would still hear the label text via the group (which VoiceOver does read), and get the description when they navigate inside onto the button, which seems fine in terms of UI?
4. In the accessibility tree, I can see that the grouping contains the button + the label that specifies the filename, which starts out as "No file selected." However, that label doesn't get associated with the button in any reasonable way. Perhaps as a default when no other description is provided, the built-in label could be placed into the description slot of the button element? Then a screen reader should read out "Browse, no file selected" instead of just "Browse" on focusing the button when no ARIA content or labels have been provided, which would IMO be a step up from just "Browse."

I'm still unclear as to how as a developer I should foreground validation items associated with a file upload input using the Firefox setup, even assuming no bugs in voiceover programs, although now I've got a better appreciation for why the group is being used, and it makes sense to me that it should be.

Putting aria-describedby on the input element is what I think should be the way to do this, but if that doesn't result in an associated description which is read out when tabbing onto the button, it seems like there should be another way to get that behavior.

Sadly I'm not an expert on this stuff; if someone can point me at the spec where the behavior of reading out the ancestor grouping of an element is defined, I'd be happy to look into it to see what it says about reading the name vs. name + description of the ancestor.

Comment 6

[Dianna Smith [:diannaS]]

:jamie can you take a look at this and see if there is a bug still occurring in here to track and if so, is it still an S2?

Comment 7

[James Teh [:Jamie]]

This bug is still valid. It's been triaged as an s2 because it might mean that important information is not exposed to users in some cases and there might not be a workaround. That said, it's difficult to gauge whether this actually hurts users in daily usage.

Comment 8

[Andrew N]

I would argue that it does hurt users in daily usage. Content authors are going to want to put important information on pages with file inputs, and they're going to want to expose that information to screen reader users. Screen reader users using Firefox are going to miss that important information.

Comment 9

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

Set release status flags based on info from the regressing bug 1226000

Comment 10

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

:surkov, since you are the author of the regressor, bug 1226000, could you take a look?
For more information, please visit auto_nag documentation.

Comment 11

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

Set release status flags based on info from the regressing bug 1226000

Comment 12

[Maire Reavy [:mreavy]]

Hey Jamie, I'm looking at all open S2 bugs as we head into Q4. Is this bug still valid, is it still an S2, and if so, what's the path forward here to fix it? Could this be a "good first bug" for a strong programmer who is new to a11y? Thanks.

Comment 13

[James Teh [:Jamie]]

Sorry for the delay, Maire.

This is considered an s2 because it prevents a user from easily accessing potentially important information. This hasn't been worked on because honestly, it's unclear what the "correct" path forward is. In the absence of an obviously correct path, I think I'm going to need to just pick a path, knowing it won't be perfect.

Implementation thoughts: Given that we're dealing with bugs in various screen readers here that aren't likely to be fixed any time soon, I think it might be simplest just to get rid of the group and have a button like Chromium does. The label for said button would incorporate the label provided by the author, or if there isn't one, the Browse button label. It would also include the file name. The description would be as specified by the author. I haven't looked into how this would be implemented yet, so the plan might change depending on any feasibility issues I might discover.

Comment 14

[James Teh [:Jamie]]

Attachment: Bug 1661923: Expose file input as a button in the a11y tree rather than a group.

A file input contains two native anonymous children: the Browse button and the file name label.
Previously, we exposed the file input as a group in the a11y tree and its anonymous children as children of that group.
While this is semantically correct, it causes several problems for screen readers.
First, if the author provides a label or description, that gets exposed on the group.
Some screen readers ignore either one or the other depending on the screen reader, what the author specified and how the user navigated there.
Second, the file name label isn't focusable and wasn't associated to the group in any way aside from being a child.
This meant that a screen reader user might not perceive it in some cases.

Since most users understand a file input as a single control anyway, we now just expose the input as a simple button containing two text leaves.
However, unlike most buttons, we need to append the text to the name even if the author specifies a name.
As a bonus, this simplifies some code, since we no longer need to redirect focus or events.

An additional problem was that the file input previously returned false for LocalAccessible::IsWidget, which meant that a wrapping HTML label wasn't associated correctly.
This has been fixed as well, although this fix could have applied just as easily to the previous group implementation.

Comment 15

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/9e0814d9dc09
Expose file input as a button in the a11y tree rather than a group. r=eeejay

Comment 16

[Narcis Beleuzu [:NarcisB]]

https://hg.mozilla.org/mozilla-central/rev/9e0814d9dc09

Comment 17

[James Teh [:Jamie]]

This significantly changes behaviour that has been around for a long time, so I'd like this to bake for longer. Thus, we should not consider uplifting this to 120.