Skip to content

LG-8398 Update screen reader to read headings after user searches for an address#7500

Merged
eileen-nava merged 2 commits intomainfrom
em/8398-update-screen-reader
Dec 16, 2022
Merged

LG-8398 Update screen reader to read headings after user searches for an address#7500
eileen-nava merged 2 commits intomainfrom
em/8398-update-screen-reader

Conversation

@eileen-nava
Copy link
Copy Markdown
Contributor

🎫 Ticket

Update screen reader implementation

🛠 Summary of changes

If the user searches for an address on the "Select a location to verify your ID" page.....

  • the screen reader will maintain the user's place on the page
  • if there are no results returned, then the screen reader will read the heading "Sorry, there are no participating Post Offices..."
  • if results are returned, then the screen reader will read the heading "There are %{count} participating Post Offices within 50 miles...."

📜 Testing Plan

  • Navigate to the "Select a location to verify your ID" page
  • Turn on Voiceover (Command + F5 on macs)
  • Search for an address in the search box and watch the screen reader work

👀 Screenshots

If relevant, include a screenshot or screen capture of the changes.

Screen recording of a search with results returned:
SearchReturnsResults_Reader.mov
Screen recording of a search with no results returned:
SearchReturnsNoResults_Reader.mov

Copy link
Copy Markdown
Contributor

@NavaTim NavaTim left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Might be nice to have a good test for this, but otherwise looks good.

return (
<>
<h3>{t('in_person_proofing.body.location.po_search.none_found', { address })}</h3>
<h3 role="status">
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It may behave differently depending on specific screen readers, so we could test to check, but my understanding of live regions is that they must be present on the page before adding the content that we want to be announce, since it's "live" in the sense that it announces changes to the content. Typically this would be at page load, but that's impractical for how our React application works.

The error container must be present in the DOM on page load for the error message to be spoken by most screen readers.

https://www.w3.org/TR/WCAG20-TECHS/ARIA19.html#ARIA19-examples

If testing shows that this works okay as-is, maybe not worth worrying too much over. Otherwise, maybe we adjust the rendering so that the live region is always present (but non-visible) from beginning to end of the searching process, and we add the text once the result is available.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This worked as-is on Mac Voiceover, but I didn’t test it with other screen readers. I’ll do a timeboxed investigation into testing it for other screen readers.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Update: I tested on a second screen reader, the Chrome extension screen reader, and the code worked as is. I am going to merge this.

@eileen-nava eileen-nava merged commit dc20140 into main Dec 16, 2022
@eileen-nava eileen-nava deleted the em/8398-update-screen-reader branch December 16, 2022 15:41
@aduth aduth mentioned this pull request Dec 19, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants