Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

USWDS - Feature: Enhance screen reader callouts for Validation component #5841

Open
mahoneycm opened this issue Mar 27, 2024 · 1 comment · May be fixed by #5897
Open

USWDS - Feature: Enhance screen reader callouts for Validation component #5841

mahoneycm opened this issue Mar 27, 2024 · 1 comment · May be fixed by #5897
Labels
Affects: Accessibility 🟡 Relates to the accessibility of our components Package: Validation Role: Dev Development/engineering skills needed Type: Feature Request New functionality
Milestone

Comments

@mahoneycm
Copy link
Contributor

mahoneycm commented Mar 27, 2024

Is your feature request related to a problem? Please describe.

Follow up to #5760 & #5835.

If a screen reader user navigates via the tab key, they will arrive on the validation component input without being made aware of the validation requirements.

Describe the solution you'd like

Screen readers should call out the requirements of a validation import upon arrival to the component, similar to the way they are updated upon input change.

Describe alternatives you've considered

Before #5835, the checklist items dynamically set tabindex which would allow them to become focused via tab.

We decided this was unexpected behavior in #5760 and decided to remove. Focus states should be reserved for interactable elements only.

Additional context

There is an usa-sr-only element that gets updated with the validation state on input change but is empty upon initialization. We should explore ways to allow this span to be pre-populated with the validation requirements on init.

There are various functions we could access via validate() that will allow us to resolve this issue.

Methods tested to update the sr-only span on initialization

We can populate the screen reader span by running the validate() function on init. We could alternatively look into setting the sr-only text content on createInitialStatus().

However, I noticed that with VoiceOver, users had to use a "more information" command in order for the span to be read.

I tried replacing aria-describedby with aria-labelledby which will allow the requirements to be read without the more information command but this replaces the validation label (i.e. "code" in our component example) which I feel we should avoid.

I was also able to run validate() on focus, which appropriately updates and reads the sr-only span the first time the element is focused, but it is not read on any subsequent focus. I believe this is due to the status of the input/validation not changing. This behavior is consistent with text input behaviors where the status gets read out only if/when it changes.

For example, if you enter a number, the screen reader will read out the number requirement as complete. It will not read the number requirement status again unless the number is removed or another validation requirement is met.

While this is fine for input changes, it seems problematic for focus behaviors if users miss the validation requirements the first time they visit the input. It also seems a bit heavy-handed to call every time the component is focused.

@mahoneycm mahoneycm added the Type: Feature Request New functionality label Mar 27, 2024
@github-actions github-actions bot added the Status: Triage We're triaging this issue and grooming if necessary label Mar 27, 2024
@mahoneycm mahoneycm added Affects: Accessibility 🟡 Relates to the accessibility of our components Needs: Discussion We need to discuss an approach to this issue Role: Dev Development/engineering skills needed Package: Validation labels Mar 29, 2024
@mejiaj mejiaj removed the Status: Triage We're triaging this issue and grooming if necessary label Apr 11, 2024
@mejiaj mejiaj added this to the uswds 3.8.1 milestone Apr 11, 2024
@mejiaj mejiaj added Added during Sprint and removed Needs: Discussion We need to discuss an approach to this issue labels Apr 11, 2024
@mejiaj
Copy link
Contributor

mejiaj commented Apr 16, 2024

  • @mahoneycm to add additional notes to the description. Includes findings & potential solutions.

CM: Added additional notes to the PR description

@amyleadem amyleadem modified the milestones: uswds 3.8.1, uswds 3.9.0 May 6, 2024
@amyleadem amyleadem removed their assignment May 30, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Affects: Accessibility 🟡 Relates to the accessibility of our components Package: Validation Role: Dev Development/engineering skills needed Type: Feature Request New functionality
Projects
Status: Scheduled
Development

Successfully merging a pull request may close this issue.

3 participants