Typing a correct option in to the autocomplete will not get accepted

[edwardhorsford]

If a user types their answer in to the autocomplete rather than picking one - even if it's an exact match, that answer will not get submitted.

I'd consider this quite a serious bug - and am surprised we haven't come across it before. I assume on blur we should be checking the value and doing some stuff - but it seems like this only happens on interaction with the suggestions.

I've frequently observed users type complete answers in the autocomplete and not even realise suggestions were showing. Where the answers are short (eg 'French') they may well have typed the answer before ever noticing the suggestions.

There are some related bugs with this:

• If they previously picked a different answer, then change the text and type a different, correct answer, then the old answer will be submitted.
• If they type a correct answer, but in different case, that answer will also not be saved.

[vanitabarrett]

There is a similar issue raised in the govuk-country-and-territory repo alphagov/govuk-country-and-territory-autocomplete#70

[vanitabarrett]

I've tested this issue using this page but wasn't able to replicate the issue. I tried the following steps:

1. Type "Ireland" in to the autocomplete field
2. Press enter without selecting an item from the dropdown, to submit the form

and

1. Type "Ireland" into the autocomplete field
2. Press ESC key to close the suggestion list without picking anything
3. Click the submit button / tab to the submit button and press ENTER to submit the form

@edwardhorsford Are you able to check if you're still seeing this issue and provide the exact steps you're taking so we can try to reproduce the issue, please? It would be good to know what browser you're using and what version of the autocomplete too.

[edwardhorsford]

@vanitabarrett I can't easily test this myself, but could do a screenshare with you?

Skimming the issue I suspect it directly relates to the accessibleAutocomplete.enhanceSelectElement({}) and possibly architectural decisions for the component.

With the enhanceSelectElement() the autocomplete attempts to select the right option in the underlying select when you pick an item. This code doesn't run if you escape out of the field - even if the option is a caseless match.

Somewhat by design, when using this mode the raw value typed doesn't get submitted to the server (by default?). I think I've now come to the view this is the wrong decision, and when in this mode the autocomplete should either submit the value for the selected select option, or else the free text typed if there is no match.

I'd stop bothering with trying to keep around the underlying select and keep it in sync - instead remove it and submit something using the same name.

[edwardhorsford]

To add some more context:

In the enhanceSelectElement() mode, the autocomplete partially works like a select, but looks like an input.

I strongly think it should either:

• Only ever let you pick from the allowed values and blank out any other input if you escape / blur without picking something
• Submit what was typed to the server (where it's not a known option) so the server can decide what to do with the input.

At the moment we get the worst of both worlds - it looks like there's a value in the input, but it's not valid and won't even get sent to the server.

On my service, we've set up the autocomplete to always send the raw value typed to the server so we can compare it to the allowed values and act accordingly.