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.

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

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

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

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.

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.

: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?

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.

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.

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

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

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