feat: use autocomplete web component in FindProperty

[jessicamcinchak]

replacing material ui autocomplete (which continues to fail a11y audit) with gov-uk's accessible-autocomplete wrapped in a Lit web component that additionally handles fetching addresses from OS Places API

https://887.planx.pizza/opensystemslab/test/preview

changes / todos:

• remove material ui autocomplete code & deps, add web component
• support "back" button & "change" (feat: address-autocomplete supports a default value map#120)
• refactor tests, taking into account no access to shadow dom
• clean up styling inconsistencies / figure out how to override web component styles (not an audit blocker though!) (feat: Allow autocomplete to be styled from parent map#124 💅)

most recent accessibility feedback to keep in mind while testing:

Our screen reader found the following issues with the autocomplete and strongly recommends the GOV.UK example if possible.] Hope that this is of some help.

JAWS and NVDA
A button reading as ‘Open’ appeared after the item which then changed to ‘Close’ once I entered the item. I was not able to determine either in or out of context what this related to and what would be opened or closed. In a testing environment I would not expect an additional button to be present in relation to an auto complete feature as the auto complete element itself should perform an action by itself without other related content.

When I entered the auto complete item I found that using the up and down arrow keys automatically led me to the options.

I did not receive any instruction on how to use the feature and was not advised that options were filtering as I was taken directly to the first option when I entered characters and pressed the down arrow.

Although a prompt appeared after the result to advise me the number of results I would not have been aware of this content in a non-testing environment and would have been unaware that options had filtered.

If using the component in a non-testing environment I would not have been aware of what was occurring and would have used the item as a standard combo box.

VoiceOver
With VoiceOver the ‘Open’ and ‘Close’ button was consistent with desktop screen reading software.

An instruction announced to me to indicate how the auto complete should be used, however the instruction advised me to type and use the arrow keys which was an incorrect instruction for a touch device and prevented me from understanding how the item should be used.

When I entered characters the options filtered but I was not given an indication that the options had filtered, instead receiving the same instruction that the arrow keys should be used.

I attempted to explore by touch to locate the filtered options but was unable to locate the content with the keyboard collapsing and my focus being taken out of the field.

I was not able to identify the options in context and would not have been able to select an option.

I would not have been able to continue through the service as I would have been prevented from selecting an address.

TalkBack
I located the ‘Open’ and ‘Close’ button but was not aware of what it related to.

I did not receive a prompt either in or out of context to advise me of how to use the component on the page and was not advised that options had filtered.

After extensive exploration in a testing environment I found that I needed to use the ‘Open’ button to view the options rather than the input field but I would not have been aware of this in a non-testing environment and would have been unable to use the component.

Either using a standard combo box, or using a different auto complete component which advised me when options are filtered and how to select the item and works as a single component will prevent any confusion and will allow me to continue through the service.

future:
not using <postcode-search /> web component yet (that MUI input is not failing a11y audit, so will introduce in future PR), but on first try noticed that we'll probably want to dispatch an event on every input change, rather than only on validated postcode. currently, we lack a signal to know when to re-hide/clear address autocomplete if postcode is changing after the first validation.

[github-actions]

Removed vultr server and associated DNS entries

[jessicamcinchak]

Learned an important thing about web components here: it's going to render <address-autocomplete .../> in the document during testing, not the full shadow DOM as if you were inspecting the live service.

Therefore, we can't actually test typing input, selecting an option from the dropdown, etc. This feels a bit weaker overall, but we can still test valuable things like if the "postcode" prop has updated as a result of a new postcode being typed in.

Going forward, I think the answer will be to add these types of behavior tests directly in the web component repo (using https://open-wc.org/docs/testing/helpers/ maybe?) & then test for correctly setting props here. Does that make sense?