Skip to main content

Accessibility lessons: dealing with a large amount of form inputs

Posted by: , Posted on: - Categories: Accessibility, Code

On GOV.UK we’ve been looking at ways of improving our finder pages, like services and news and communications. Finder pages allow users to search for specific kinds of content using facets such as topic and organisations to narrow their results.

One of the facets uses a component called an ‘option select’ to display multiple checkboxes in an expandable box. This was built with accessibility in mind – it can be used with a keyboard, the expand/collapse functionality uses a button and the correct ARIA attributes are applied automatically. It looks like this:

Screenshot with a heading that says 'person' and a list of checkboxes that show the following names: Admiral Sir George Zambellas KCB DSC ADC, Admiral Sir Mark Stanhope GCB OBE ADC, Admiral Sir Philip Jones KCB ADC, Air Chief Marshal Sir Andrew Pulford KCB CBE ADC RAF, Alan Charlton CMG CVO

Despite this, the component didn’t work well at scale. Some of the facets it was used for included hundreds of options, so navigating to the last checkbox using a keyboard or screen reader was a slow task.

This presented problems even when using a mouse or a mobile device, as navigating accurately through so many checkboxes became more difficult as the number of options increased.

Worse still, there was no way to search through the checkboxes. Consider how you might try to find a person. Would they be listed alphabetically by their name, or by their title? What if you only knew their surname? Finding them among so many other people could be difficult.

Looking for an alternative

A few years ago, a team at GDS built an accessible autocomplete. An autocomplete is a text input that behaves like a select element, but you can also type in it to filter the results.

A screenshot that says: Countries, with 'France' selected from a dropdown menu
The accessible autocomplete

It looked like an ideal replacement for our option selects, as it provided essentially the same functionality but allowed the user to type to filter the available options. This meant that even with a large number of options users would still be able to navigate through them, regardless of how they were using it.

Best of all, it had been built with accessibility in mind, so we could have confidence that it would be usable.

Implementation and iteration

We set to work getting the accessible autocomplete into our finders, by creating a new component and adding the autocomplete code into it. After a bit of work, we had it running, and it was a huge improvement.

A screenshot with a search box with 'justice' typed into it, showing 'Academy for Social Justice' highlighted as a suggestion
The accessible autocomplete in place of an option select in the news and communications finder.

Although the autocomplete was working well, there was one big problem – it only allowed users to select a single option, whereas the ‘option select’ component that this replaced allowed multiple selections.

Fortunately, a version of the accessible autocomplete existed that allowed multiple selections, but when we switched to using it, we discovered another problem. In single selection mode the user’s choice remained in the text box, but in multiple mode the selections were shown beneath it, as there was no room for them in the text box.

A screenshot that says: Countries, with 'France' selected from a dropdown menu

A screenshot showing 'Countries' as the heading, with a search box underneath and 'France, Germany, Sweden' as suggestions underneath that
The accessible autocomplete operating in single selection mode (top) and multiple selection mode (bottom).

We refer to the user’s selected options as ‘facet tags’. Clicking a facet tag removes it from the user’s selections. This worked well but we had already added facet tags to our finders for the other facets, so with this change there would be a duplication of functionality.

A screenshot of search results, filtered using the organisation filters 'Defence Academy of the United Kingdom (DA)' and 'Ministry of Defence (MOD)'
The accessible autocomplete in a finder in multiple selection mode.

If we were to keep the autocomplete’s facet tags, we would have a confusing interface. The best option was to remove them and use our own, but it was not immediately obvious that selecting an option in the autocomplete had been successful, as the result was an empty text box.

This problem was worse on mobile, where, due to the stacking of the facets above the search results, our facet tags were often not visible at all, so users had no way of knowing that their autocomplete selections had been successful.

A picture of a phone showing 'News and communications' as a heading and a search box underneath with 'minister' typed into it
The accessible autocomplete in multiple selection mode on a mobile device, with facet tags hidden to avoid duplication. The user cannot see what they have selected, because it is below the visible area of the screen.

To add to our problems, the accessible autocomplete was intended as an isolated piece of code, meaning that there was no API with which to control it. With the need to be able to remove selections from it without using it directly, we were having to write increasingly complex code in order to manipulate it within our finders.

Hard decisions

After much consideration and discussion, we reached the difficult conclusion that the accessible autocomplete wasn’t a suitable solution to our problem. It was a hard decision to make – we had already invested considerable time into it and didn’t have a better alternative.

We returned to the original option select component to consider the problem. Inspired by the autocomplete, we prototyped adding a text input that would allow users to filter the visible options.

A screenshot showing the heading 'world location' with a search box with 'al' typed into it underneath, and a list of checkboxes saying 'Albania, Algeria, American Samoa, Australia' underneath, with 'Albania' and 'American Samoa' ticked

Although the filter control looks simple, we had to consider carefully how to make it perform well and be accessible.

User input is sanitised in order to help users match options more easily; it’s case insensitive, it ignores duplicate whitespace, and matches ‘and’ with ‘&’ and vice versa.

Hidden text is included that announces to screen readers how many matches have been found, how many options are selected, and provides context that something is happening as the user enters text.

Checkboxes that have been checked are always shown regardless of the filter.

The option select component still has a few other minor accessibility issues, but the addition of this filter has improved it enormously. We’re still testing and improving it, and you can try it for yourself on our news and communications finder.


There are a few important things to take away from this experience.

If something is inaccessible, this can be a problem for everyone. Finding one checkbox among hundreds isn’t a problem only for people using a screen reader – it can be difficult for all of us.

Making something accessible doesn’t necessarily require an entirely new approach. Although the autocomplete looked like the better option, in the end a small change to our original component suited our needs better.

An investment of time and effort into something shouldn’t make it indispensable. Although we’d spent a lot of time integrating the autocomplete into our finders, it wasn’t the best solution to our problem. It can be difficult to discard something, but sometimes it’s the right thing to do.

And in the end, although we didn’t use it in finders, the autocomplete component was used successfully by another team elsewhere on GOV.UK.

Don't forget to sign up to this blog.

Sharing and comments

Share this page

1 comment

  1. Comment by Duncan Garmonsway posted on

    Is the code available?