Add visual cue for when a dialog is available

[owenatgov]

Change

Adds visual cues to the component so that users who are zoomed into the input know that there is a dialog below that they may be able to interact with. When a dialog is displayed, the input will be given a 'bottomless' class to remove it's bottom border, making it visually flow into the menu and drawing the eye down.

This also gates the change behind the useBottomlessInput attribute so that users using the cssNamespace attribute doesn't get served useless CSS classes on render.

More detail in alphagov/govuk-design-system#4015

Visual changes

Before/without attribute

After

[netlify]

✅ Deploy Preview for accessible-autocomplete ready!

Name	Link
🔨 Latest commit	e1964d5
🔍 Latest deploy log	https://app.netlify.com/sites/accessible-autocomplete/deploys/6706a7179ca42b00087e2946
😎 Deploy Preview	https://deploy-preview-753--accessible-autocomplete.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site configuration.

[edwardhorsford]

@owenatgov I would encourage significant usability testing on this before showing arrow by default.

The risk is that it nudges people towards interacting with the results prematurely so they end up interacting with a long list rather than a much shorter filtered list.

I've observed this across many usability sessions - that when the arrow is present, users stop interacting with the autocomplete as an autocomplete - they don't type or search but instead click the arrow to use it as a select. This might be mitigated if the arrow is only shown once there's results, but I'd still want to test it extensively.

On my previous service we initially used the showAllValues option but eventually removed it because in practice it made searching for items worse.

[romaricpascal]

Added a couple of questions on the code changes, but couldn't check how things were working as Netlify seems to be struggling to deploy. From the screenshots, the arrow looks quite high inside the input box, though, is this intended?

[owenatgov]

@edwardhorsford This is useful context, cheers. To clarify, the arrow is only shown when there are results. I've tried to adjust the content of the PR to make that clearer.

[edwardhorsford]

@edwardhorsford This is useful context, cheers. To clarify, the arrow is only shown when there are results. I've tried to adjust the content of the PR to make that clearer.

Thanks, I understand that - I'd still be cautious with this change and encourage usability testing of it first to make sure the downsides I mentioned don't occur.

[owenatgov]

After discussing this again with the team, we're going to remove the arrow following @edwardhorsford's comments about prior research. We think the 'bottomless' effect is good enough (pending testing by @selfthinker). I'm going to remove the arrow and adjust the description of this PR.

[edwardhorsford]

Thanks @owenatgov - I didn't comment on the line but it looks like a nice visual touch!

It may well be there's no impact from the arrow, or another visual indicator could be added that doesn't look like a arrow / select.

[owenatgov]

I've added an attribute to this PR: useBottomlessInput. This gates this process behind an attribute to prevent us service useless CSS classes to users of cssNamespace. This is following suggestions by Romaric on this PR and discussions off github that this could be a breaking change.

Now that I've done it I'm not sure how necessary this is. The component won't stop working, it'll just not use the visual enhancement and we service them extra html in the form of additional CSS classes. I'm not sure this is breaking necessarily. The 'breaking' point felt much more relevant when we still had the arrow since the way I'd done it made it more likely to be a breaking change. @romaricpascal Whatcha reckon?

[selfthinker]

I have tested the old and new version in Windows High Contrast Mode (option 1, 2 and white), Firefox colour changes (a dark and a light colour scheme) and the Chrome extension 'High Contrast'.
I have uploaded screenshots of everything to this folder (which can only be viewed internally).

To summarise those:
I guess the difference is clear enough when none of the results has been selected yet. But when the first item has been selected (as is the case automatically on the Design System website), the difference is much less visible.
In Firefox the dropdown never looks like an extension of the text field because their background colours are different.

The dropdown box never aligns with the text field. That has nothing to do with this change, though.
It's also interesting that the highlighted item always has blue as a background colour. While that also doesn't have anything to do with this change, it might be more important to help with the perception that the dropdown extends the text field. There might be a problem with how we set the colour. Could we maybe use the system colour 'Highlight' in forced colour modes?

[owenatgov]

Following a chat off-github with @romaricpascal I'm going to close this in favour of alphagov/govuk-design-system#4220. Reasons:

• We expect teams to mostly do their own styling of their autocompletes and keep the base level CSS light
• As I've found with Add styling for site search input 'flowing' into dropdown govuk-design-system#4220, this can be done 100% with css and we'd have to reapply this styling ourselves anyway

If this turns out to be useful for users who aren't styling their own autocompletes, we may reopen or restart this.