E-mail List Archives

Search E-mail List Archives for

Number of posts in this thread: 3 (In chronological order)

From: mhysnm1964
Date: Fri, Oct 26 2018 12:54AM
Subject: accessible combo boxes and correct behaviour
No previous message | Next message →

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?

From: Birkir R. Gunnarsson
Date: Sat, Oct 27 2018 1:58PM
Subject: Re: accessible combo boxes and correct behaviour
← Previous message | Next message →

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 ADDRESS REMOVED = < = EMAIL ADDRESS 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?
>
>
>
> > > > >


--
Work hard. Have fun. Make history.

From: mhysnm1964
Date: Sat, Oct 27 2018 3:21PM
Subject: Re: accessible combo boxes and correct behaviour
← Previous message | No next message

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