Asserting conveyance of different values for aria-autocomplete

[jscholes]

Over on issue #340, @mfairchild365 asks:

was there any discussion on if the value of aria-autocomplete needs to be conveyed (both, list, or inline)? Or is just that the presence of autocomplete behavior in general sufficient?

The comment specifically relates to the updated tests for the Editable Combobox With Both List and Inline Autocomplete example, which uses an aria-autocomplete value of "both". In tests relating to the textbox, we assert:

The presence of autocomplete behavior is conveyed

This is generic/abstract wording, allowing testers to decide whether the specific output of a given screen reader/browser combination represents a pass or fail. But it also raises two questions:

1. Should there be different assertions for different aria-autocomplete tokens?
2. If so, will that require us to create more concretely worded assertions? I'm concerned that we may create either:
   • assertions that are too vague, e.g. "the presence of inline autocomplete behaviour is conveyed", which testers don't really understand; or
   • per-combination assertions that are too specific and imply a preference on AT output, particularly if we have to invent those output strings because ATs don't currently differentiate between aria-autocomplete tokens.

[jscholes]

Notes from the March 25, 2021 CG meeting:

• The point was raised that the use of different aria-autocomplete values has never been particularly clear, even to this day. E.g. aria-autocomplete="none" might be more appropriate than no aria-autocomplete attribute on some controls, like a search input that provides the most recent search terms regardless of the content typed by the user. But this isn't autocomplete in any sense of the word, so this is somewhat illogical.
• How much thought has gone into how screen readers convey the presence of different token values for the attribute?
• One school of thought is: should it just be a boolean flag instead? "true" if some type of concrete autocomplete functionality is available, "false" otherwise.
• If data from the ARIA-AT project proves that screen readers behave the same regardless of aria-autocomplete value, that would strengthen the case for proposing a change to the spec.
• On the other hand, the ARIA-AT project is in a position to propose the fact that screen readers adopt better support for this attribute and its values. These would have to be optional assertions, as screen readers would currently fail even if they did convey the presence of autocomplete behaviour in general. Would this drive screen reader user experience forward?
• What crossover is there with the autocomplete attribute in HTML, which is used both to signal the availability of autocomplete behaviour and, in some cases, indicate the type of data expected?

Ultimately, this was a productive discussion but we didn't reach consensus on the above points and should revisit.