alphagov / govuk-design-system

One place for service teams to find styles, components and patterns for designing government services.
https://www.gov.uk/design-system
MIT License
511 stars 232 forks source link

Autocomplete: Visual information for sections not available to assistive tech #4006

Open selfthinker opened 3 months ago

selfthinker commented 3 months ago

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

DAC's description

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.

Screenshot of the autocomplete showing results with their section

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 commented 2 months ago

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:

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

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 commented 2 months ago

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 commented 1 month ago

I'm reopening this issue as, whilst we did solve it with https://github.com/alphagov/govuk-design-system/pull/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.