RE: Asking all to consider making aria-autocomplete Boolean

Right, we wouldn’t break anything by deprecating the old values. All we have to do is have browsers map true to list and false to none. Browsers could still pass through all 4 legacy values for legacy implementations.

 

Then for ARIA 2.0, we could remove the mapping of true to list and false to none  from the AAM, and by that time, all the AT will support the boolean values supplied by authors in 1.1-compliant web content. Browsers and AT could continue to support 1.0 implementations for as long as they see fit.

 

So, I am still looking for a reason that autocomplete must be an enumeration instead of a boolean.

 

Matt

 

 

From: Michiel Bijl [mailto:michiel@agosto.nl] 
Sent: Wednesday, February 3, 2016 10:46 PM
To: Rich Schwerdtfeger <richschwer@gmail.com>
Cc: Matt King <a11ythinker@gmail.com>; ARIA Working Group <public-aria@w3.org>
Subject: Re: Asking all to consider making aria-autocomplete Boolean

 

We could add a warning/note to indicate it will deprecated in 2.0? If that what is what we want to do. 

—Michiel


On 04 Feb 2016, at 06:16, Rich Schwerdtfeger <richschwer@gmail.com <mailto:richschwer@gmail.com> > wrote:

Yes. If there are current implementations out there with those values it breaks them.

 

We are trying to shut 1.1 down Matt. This is not what you do when you are trying to shut it down.

 

We also don't have time to canvas the wild now to see what this breaks.

 

Rich

 

Rich

Sent from my iPhone


On Feb 3, 2016, at 8:26 PM, Matt King <a11ythinker@gmail.com <mailto:a11ythinker@gmail.com> > wrote:

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