Accessibility testing of Services Autosuggest prior to usability research

[jilladams]

Description

Must: If you decide to build your own combobox component separate from what's already underway in the design system, make sure it has all of the accessibility functionality it needs to be functional for expected keyboard actions and have everything announced to screen reader users. The work done by the 526ez team is a great place to start. I'll also point to this blog post from Pope Tech, especially the sections on required keyboard actions and required ARIA roles, states, and attributes.

This testing should happen prior to usability research.
We will need a separate ticket to test again after research / any revisions / before Staging review & ship.

User story

Describe the audience/user, enhancement or fix, and value / outcome desired.

AS A user who depends on assistive technologies (such as screen readers and keyboard navigation)
I WANT the combobox component to be fully accessible, with correct keyboard interactions, ARIA roles, and attributes
SO THAT I can interact with the combobox seamlessly and without obstacles, ensuring it complies with WCAG and accessibility guidelines.

Testing & QA

This ticket includes running the test plan developed for Services autosuggest as well as running automated accesibility testing.

Acceptance criteria

• Any a11y notes / feedback from Midpoint Review - Accessibility Feedback - Sitewide Facilities: Facility Locator Services Autosuggest + Progressive Disclosure va.gov-team#101887 have been addressed
• Services autosuggest build passes all a11y tests before research

[jilladams]

From @Shamiaalam re: Address autosuggest / Services autosuggest component: https://dsva.slack.com/archives/C0FQSS30V/p1738197794286629?thread_ts=1738127976.004369&cid=C0FQSS30V

given the changes in Downshift v9, we should test how different screen readers handle role="combobox" before deciding whether to reintroduce aria-live. If screen readers are announcing updates effectively, adding aria-live could be redundant or even cause conflicting announcements. Let’s validate with screen reader to ensure the best user experience.
Correct in my opinion, if all elements in the combobox are already in the DOM, using aria-setsize and similar attributes isn’t necessary. These attributes are typically useful when items are dynamically loaded or when a screen reader needs to understand the total number of options. We should test to confirm that screen readers are handling the list correctly without them.