- From: Joseph Scheuhammer <clown@alum.mit.edu>
- Date: Thu, 11 Feb 2016 10:21:11 -0500
- To: Matt King <a11ythinker@gmail.com>, "'ARIA Working Group'" <public-aria@w3.org>
- Cc: "'Bryan Garaventa'" <bryan.garaventa@ssbbartgroup.com>
Matt, On 2016-02-08 12:52 PM, Matt King wrote: > The proposal I am putting forward in action 1490 is to remove all that extra meaning from aria-autocomplete and give it one clear purpose that authors, AT developers, and users can utilize. > > As a user, I will not remember all these different meanings. And, I do not want my screen reader to slow me down with a description of how the combobox is going to behave. I sympathize. As a sighted user, I see (1) the characters I am typing in the text field plus (2) a suggested completion within the text field changing as I type, and/or (3) changes to the listbox contents as I type. Sometimes, I do not want to be distracted by all that visual noise. I just want to enter a specific string in the text entry field, hit return, and be done. I would love the ability to toggle all forms of auto-completion, so it's there where I find it useful, and avoid when it is not. In short, I want a simpler visual interface. Likewise, a solution for screen readers is for them to simplify their presentation. ARIA is not prescriptive in that it does not dictate how ATs use or present accessibility information. If screen reader users don't need to know the exact nature of the auto-completion, then perhaps screen readers shouldn't relay that degree of detail. > The best way for me to find out what is in the list and how many values are in the list is to read the list. There are some complex interactions where it might be a good idea for the author to add a live region with a short description of what is happening in the list as the user types in the input. But, such cases are pretty rare. > > If we restrict the meaning of autocomplete to describe what is happening in the input field, then the screen reader developer can exploit that to provide intelligible reading of the completed value and/or caret position in that value. Fair enough, but, again, why isn't that the screen reader's job? That is, if the list form of auto-completion is irrelevant to screen reader users, then why don't screen readers ignore aria-autocomplete="list"? > The screen reader developer can get info about the availability of the list from the combination of aria-controls and aria-expanded and inform the user appropriately. > > One of my primary goals is to make ARIA easier for everyone to understand so we can increase the quality of both authoring and AT support. That is the spirit of my proposal. That is high on everyone's list, but it involves finding the best level of detail. You've also suggested that: > 3. Change combobox aria-autocomplete authoring requirements to state > that aria-autocomplete be set to either "both" if autocomplete is > provided in the textbox or "list" if it is not. That implies that comboboxes always support auto-completion. Above, I suggested adding the ability to reduce visual noise by disabling all auto-completion. That may be even more useful for users with cognitive impairments. Consider a developer who decides to create a combobox that doesn't implement auto-completion in the text entry filed nor in the listbox, in order to simplify the visual presentation. They then add the appropriate aria attributes, and discover that they need to declare aria-autocomplete="list" even when they have specifically not supported it. That's confusing. Also, if the meaning of autocomplete is restricted to describe what is happening in the text input field, then the autocomplete property is tied to that entry field and not the combobox as a whole. Okay, but in that case, I would think the values of "inline" and perhaps "none" would apply, since "list" is not relevant to describing what is happening in the text entry field. "List" is describing what is happening in the listbox. Finally, what does auto-complete mean when the drop down contains a dialog? Defaulting to a value of "list" in the case of a dialog ... well, I'm stumped. There is no listbox containing completion suggestions in that case. I guess the meaning could be extended to say it applies to anything in the drop down that adapts to user's typing. But, does the dialog's contents change based on what the user is typing in the input field? My gut is that this is a case where auto-complete might be described as "none". -- ;;;;joseph. 'Die Wahrheit ist Irgendwo da Draußen. Wieder.' - C. Carter -
Received on Thursday, 11 February 2016 15:21:43 UTC