search

w3c / html-aria

ARIA in HTML
https://w3c.github.io/html-aria/
Other
181 stars 49 forks source link

Clarification, if the input type="file" should allow role of button #126

Closed cpandhi closed 5 years ago

cpandhi commented 5 years ago

According to the ARIA in HTML https://www.w3.org/TR/html-aria/#docconformance

has no implied role: or allowed role. Yet the Chrome browser classifies this element as a button in the accessibility tree.
scottaohara commented 5 years ago

giving this a quick look, yes it appears that chrome is surfacing this input as a push button. though i question if that's correct, since the button is merely one part of this input's shadow dom. Testing with JAWS and VoiceOver, chrome does not correctly expose the currently selected file portion of this input.

Other browsers also will surface the push button, but again, as a child of the input and not as the input itself, which is either exposed as an accRole = input, if a role is exposed at all.

@stevefaulkner, thoughts on this? I'm looking at this as incorrect behavior from Chrome, but would appreciate a double check.

asurkov commented 5 years ago

Firefox exposes input@type="file" as a generic accessible object containing a button accessible and a label for it. Having said that I guess the spec shouldn't prohibit Chrome from shrinking a tree to a single button, of course if doesn't prevent them to fix input@type="file" accessibility issues.

cc'ing @aleventhal

tombrunet commented 5 years ago

Firefox notes the value of the file input as a label, but doesn't say what it's for. Semantically, the Chrome implementation seems more correct to me - the selected file is returned as the button value, and the button text is the name. Vs. Firefox where the button and value seem to not be related, and the value is marked as a label.

scottaohara commented 5 years ago

Just for comparison's sake, https://codepen.io/scottohara/full/aXmxrN

In Chrome: MSAA / IA2: accRole / Role: push button accName / Name: associated label text or "choose file" if unlabelled accValue / Value: - file name or "no file chosen"

Testing with JAWS, NVDA, VO, the no file selected / file name is not announced when using Chrome, with the exception of NVDA if in forms mode.

In Firefox: The wrapping input is exposed as: MSAA / IA2: accRole / Role: input / text frame accName / Name: associated label text or nothing if no label supplied

The push button is then provided the accName of "browse..." regardless of file chosen or not, or if the input has an associated label.

The "no file selected" / file name is consistently treated as text and available to JAWS/NVDA. The manner in which each screen reader treats the text is different. NVDA will announce the file name when navigating to the input with tab or the virtual cursor. JAWS will require someone to navigate to the file name with the virtual cursor to announce it.

Presently, if one were to add a role=button to the file input, there'd be some duplicate "button" announcements in NVDA + Firefox, but testing with other screen readers / browsers, there doesn't appear to be any other adverse affects here.

Actually, adding the role="button" to the wrapping input appears to help Chrome actually announce the currently selected file name with NVDA w/out needing to be in forms mode. Chrome and JAWS 2019 still won't announce the selected file name.

stevefaulkner commented 5 years ago

@cpandhi the mapping is derived from the implementations refer to https://w3c.github.io/html-aam/#el-input-file In cases where there is no implicit role parity accross browsers there is no implied role.