RE: Search fields

We do a lot of user testing with people with disabilities, especially screen reader users. Much of this work is on UK government websites that use the GOV.UK Design System that you mentioned. My experience is that almost no one uses the dropdown search results.

After the user testing session is finished I ask people why they didn’t use the dropdown results. In the case of screen reader users it’s always because they were not aware of them. They type and submit the form so fast that either the dropdown doesn’t have time to appear, or it appears but isn’t announced before they submit the form. I’m not sure there’s a way to fix this, but I am also not sure it even needs to be fixed. No one ever expressed disappointment at the absence of dropdown search results.

Sighted people also rarely used the dropdown, but for different reasons. Some people don’t even notice it, and I have sometimes had to replay the video recordings to prove that it was actually displayed. Others saw it but didn’t use it because they were not expecting it and it did not fit into their planned approach to the task. The possible benefit of using it did not justify the cognitive load of stopping their planned approach, evaluating this new thing and deciding whether and how to use it. It was just easier to carry on and ignore it.

Of course these tests were only evaluating people’s initial use of the website, so they may start to use the feature if they use the website regularly. However, many of the websites were for things you would only do once or extremely rarely.

So my recommendation is to do lots of user testing of possible solutions before committing to any changes.

Steve Green
Managing Director
Test Partners Ltd



From: Marc Haunschild <haunschild@mhis.onmicrosoft.de>
Sent: 19 September 2019 17:10
To: w3c-wai-ig@w3.org
Cc: W3C WAI ig <w3c-wai-ig@w3.org>
Subject: 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<http://www.mhis.de>


Am 19.09.2019 um 17:28 schrieb Joppe Kroon <J.Kroon@topdesk.com<mailto: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