Conflict cases when aria-autocomplete and autocomplete are used together

[shunguoy]

From user: If we remove autocomplete=off the browser will no longer be instructed to not add it's own autocomplete dropdown/listbox, which would harm UX of the existing listbox provided by our component.
If we remove aria-autocomplete and keep autocomplete="off" assistive tech won't be provided the inline/list/both hint.

There are two aspects to this. One is that when conflicting or overlapping native and aria attributes exist, a user agent may choose to ignore the aria attribute. However, in this specific case, it works fine with the autocomplete=off and aria-autocomplete coexistence in the Jaws test on Chrome and FF by Phil. The other aspect is that "If we remove autocomplete=off the browser will no longer be instructed to not add it's own autocomplete dropdown/listbox", and the key is how to verify this through tests because many HTML 5 and Aria best practice Combobox examples don't have the autocomplete=off setting. If that interference does exist, those examples would have an issue.

Overall, it's odd to have both native and aria attributes with the same or opposite meaning. Especially for Combobox in which a user agent knows to search the data from the list box associated with an input, and no reason to use autocomplete.

[shunguoy]

Triage: remove aria-autocomplete from the conflict list.

[philljenkins]

@shunguoy is this (removing autocomplete conflict check) being implemented in PR #2025 fix(engine): rule engine refactor and update ?
Changing file: accessibility-checker-engine/src/v2/aria/ARIADefinitions.ts
in branch dev-1974

[shunguoy]

@philljenkins yes. Will be deployed at the end of the release.

[philljenkins]

An issue has also been opened against the W3C specs: #2337.