508-enhancement [MOBILE DESIGN]: Consider iterating typeahead UX pattern for mobile screen reader users

[1Copenut]

Feedback framework

• ❗️ Must for if the feedback must be applied
• ⚠️ Should if the feedback is best practice
• ✔️ Consider for suggestions/enhancements

Definition of done

1. Review and acknowledge feedback.
2. Fix and/or document decisions made.
3. Accessibility specialist will close ticket after reviewing documented decisions / validating fix.

Point of Contact

VFS Point of Contact: Josh, Angela, Trevor

User Story or Problem Statement

As a relatively new mobile screen reader user, I want suggested search results to remain on screen after I press the "Done" button on the iOS keypad.

Details

While testing the typeahead in iOS with VoiceOver turned on, I noticed the suggested results disappeared as soon as I pressed the Done button. I'm not sure this is a bad UX; I'm also not sure it's not. I'm opening this as a spike ticket for iterating on the UX if the team proceeds with user research suggested in 20719.

I like the Vue Autocomplete because I can swipe right with the keypad still open to move to the suggested results. This is not meant to be prescriptive, just an example of alternative UX.

Related Issue: downshift-js/downshift#779

Acceptance Criteria

• Autocomplete maintains current behavior EXCEPT
• iOS users can swipe right with the keypad open and under focus, to view search results

[denisecoveyduc]

FYI - @1Copenut @joshkimux @AngelaFowler82 Adding this write up about the downshift implementation that we implemented for typeahead. Closing this issue as a result. cc: @srsuddath

Our current implementation of Typeahead has a couple key requirements that resulted in our implementation choices. We need to be able to track the suggestions a user receives, what their query is, and whether they used the suggestions presented
we need to meet accessibility standards for usability.
The original proposed implementation for Typeahead was to use a Datalist, however this component does not allow for custom event handlers, which did not meet many of our analytics requirements for this feature.

As a result, we had two options:

The first was to create a custom component to be owned and maintained by va.gov to implement typeahead in such a way that would meet analytics and accessibility requirements
The second was to use the 3rd party component DownShift, which had previously been used on VA.gov for a typeahead experience.
Due to this product being a POC, the decision was made to use Downshift, rather than sped the time required to build a custom component from scratch, saving us a LOT of time in approvals and streamlining the release process.

However, Downshift lacks a large number of customization options, and obfuscates a lot of functionality from the developer (certain elements can't have event listeners added to them, or cannot be interacted with from outside of the component). It is because of these quirks that many of the "Nice to have" features are not an option for us currently.

Additionally, because the downshift component hides a lot of its interior elements, there are some functionalities that might "flake out" due to the component loading, such as focusing the input field on clicking the search menu button.

There are talks about creating a unified sitewide search, and as part of that process a more robust "custom" typeahead component would be designed and built that would allow for many of these features to exist.

[joshkimux]

Reopening this and attaching it to the full 508 office ticket for awareness. I'll remove this from the staging review ticket 👍

[denisecoveyduc]

During our team discussion today we agreed that this is not an issue we will move forward with. Mobile Screen reader users are a small portion of our user base and our ability to test is limited. That said the main reason to close this for now is that we are continuing to iterate on the typeahead experience. In Typeahead 2.0 we are developing a drop down component for which users will be able to benefit from the typeahead experience across the site vs only in the header search. This new experience will have a full 508 audit and we will be examining the impact to mobile screen reader users there as well.

[AngelaFowler82]

I will not be convinced that this new design will improve the experience for mobile screen reader users until we have had a chance to review it. Reopening this issue at this time.

[joshkimux]

@denisecoveyduc As I mentioned in the other ticket-- I'm excited to hear that Typeahead 2.0 is on its way! 🥳

To add some context to Angela's thoughts 🙇

• We're not certain if mobile screen reader users are a small portion of our user base or if existing a11y barriers are causing them to be a small portion of our user base (I'm more worried about the latter scenario).
• Mobile screen reader users are an underserved group who are more likely to have greater needs, but less access to benefits. From that framing, I think it is important that we prioritize them.

That being said, I'm certain Typeahead 2.0 will likely be designed to be more inclusive to mobile screen reader users which will render this ticket unnecessary once it's launched.

I'm wondering if we could perhaps transfer this ticket over to the Typeahead 2.0 epic so this particular use case is at the top of our minds? Otherwise, would you be comfortable with us keeping this open until Typeahead 2.0's a11y audit is complete?

Feel free to reach out to me over slack or call too! I'd be more than happy to explain the a11y perspective and why this is important to us 😄

[denisecoveyduc]

Hey @joshkimux I was chatting with Angela over slack about this too. Thank you to both of you - I completely agree with moving these forward to be addressed as we round out typeahead in 2.0.

I was just doing a little housekeeping and I'd love to close out 1.0 just to keep the boards clean.

• IF you are comfortable to open a Typeahead2.0 A11y audit ticket now to house these two issues (508-enhancement [MOBILE DESIGN]: Consider iterating typeahead UX pattern for mobile screen reader users  #20721) and (508-defect-2 [SCREENREADER]: Search should not be fired upon selecting a typeahead suggestion from the list with enter #24779) for future consideration that would be great. Then I can close out typeahead 1.0.
• IF it is not the right time to do that (no problem!) in that case we can leave them where they are and resole as we get to our 2.0 Audit.

[joshkimux]

@denisecoveyduc If possible, could we swap the epics for these two tickets from Typeahead 1.0 to Typeahead 2.0? If you can provide me a link to the Typeahead 2.0 epic I can do that today!

Otherwise, let's keep them where they are until there's a place for these to be transferred to officially.

[srsuddath]

Hey @joshkimux and @AngelaFowler82 can we close this ticket now that typeahead 2.0 has passed 508 reviews and is live in the wild?

[joshkimux]

Let's close it! Thank you for all the hard work @srsuddath 🙏