Re: Search fields

Hi Joppe,

do you know select2?

As far as I know, it’s been on a good way. At least there are aware of accessibility issues and willing to work on them.

And if it is not perfect by now, then maybe they could use some help?

Also there was a fork, that wanted to improve the accessibility.

But all that was some time ago and I’m not sure, how successful these improvements have been.

Anyway if you are interested in this solution you should definitely read the discussion on github.

Also it depends on jquery which may be a problem if you prefer vanilla js.

https://github.com/select2/select2


Sorry that I cannot give you more precise information, but I’m not using it for quite some time...

--
Mit freundlichen Grüßen

Marc Haunschild
www.mhis.de

Am 19.09.2019 um 17:28 schrieb Joppe Kroon <J.Kroon@topdesk.com>:


Hello all,

Lately I’ve been looking at a recurring issue for us: search fields.

In our product we make use of search fields here and there, that have a drop down that pops open with the search results while someone is typing, usually after a short debounce period for performance reasons. Of course that means a spinner while the request is in flight, and a drop down that gets populated as the response is received, rinse and repeat if the user continues typing.
IKEA employs a very similar concept on their websites, if you’d like an example.

I was wondering,  could this ever properly work with respect to accessibility?

Apart from some mild visual changes outside of your direct focus area (somewhat worse than a standard select element, as the items tend to be larger and ‘richer’), I feel there are mainly issues for screen reader users. I have not seen a proper solution to providing users with feedback on the status of the search while they may still be typing (depending on their typing speed/accuracy). Of course, there is the “polite” value for an “aria-live” area, but then still the status messages tend to become lost among the flurry of feedback that the screen reader is giving.

Looking around I noticed that this concept is almost never used, and in the cases where they are, I had no confidence in the implementers considering a11y.

I feel like there are two proper avenues of providing search functionality:


  1.  Use the combobox pattern, but only if the result values can be calculated instantly (example UK design system<https://design-system.service.gov.uk/>)
  2.  Fire the request only after a submit and direct to a search results page, basically ditching the “autocomplete” behavior (example US design system<https://designsystem.digital.gov/>)

There is one solution I think that allows us to have our cake and eat it too, and that is to employ a longer debounce period for the search result status message to increase the likelihood that the user is done typing. However, that results in a window of time where there is a dropdown with search results that can be interacted with that the screen reader user is not yet made aware of.

I am looking forward to your thoughts!
Joppe Kroon