[a11y]: The ARIA attribute "aria-autocomplete" is in conflict with the corresponding HTML attribute "autocomplete"

[tay1orjones]

Reported in slack, this violation appears on downshift-based components with the latest Aug06 ruleset.

Details

These attributes are set by downshift, the library that powers the Combobox, MultiSelect, FilterableMultiSelect and Dropdown.

While the spec calls for native attributes to "win" and be used if both of these are applied, in practice both are required in attempt to achieve the outcome of:

1. Turning off form autocompletion so the browser does not display it's own listbox that conflicts with the listbox provided by the component (see examples [FilterableMultiSelect]: autocomplete="off" ignored by Chrome  #8993, and [Bug]: Chrome autocomplete shows over DatePicker #12602)
2. AT's surfacing the presence of a list connected to these components.

The attributes are not semantically equivalent and have disparate features

Current progress

• We're working with IBMa to determine if this is a valid violation or not
  • Conflict cases when aria-autocomplete and autocomplete are used together IBMa/equal-access#2052
• We've asked for more clarification on this topic from the aria working group
  • Clarify aria-autocomplete and autocomplete semantic equivalency w3c/aria#2337

Reproduction

https://stackblitz.com/edit/github-k5cekb?file=src%2FApp.jsx

Components impacted

• ComboBox
• MultiSelect

[philljenkins]

See comment on W3C issue

[tay1orjones]

Thanks @philljenkins! Do you know when the next release of the checker will be?

[philljenkins]

@tay1orjones late Oct or early Nov.
The Action Artifacts of our builds does include an interim versions of the Checker that can be used to test/close issue without waiting for the release to deploy to the Chrome Store.

The "autocomplete" fix will be in this Checker PR IBMa/equal-access#2025
(it's currently in Draft, so no artifact too test with yet)