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

Autocomplete: Use of invalid role when no results found #4003

Closed
Tracked by #3967
selfthinker opened this issue Aug 8, 2024 · 0 comments · Fixed by alphagov/accessible-autocomplete#724
Closed
Tracked by #3967
Assignees
Labels
accessibility regulations failure Does not meet the Public Sector Accessibility Regulations (WCAG 2.2 level AA) accessibility audit july 2024 Issues from July 2024 external accessibility audit against WCAG 2.2 criteria

Comments

@selfthinker
Copy link
Contributor

selfthinker commented Aug 8, 2024

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

DAC's description

The options within the autocomplete were contained within a ul with the role="listbox" applied to it. Typically the results will be contained within <li> items with the role="option" applied to it which makes it valid.
However, when there are no results found the information is contained within an <li> item without a role. As there is no valid role present, the implementation of the <li> is not valid as the parent listbox should only contain option elements.

Screenshot of the autocomplete with no results

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 class="app-site-search__option app-site-search__option--no-results">No results found</li>
</ul>

DAC's proposed solution

As <li> items are specific child elements to unordered/ordered list they cannot be used in place of an option within a listbox. In this instance when there are no results present, in order for the content to behave in the expected way it will need to be marked-up differently.
We suggest adding a role="option" to the <li> as this is a valid child element of the listbox.
We then suggest applying the aria-disabled="true" attribute to convey that the option cannot be selected to screen reader users.

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.

Needed roles

Frontend developer

@selfthinker selfthinker added accessibility audit july 2024 Issues from July 2024 external accessibility audit against WCAG 2.2 criteria accessibility regulations failure Does not meet the Public Sector Accessibility Regulations (WCAG 2.2 level AA) labels Aug 8, 2024
@owenatgov owenatgov self-assigned this Aug 12, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
accessibility regulations failure Does not meet the Public Sector Accessibility Regulations (WCAG 2.2 level AA) accessibility audit july 2024 Issues from July 2024 external accessibility audit against WCAG 2.2 criteria
Projects
Status: Ready to release 🚀
Development

Successfully merging a pull request may close this issue.

2 participants