USWDS - File input: Fix issues with voice command #5213
Conversation
…ons to let at top of function
… to removeOldPreviews params
|
@briandeconinck I have created a prototype here that changes the This is still a work in progress but before I get too far down the road, would you be able to test this prototype to see if you can access the input by speaking the visible text via Dragon Naturally Speaking (and/or any other voice control software you might have access to)? Please let me know if you have questions! |
|
Hi Amy! Sorry for the slow reply. I see the updated I will note that since the instruction text has the fake-link styling, the command "Click link" still doesn't highlight the input as an option, which would typically be the next thing I try if "Click choose from folder" doesn't get a match. Maybe make it an actual link or button with a JS action to map it to the input? I believe even if it's removed from the tab order with Up to you whether you want to pursue that. What you have here is definitely an improvement and should work most of the time for Dragon users (again, accounting for possible Dragon weirdness). |
|
Thanks for the response, @briandeconinck! Your test results are helpful. Since we aren't hitting consistent results with |
|
Note: considering removing the SR-only element readout if file input is disabled. Might determine that no action is needed or it could be a follow-up issue. Will investigate tomorrow. There is no need for this effort to interrupt any reviews in process. |
|
I added a check for the |
| /Edge\/\d./i.test(navigator.userAgent) | ||
| ) { | ||
| fileInputParent.querySelector(`.${DRAG_TEXT_CLASS}`).outerHTML = ""; | ||
| } |
There was a problem hiding this comment.
On enhance file input will add a class if the component either has aria-disabled or disabled attribute.
|
@mejiaj I confirmed that your update adds the disabled class as expected when either Will you let me know if you see anything else? |
There was a problem hiding this comment.
Code looks good, I just have a comment on addPreviewHeading(). This function adds a description for screen readers for how many files and their names.
On voiceover this only gets read once after upload. We could improve this by having it be read on focus as a fast follow-up.
| * @param {HTMLInputElement} fileInputEl - The input element. | ||
| * @param {Object} fileNames - The selected files found in the fileList object. | ||
| */ | ||
| const addPreviewHeading = (fileInputEl, fileNames) => { |
There was a problem hiding this comment.
This function adds text describing:
- How many files
- Which files have been uploaded
So far I've only gotten it to read after initial upload. If I move to another area and comeback it doesn't get read on VoiceOver Chromium 113.
Possible Future enhancements:
- Add a unique ID to this message and tie it to the component via
aria-labelledby[MDN on aria-labelledby] - Move the preview heading text so it always gets read.
- Dynamically update the aria-label
Move the preview heading text example
Summary
Improved the file input experience for voice command and screen reader users. Voice command users can now more easily interact with the component by speaking the visible instructions text. Additionally, screen reader users now have access to both the visible instructions text (in the
aria-label) and the file selection status (in a newly created screen reader-only element).Breaking change
This is not a breaking change.
All changes have been handled dynamically.
Related issue
Closes #5192
As a future enhancement, issue #5238 will create data attributes that will allow users to customize the status and instructions text.
Related pull requests
Changelog update: uswds/uswds-site#2088
Preview link
Preview link: File input
Problem statement
Users of assistive technologies should be able to intuitively access all form elements, understand what action they should take, and receive feedback so that they can confirm that the information they have added is correct. However, the file input component presents problems for both screen reader and voice command users:
Voice command issues
Because of file input's structure, voice command does not work in an intuitive way. A user would expect to vocalize the text shown on screen as part of a "Click" command. For file input, this would mean the user would expect to say something like "Click drag file here or choose from folder" or ""Click choose from folder" to interact with the file input. However, neither of these work because the accessibility tree does not include this information.
Screen readers issues
Screen reader users do not have access to the instructions text ("Drag file here or choose from folder"). Instead, the
aria-labelprovides feedback on the file selection status. This is insufficient information for interaction. The defaultaria-label"no file selected" does not clearly communicate what the input is or what the user should do, which can lead to confusion.Solution
To allow voice command users to easily access the file input component, we should make sure the input
aria-labelmatches the visible text as the status changes.To allow screen reader users to continue to confirm their file selection, we should move the file status from the
aria-labelto a dynamically createdsr-onlyelement.Major changes
buildFileInput()into separate functions:createTargetAreaandcreateVisibleInstructionsPossible future enhancements
Converting the CTA text ("choose from folder", "change file") from a
<span>element to a<button>element might improve consistency in Voice Command software. It could also give an alternative method for voice control users so that they can highlight all interactive elements on the page and select the element they want to click.Testing and review
Accessibility:
Developers:
The following items should be confirmed: