WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: accessible combo boxes and correct behaviour

for

From: mhysnm1964@gmail.com
Date: Oct 27, 2018 3:21PM

Birkir

I was aware of no native combo boxes. The last part of your message of the
dev's not storing the original value in case of cancellation is the more
important aspect. From my point of view, this should occur as it supports
the user flow of dismissing their last action.


WCAG 2.1 doesn't cover this, but you could use 4.1.2 Name, role, value
dinging on the value aspect.

Sean

-----Original Message-----
From: WebAIM-Forum < <EMAIL REMOVED> > On Behalf Of
Birkir R. Gunnarsson
Sent: Sunday, 28 October 2018 6:58 AM
To: WebAIM Discussion List < <EMAIL REMOVED> >
Subject: Re: [WebAIM] accessible combo boxes and correct behaviour

There is no native browser implementation of a combobox.
An input with a list attribute and a matching listbox comes closest. I have
an off-line example of that somewhere and it has a surprisingly decent
accessibility support, I just have to upload it to Code Pen.
Since the interaction has to be scripted and starts in a text input field
the implementation is entirely up to the developer.
It is easiest to indicate the current focus in the suggestion list by simply
copying the value of that suggestion to the text input rather than messing
around with aria-activedescendant, so that is probably why you are seeing it
so frequently.
Even with an inline autocomplete implementation the developer can easily
remember what the user typed before activating the suggestions, just store
it in a variable, and when the user presses the escape key siply replace the
value of the selected suggestion with the content of that variable



On 10/26/18, <EMAIL REMOVED> < <EMAIL REMOVED> > wrote:
> All,
>
>
>
> I have seen many attempts of accessible combo boxes. What I have not
> seen and require verification. When a combo box is open and the
> keyboard user is navigating the list of options. If they press escape.
> The prior value should be maintained in the edit field and not
> overwritten with the currently selected value. All the combo boxes I
> have tested even the one from W3C ARIA 1.1. best practise does what I
> have described when using Firefox 62. I must admit I have not tested
> this with IE11 or Chrome.
>
>
>
>
>
> For example: A combo box with 3 options. The edit field is blank. The
> combo box is open by using the alt down arrow. The down arrow is moved
> to the 2nd value called "2". The user presses escape and the value 2
> is inserted into the edit field rather than kept blank.
>
>
>
> I understand Chrome has decided to change how combo boxes are open now.
> Instead of using alt down arrow or the down arrow. The enter key is
> used. I believe this is in Chrome 70. Thoughts on this?
>
>
>
> > > archives at http://webaim.org/discussion/archives
> >


--
Work hard. Have fun. Make history.
http://webaim.org/discussion/archives