Autocomplete — share your use cases and implementations

[christopherthomasdesign]

We plan to revisit 'Autocomplete' to see if we can make this component more easily available, as well as up-to-date with the latest technologies and accessibility requirements.

About this work

Autocomplete is a text input that suggests options to the user as they type.

The community has worked on this in the past – see the accessible autocomplete repository, and the associated accessible autocomplete examples demo.

Previous conversation can be found at alphagov/govuk-design-system-backlog#4.

What we're looking for

We want to understand:

• services that use the current autocomplete
• their different use cases
• customisations or ‘hacks’ that teams have made
• datasets in use
• accessibility work service teams have done, and what needs they’ve discovered

[edwardhorsford]

Our team has coded an extension to the autocomplete to fix some common usability issues and extend the functionality. It's written as a drop in bit of code other teams can use and then expand on. Most of the features can be configured by adding the appropriate data-attributes on to each item on a select.

We documented it in this blog post

Improvements it makes:

• Better matching / searching - whitespace / punctuation differences no longer cause a failed search
• Results are sorted from better match to worse match
• Built-in support for synonyms
• Support for boosting specific items
• Support for stripping stop words (in, of, and, at, etc)
• Support for appending extra information to the name
• Support for showing a hint with the name

We also did some work to have analytics on our autocompletes - so we know what people search for and what they ultimately pick - this helped us find gaps in the functionally or where we needed more synonyms.

[edwardhorsford]

Our most complex autocomplete is for searching for a school. This uses Ajax to live search our db using the user's query. There are around 40k entries. We use a hint to show additional school details that users can pick from. For non-js, we have a regular input with server-side search.

Blog post about the js search
Blog post about the no-js fallback.

Prototyping with the autocomplete

For prototyping, I've wrapped the accessible autocomplete as a nunjucks component. The API could do with a bit of cleanup, but the object currently looks like this:

{{ appAutocompleteFromSelect({
  label: {
    text: "Type of degree",
    classes: "govuk-label--s"
  },
  hint: {
    text: "Hint"
  },
  id: 'degreeTypeUK',
  name: "degreeTemp[typeUK]",
  items: items,
  classes: "govuk-!-width-two-thirds",
  value: degreeTemp.type,
  autocompleteOptions: {
    minLength: 2,
    autoselect: false,
    showSuggestionsBanner: true,
    values: degreeTypeAutocompleteValues // optional values
  }
} ) }}

The component then renders out an html select with appropriate data attributes on each option. Our autocomplete code runs on all pages and inits for each select or input it finds, and gets the relevant data from the data attributes. This component has made setup of new autocompletes for prototypes much easier - as you usually just need to provide an array of data. There's a similar component for enhancing from an input rather than a select.

[rgarner]

@edwardhorsford we have the same use case, with the same dataset/size. What we've found is that the autocomplete (even with minLength) generates a lot of queries, which puts demand/expense on hosting for smaller projects (typically those relying on commodity Postgres as opposed to some search index). Debounce helps here alphagov/accessible-autocomplete#611.

[edwardhorsford]

DfE has also been working on an autocomplete with revised styling for situations where the results are suggestions only, but the user is free to type whatever they want. This work was done with @frankieroberto and was influenced by the ONS' Census 2021 autocomplete.

Autocomplete with suggestions:

ONS Census 2021 autocomplete:

[christopherthomasdesign]

These are very nice indeed 😎

[edwardhorsford]

One area where the autocomplete lacks is proper support for values that are separate from the visible text. Eg the text might be "Hogwarts academy" but you want to store a uuid value. This becomes important for larger sets where you might have several items with the same name.

Selects support values and it half-works if you're using the enhanceSelectElement mode - but not very well, and not if you're enhancing from an input. We've patched this by creating a hidden input that stores the value - and sending that to the server.

[adamliptrot-oc]

Working on service teams at HMRC I added some js and css to handle a few issues (link to Gist):

1. a user picking a valid answer, not submitting it, changing their answer to an invalid one and submitting - the previously selected valid response was sent instead of the new invalid one.
2. error styling not being presented on the js-generated input
3. any aria-describedby attributes on the original select not being copied over to the js-generated input (so any hints or errors are not exposed as expected)
4. css to handle the 'show all' icon not presenting due to z-index

[DilwoarH]

On GOVUK Publishing we have a need for multiple selections as well as a single selection. An example of this can be found here.

From my experience in working on publishing apps, I found that the following is needed to make the accessible autocomplete better:

