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

Re-design visuals of search results #4195

Open
Tracked by #4167
hazalarpalikli opened this issue Oct 9, 2024 · 0 comments
Open
Tracked by #4167

Re-design visuals of search results #4195

hazalarpalikli opened this issue Oct 9, 2024 · 0 comments
Assignees

Comments

@hazalarpalikli
Copy link

Hypothesis

Improve the visuals of search results without relying on visually hidden text so we can help users who relies on screen readers make the distinction between search term vs the category.

Identified Problem

When searching for results within the autocomplete components, each result is presented with two key sets of information. The first line includes the item/string that has been searched for, which is followed by indicating what area of the GOV.UK Design System it resides under.

However, while this structure is useful in the event of multiple items having the same name but residing in different parts of the design system; the current programmatic presentation is not equivalently provided to screen reader users as it is visually. Currently each option will read as one line and the is no distinction between the search term and the category it belongs to. Visually this is obvious to users due to the information being provided on a separate line and in some instances with a chevron to indicate subcategories. However, none of this stylist information is provided to screen reader users.

Ticket for this work is #4006

Previous tests

Owen has run testing against the comma solution he found the following:

I've run testing against the comma solution, following some team conferring where it was noted that ideally the screen reader output should reflect the visual output as closely as possible. I've added a column to the testing spreadsheet linked above.

Testing results for this one are very positive. Dictation for all screen readers clearly deliminates the search result and the section information associated with said result with a pause between items. The only downside is that text boxes provided by screen readers to display what they dictate would display a space before the comma. For example, using Radios and Components, this sounds like

Radios, Components

...but looks like

Radios , Components

I personally don't think this is an issue as the impact to user experience is neglegable. I'm going to press for this solution for now.

Needed roles

Designer, content, frontend developer

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: In progress 📝
Development

No branches or pull requests

2 participants