- From: Matt King <a11ythinker@gmail.com>
- Date: Wed, 3 Feb 2016 18:26:25 -0800
- To: "ARIA Working Group" <public-aria@w3.org>
- Message-ID: <012201d15ef3$72623e40$5726bac0$@Gmail.com>
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