Autocomplete: Visual information for sections not available to assistive tech

[selfthinker]

This issue is from the accessibility audit of the Design System website by DAC in July 2024.

DAC's description

• Page: Home – GOV.UK Design System
• WCAG reference: 1.3.1 Info and Relationships (Level A)
• Issue ID: DAC_Autocomplete_Options_01

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.

Current code

<ul id="app-site-search__input__listbox" role="listbox" class="app-site-search__menu app-site-search__menu--overlay app-site-search__menu--visible">
  <li aria-selected="false" class="app-site-search__option" id="app-site-search__input__option--0" role="option" tabindex="-1" aria-posinset="1" aria-setsize="14">Radios<span class="app-site-search--section">Components</span></li>
  <li aria-selected="false" class="app-site-search__option app-site-search__option--odd" id="app-site-search__input__option--1" role="option" tabindex="-1" aria-posinset="2" aria-setsize="14">
    Roadmap<span class="app-site-search--section">Community</span>
  </li>
  <li aria-selected="true" class="app-site-search__option app-site-search__option--focused" id="app-site-search__input__option--2" role="option" tabindex="-1" aria-posinset="3" aria-setsize="14">
    Responsive spacing<span class="app-site-search--section">Styles<span class="app-site-search__separator" aria-hidden="true">›</span>Spacing</span>
  </li>
  […]
</ul>

DAC's proposed solution

To ensure there is a distinction between the item searched for and the category to which it belongs, we recommend the information relating to the category is provided within parenthesis; which will still visually indicate the distinction between the item/category, whilst at the same time ensuring this information is equivalently provided to screen reader
users.

Other solutions

DAC's proposed solution would fix the issue, but there are other solutions to explore.
For example, we could add the text "Section: " or "Category: " in front of each category (visually hidden or not).

Additional instances

This component appears on every page but is a single component, therefore only needs to be fixed once.
It uses the accessible autocomplete component.
But this particular issues seems to be specific to the Design System website and is not part of the component by default.

Needed roles

Frontend developer, designer, content designer

[owenatgov]

I've run testing against both DAC's proposed solution and the one noted by @selfthinker. See the testing spreadsheet.

Thoughts

Both options mostly improve the screen reader experience for site search items, with the colon solution being overall better. However, both solutions have notable issues:

• The parentheses solution doesn't improve the experience for Talkback
• For both solutions, JAWS doesn't respect the punctuation and literally reads out 'left paren', 'right paren' and 'colon'
• There are instances in search of items that are headings within pages and therefore have search item info formatted as '[Section] > [Page]' eg: the item 'responsive spacing' has section info 'Styles > Spacing'. In both solutions, screen readers don't respect the greater than symbol and read both section and page as a single phrase and display it in textboxes as one word

Based on the above, I'd like to explore 2 more solutions, as well as both at the same time:

• a comma after the search item
• visually hidden text between the search item and the section info eg: '[Item] from section [Section]'

I'd also separately like to explore either adding visually hidden text between sections and pages eg: '[Section] in page [Page]' alongside the greater than symbol or simply replacing the greater than symbol with text.

[owenatgov]

Update

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.

[owenatgov]

I'm reopening this issue as, whilst we did solve it with #4063, that solution doesn't fully solve this. We're planning on revisiting the visuals to try to solve this without necessarily needing to rely on visually hidden punctuation.