Asking all to consider making aria-autocomplete Boolean

As I am digging into action 1490:

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

I am attempting to clarify the meaning of states and properties that apply
to combobox.

 

I have been discussing the meaning of autocomplete with a variety of people,
and the only thing that is clear to me is that everyone seems to have a
different understanding of when each of the different values should be used.
Ironically, in some initial sniff testing, the value of aria-autocomplete
does not seem to matter much when it comes to screen reader behavior.

 

I am coming to the conclusion that aria-autocomplete is overloaded with too
many meanings and that simplifying would better serve both assistive
technology developers and web authors.

 

My proposal: make aria-autocomplete a Boolean. True means that a textbox has
autocomplete behaviors, i.e., suggested completion will appear after the
caret as a user types.

 

I propose that for combobox, we do not need any of the following values for
aria-autocomplete:

1. none because that would be the same as false.

2. inline because that would be the same as true.

3. list because all comboboxes have a list, and that list is  identified by
a relationship and known to be visible when expanded is true.

4. Both because that is the same as true combined with the list.

 

If aria-autocomplete is a Boolean, then we could also have a 1:1 mapping
with html autocomplete. Thus, in HTML, if an author specifies autocomplete,
that would imply that aria-autocomplete is true. The difference between
aria-autocomplete and html autocomplete would then be that html autocomplete
effects browser behavior whereas aria-autocomplete can be used when the
author wishes to provide the autocomplete behavior.

 

Can anyone think of a good reason for keeping the current enumeration rather
than moving to a simple Boolean with a clear definition?

 

Matt King

Received on Thursday, 4 February 2016 02:26:54 UTC