1. If you select an option, it should not allow you to edit this text (unless you want to select/search for another option).
2. It should allow multiple items to be selected.
3. It should only allow you to select from the list of items specified - ie. You shouldn't be allowed to enter text which isn't in the list.
4. It should allow you to use select option groups.
5. It should allow users to scroll through the list without requiring them to enter a letter.
6. For long lists, it should support AJAX requests so that the DOM doesn't have to load up 1000s of options.

The above basically describes the behaviours of the select2 plugin which is slightly different to the current implementation of the GOVUK Accessible Autocomplete. In my opinion, an accessible "select2" type component is what we need for almost all cases.

[edwardhorsford]

I feel like it would be worth exploring multiple standalone components serving different needs. Or at least thinking about the various use-cases and how our guidance could document them.

Part of the challenge of the current autocomplete is that it can be extended very flexibly, but it's up to teams to modify, and you basically have to customise everything to get it working well and fix the usability gotchas. Different settings can have usability implications, but it's not obvious what these are. It would be so helpful to have worked examples of the different ways you can set it up, and the pros and cons of them.

Some possible components:

Enhanced select

• To help users pick from a smallish number of fixed options
• Fix many of the usability issues with selects
• Very limited in configurability - but easy for teams to implement - just provide an array.
• Possibly styled closer to a drop-down/ select rather than an input.

Suggestion autocomplete

• Similar to examples above
• Uses results as suggestions, but users are free to type their own thing

Autocomplete advanced

• Possibly a bit similar to current autocomplete, but likely rewritten
• For searching from larger lists
• Users normally expected to pick from list
• Configurable for the various use cases teams have
• Sensible defaults / presets for common use cases.
• Wrapped as a Nunjucks component but can be configured with js if needed

---

[frankieroberto]

We use autocompletes in a few places within Apply for teacher training.

They fall into 2 categories.

1) Where users have to select an item from the list

These enhance a <select class="govuk-select"> element, which is shown if javascript is unavailable.

Nationality

Training provider

2) Where there is a list, but users can also type in their own answer

These enhance a <input type="text" class="govuk-input"> element.

Degree subject

University

What we’ve found

It hasn’t always been clear whether users have to pick an option from the list or not. This could lead to users picking the "closest match" answer rather than typing in an accurate answer. To resolve this we added hint text, a "Suggestions" header and a gap between the input box and the options list. When there are no matches, we do not display the list or the heading, so that the input looks like a regular text input. In user research, we observed participants being able to both select an option and typing in their own answers.

Where a user has to pick an item from the list, we generally display a down arrow, and have the list appear when focusing the input even if no characters have been entered. This makes it more similar to a regular dropdown list, so that users realise they have to pick an option. The downside to this is that not all users realise they can type in some characters to filter the list.

[christopherthomasdesign]

Cheers Frankie! I'd be interested to hear a bit more about the need behind option 2, where a user can type what they like but we give them suggestions as they type. Is it because users don't know what to type? Or does it help with matching data in the backend somewhere?

[frankieroberto]

@christopherthomasdesign hiya. sorry for slow reply. The main benefit for the user of the option 2, where the autocomplete is added to a free text field, is that it can speed up their task and give them confidence that they have entered information in correctly. For example, when typing in their degree subject or university they might see their answer after only typing in a few characters, which saves a (small amount) of time and gives them a satisfying feeling that their answer was known and that they haven't made any typos, spelling mistakes or used a different term.

It's a relatively marginal benefit for the user (depending on how long the overall task is), but I think this is one reason why it's acceptable as an "enhancement", with the no-javascript option of just having a free text field as an adequate fallback.

As a secondary benefit, the autocomplete also gives the service "cleaner" data, with less likelihood of duplicates caused by typos, alternative names, and so on. This shouldn't be the only reason for doing it (as you could clean up that data separately), but can be an important side benefit when doing analysis of the data.

[edwardhorsford]

My team previously used the showAllValues option that displays the arrow and shows everything on focus. We ultimately removed it because of several usability issues.

Issues:

• Users never searched / typed when this mode was used - they just scrolled the list. This may be good for short lists, but for long lists 95% of the value of the autocomplete is lost. This is especially true if you want users to be able to search with synonyms.
• Users expect to be able to click the arrow to close the list. This either doesn't work or is buggy in the autocomplete.
• Once an answer is selected, users expect to be able to click the arrow to see all options again - the autocomplete does not do this.

I think having such a mode is worth keeping (see enhanced select suggestion above) - but would have it as a standalone thing and note that it's more suited to lists with not many items. I'd also restyle explicitly like a menu rather than an input.

[rgarner]

@edwardhorsford We're about to do this for subject specialisms. The insights are appreciated.

