Autocomplete: Combobox missing aria-controls

[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: 4.1.2 Name, Role, Value (Level A)
• Issue ID: DAC_Autocomplete_Semantics_01 (same ID used for Autocomplete: Listbox missing accessible name #4005)

The combobox is missing the required aria-controls attribute. The lack of the aria-controls attribute on the combobox can be problematic as it does not associate the relationship between the combobox and its corresponding listbox. The aria-controls attribute is fundamental for providing an explicit relationship between these two elements, which is necessary for users who rely on assistive technologies such as screen readers. While there is an aria-owns attribute present and some user agents might support this, for backwards compatibility it is strongly recommended that the aria-controls attribute is implemented instead.

Current code

<input
  aria-expanded="true"
  aria-owns="app-site-search__input__listbox"
  aria-autocomplete="both"
  autocomplete="off"
  class="app-site-search__input app-site-search__input--default app-site-
  search__input--focused"
  id="app-site-search__input"
  name="input-autocomplete"
  placeholder="Search Design System"
  type="text"
  role="combobox"
/>

DAC's proposed solution

Include the aria-controls attribute and ensure that it references the ID of the corresponding listbox. This is to identify the element whose contents or presence are controlled by the current element. Please note that the aria-controls attribute only needs to be set when the associated listbox is visible.

Background information

Our current implementation follows ARIA 1.0 standards, but something was changed in ARIA 1.1.
The Combobox Pattern page from the ARIA Authoring Practices Guide says:

In ARIA 1.0, the combobox referenced its popup with aria-owns instead of aria-controls. While user agents might support comboboxes with aria-owns for backwards compatibility with legacy content, it is strongly recommended that authors use aria-controls.

This was raised in alphagov/accessible-autocomplete#565 (and others) before.
Please note Ollie's comments on the issue:

We've previously said this might be part of an intentional 'regression' to prefer the ARIA 1.0 pattern due to better support from assistive technologies.

That was 4 years ago, so you'd hope that support for the 1.1 pattern had improved regardless, but we need to understand the nuance of this change and ensure it's thoroughly tested.

I'd suggest to test an aria-controls solution in all major screen readers to evaluate if it doesn't make the experience worse for anyone. Compare it to the aria-owns solution. And as someone had suggested on issue linked above, it would also be worth testing adding both parameters.

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.

Related issues

• aria-controls instead of aria-owns? accessible-autocomplete#565
• Add aria-controls accessible-autocomplete#386
• Refinements to address accessibility issues accessible-autocomplete#355

Needed roles

Frontend developer

[selfthinker]

I wonder if we should also add aria-activedescendant?

[owenatgov]

I've tested our current implementation (aria-owns), aria-controls and both against all major screen readers, recorded in this testing spreadsheet. The sheet is currently incomplete as we're struggling to manage remote previews of the accessibility autocomplete for use by mobile devices, however there's a clear trend based on the majorty of testing being complete that there's no difference between implementations on current screen readers. Therefore, pending completion of testing, my proposal is take DAC's suggestion and add an aria-controls attribute to the input.

I also suspect that we no longer require aria-owns, especially given the lack of difference between experiences.

[selfthinker]

I have been looking through previous issues and PRs and unfortunately couldn't find any detailed information about under which circumstances the old ARIA 1.0 implementation worked better than the new ARIA 1.1 implementation.
I had planned to test this a bit more in those (probably older) AT/browser combinations we knew it previously was not working as well. But because I couldn't find anything, I couldn't expand on the testing that was already done.