W3C home > Mailing lists > Public > public-aria@w3.org > February 2016

Re: ACTION-1490 proposal says good bye to the "inline" notion for combobox

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>
Message-ID: <56BCA6E7.8060409@alum.mit.edu>
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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:58:20 UTC