[edwardhorsford]

I think the autocomplete could also do with in-built support for a 'clear' button or link. It's a PITA to use where there's a pre-filled value - it's not obvious you have to clear all text to search again.

[edwardhorsford]

There's this 2019 blog post from the GDS blog post investigating selecting multiple items for GOV.UK Finders that covers autocompletes.

In particular they looked at some ways of possibly supporting selecting multiple:

[stevenjmesser]

I remember this work evolving while I was working on the Search team, and the current version is (I think) on the super-group finders, e.g. Guidance and regulation.

[jessdenney]

HMRC Online Payments Service

Part of our open banking journey requires the user to pick out the name of their bank account from a list.

Its quite a long list and it was originally trialed with radios but it wasn't very practical so we now use the auto complete list. This works quite well as there are some items which are very similar such as Bank of Scotland Personal and Bank of Scotland Business.

I'm not sure if any 'hacks' have been used to improve the function for our users. But if their bank isn't listed because its not part of open banking the user is shown other payment options behind the secondary button 'my account is not listed'.

[adyhoran1]

We use the autocomplete component to assign projects to internal Department for Education staff. See https://conversions-design-history.netlify.app/apply-to-become-academy/assign-a-project/#prototype-design

We've noticed the following issue:

Select a user from the autocomplete list

Change your mind and delete the contents of the auto-complete box

Click Continue. The person that was selected but deleted is assigned

We don't think this should happen - we think if you delete the text in the text field and click Continue, then it should not assign someone to the project.

[adamliptrot-oc]

@adyhoran1 We have seen this too - see earlier comment #2374 (comment)

[edwardhorsford]

@adyhoran1 it's possible for you to fix / correct this. You can set up the autocomplete to submit the raw input string as well as the 'selected' select item. Your backend can then compare the two or see if it's blank and behave appropriately.

I think in our prototype I also patched this in js so that we clear the select too if the value in the input is blank.

[martinwake]

A possible use case for what's called Advanced Autocomplete above is address lookups. See for example the Royal Mail's at https://www.royalmail.com/find-a-postcode.

[CharlotteDowns]

We've just added some guidance on how to 'share findings about your users' with us 📝. This will help us learn more about how your users autocomplete within your service.

[armoj]

I submitted this question/bug to your accessible-autocomplete issues a few days ago. There is a problem with our autocomplete when used with Dragon NaturallySpeaking. There is an issue, either with the autocomplete, or Dragon that prevents the form value being updated. I was wondering if this is a bug/issue that you are aware of at this time.

[stephenjmcneill1971]

Is there anyway to make the assistiveHint attribute optional?

I would like to removde the assistiveHint text

"When autocomplete results are available use up and down arrows to review and enter to select. Touch device users, explore by touch or with swipe gestures."

and the related aria-describedby being rendered. Is this an option.

Alternatively could we make it visible and styled

[edwardhorsford]

One of the options lets you provide your own assistiveHint - I assume this could be used to effectively 'clear' it. Though it wouldn't be recommended, because it's probably good to tell screen reader users how to interact with the component.

If you want instead for something to be visually shown, you'd need to add this yourself - eg use javascript to insert the appropriate element in the DOM after the component has loaded.

[edwardhorsford]

Note: I raised a bug earlier this year about AssistiveHints being broken in 2.04.

[ryanb-gds]

To add to the comment above, GOV.UK Publishing are still currently maintaining a version of the autocomplete which allows for multiple selections at https://github.com/alphagov/accessible-autocomplete-multiselect.

However, it has recently failed an accessibility review because it does not announce the selections effectively or the presence of the "Remove" button for screenreaders. We are yet to decide at this point in time whether or not to invest in making the existing multiselect implementation more accessible, which we expect will be challenging, or to explore an alternative design pattern.

[JillRichardsonPratt]

Would it be possible to call this component something other than 'autocomplete' so that we aren't using the same name for both this component and the autocomplete attribute that helps users to reuse previously filled data? When working on a team that has tickets relating to the autocomplete attribute alongside other tickets relating to this component, it's tricky to work out which tickets refer to which things! It would be great it we could remove the ambiguity. :)

[clare-brown]

HMRC Economic Crime Levy

We've used this component successfully as part of our registration journey where we ask users 'Who is your AML supervisor?' - but deviating from the standard component using it within a radio dropdown.

It was done to create focus on the main 3 supervisors, HMRC, the Gambling Commission and the Financial Conduct Authority and reduce the amount of 'Other' options on screen as it's quite a long list of 22 other professional bodies.

It's tested well after iterating and adding 'Name of professional body' above the hint text.