- From: Michiel Bijl <michiel@agosto.nl>
- Date: Thu, 4 Feb 2016 07:45:36 +0100
- To: Rich Schwerdtfeger <richschwer@gmail.com>
- Cc: Matt King <a11ythinker@gmail.com>, ARIA Working Group <public-aria@w3.org>
- Message-Id: <5A94F0A9-F54F-41B5-90EC-1423CBEECD99@agosto.nl>
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> 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> 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
Received on Thursday, 4 February 2016 06:46:09 UTC