Providing accessible search suggestions

Update Septenber 2, 2022 at 3:30 p.m.: The component has been modified after the second test. The third version of this component attempts to fix two issues with the component.

Update September 2, 2022 at 9:15 a.m.: The component has been modified after the first tests and some feedback has been incorporated. The second version of this component attempts to implement three new ideas.

This is a series of tests to discover how to accessibly provide search suggestions for a search widget that can be included in any page within the website to allow users to search through content available on the site.

This widget is not a dedicated search page, but instead will accept user input and redirect the users to the dedicated search page to show the results.

The test here is to determine how to accessibly provide autocomplete suggestions for the user. The main goal of the test is to improve the accessibility of the simplete component, since that currently has some accessibility problems.

Test Goals - Iteration 1

In the first iteration of the tests, we ensured that the following goals were achieved.

  1. Assistive technologies announce that there are autocomplete options available when the focus is within the search field.
  2. When users cycle through the available options, these are announced to the user.
  3. The options which are provided within the list of autocomplete selections are only accessible via the arrow keys and not reachable via the Tab-key.

Additionally, we want also want to improve the user-experience for the widget as much as possible. Selecting an autocomplete suggestion should result in the same behavior as typing a user defined search string and executing the form would result in. In our case, we redirect to the results page in both cases.

Test Goals - Iteration 2

In the first test, we were able to achieve the aforementioned goals. After some feedback, the second version includes the following changes:

  1. The widget should announce the number of search suggestions available to assistive technologies. For this, an aria-live region will be needed. Note: we want the widget to be able to support this, but this is a feature that we will need to test with users. It may not always be useful.
  2. The list of suggestions should be announced as a list in NVDA. This goal was achieved by adding a label to the ul element, without which the list information was not correctly announced in NVDA.
  3. The input field should use the combobox=role. See the question about combobox for more details.

Test Goals - Iteration 3

Here are the goals that we want to accomplish in the third iteration of our test:

  1. It should always be possible to revert from a search suggestion back to the original query by continuing to type. When the suggestion box opens and the user cycles through the available options, the user may decide that none of the options are relevant and want to continue typing to complete the original search query.
  2. One finding in the test was that it was sometimes possible that the text element used to announce the number of search suggestions was still read out when navigating from the search field to the search button in NVDA. I believe this occured when navigating in browse mode because the aria-live was still available as a text node even when the focus left the search field. This has been fixed so that the aria-live region is only active when the focus is the search field.

Question about combobox role

One question is whether or not the search field should have a combobox role . The autocomplete here is intended to provide possible solutions, but will not always provide all of the possible solutions. I was originally unclear if a combobox was the correct role, because for use case, we make no promises about providing all valid possibilities for the search field. However, because the WAI ARIA Authoring Practices Guide for Combobox explicitly uses a search field as an example for a combobox which provides some possible suggestions for the user but allows any content, I've decided to use the combobox role for now.

An alternative solution would be to use the aria-haspopup=listbox role instead.

How to test the widget

The search widget can be tested in the header of the page.

An alternate solution which has been used as a reference for the autocomplete implementation is awesomplete. The reason to prefer to use simplete would be because it supports the generation of the search suggestions dynamically on the server.