ACTION-2039 proposal for revisions to aria-autocomplete description ready for review

The objectives of action 2039[1] and its proposal[2] are to clarify the
meaning of the different values of aria-autocomplete and clearly state the
authoring requirements for using them. It does not change the values or
meanings; it is an attempt to describe the ARIA 1.0 intent derived from
discussion on the public ARIA mailing list.[3] [4] It also harmonizes the
language with the ARIA 1.1 definition of the combobox role and haspopup
property.

 

This proposal is particularly important to the goals of improving both
authoring of and support for elements with autocomplete behavior, especially
comboboxes. It will also facilitate appropriate use of autocomplete in
design patterns other than combobox.

 

The proposal for revisions to the aria-autocomplete section of the
specification is in branch action2039-autocomplete.[2] It includes the
following changes.

 

1. The first paragraph revises the short definition of the property to
emphasize that:

A. The property both indicates whether an elemet provides autocomplete
behavior and what type of behavior is provided.

B. Autocomplete behavior is limited to suggesting values that would complete
input based on some amount of input that has been provided by the user;
autocomplete behavior does not exist where only some arbetrary values
unrelated to the user's input are suggested.

 

2. Added a paragraph that summarizes how each of the autocomplete values
describe a specific type of interaction model.

 

3. Added a paragraph that describes the difference between an input that
provides an autocomplete list and an input that provides a popup list of
suggested values but does not have autocomplete behavior.

 

4. Clarified the intent of the normative authoring statement regarding the
selection state for inline suggestions.

 

5. Added a normative authoring requirement to provide an appropriate value
for aria-haspopup when autocomplete is list or both.

 

6. Added a description of the difference between implementations that
pre-select a specific value from a list and implementations that require the
user to take specific actions to select a suggestion.

 

7. Added a normative authoring requirement to use aria-activedescendant when
autocomplete is list or both and when the autocomplete implementation
automatically pre-selects a specific suggestion.

 

8. Added a paragraph to clarify that autocomplete is a property, not a
state, and what that means in practice, e.g., authors should not dynamically
change its value to reflect the presence of autocomplete suggestions.

 

9. Added a normative authoring requirement that states that authors should
use aria-expanded to communicate the presence of the suggestion container
element when autocomplete is list or both.

 

10. Adjusted the language throughout the entire description to emphasize
that the "list" value refers to a collection of suggestions that is
presented in a separate element and that element is not necessarily a
listbox. This is to make it compatible with the ARIA 1.1 combobox support
for elements other than listbox.

 

11. reworded the descriptions in the value table for autocomplete to make it
clear the values describe what an element will do (they are a property)
rather than what an element is doing (they are not reflecting a state).

 

Matt King

 

[1] Action 2039:

https://www.w3.org/WAI/ARIA/track/actions/2039

 

[2] action2039-autocomplete branch: 

http://rawgit.com/w3c/aria/action2039-autocomplete/aria/aria.html#aria-autoc
omplete

 

[3] List post describing the difference between values list and none: 

https://lists.w3.org/Archives/Public/public-aria/2016Feb/0136.html

 

[4] List post describing inline and list with Microsoft references:

https://lists.w3.org/Archives/Public/public-aria/2016Feb/0287.html