Input fields (search)

Research and rationale

The design of the search field is intended to match the text-inputs. This way forms benefit from the same research and maintain aesthetic consistency with other form fields. The general design builds on the research and pattern crafted by the DTA search component.

Placement

On a landing or home page, it’s recommended that the search box sits prominently in the top right area of the screen. (Nielsen Norman Group: Top 10 Information Architecture (IA) Mistakes ). We've adopted this for our design system as this where users naturally expect a search box to appear and is also the convention used by other design systems. Where this differs is on the search results page, where the natural position of the search box is closer to the search results. This helps to show a relationship between the results and the search query (DTA 2018).

Width

We've crafted our default search box to have a width that is approximately 27 Characters long which according to both the USA design system (2022) and Nick Babich’s article the ‘Best practices for search’ this length will accommodate most search queries. A Nielsen and Norman (2001) article on search best practices states that if the box is too small, the query will scroll and diminish usability.

Search button

We include the word “Search” in our button to assist screen readers (USA Design system 2022). On mobile this is hidden using CSS and replaced with the search icon for afford users more space to type their request. The search button design colour and appearance is also designed to match our primary action buttons to ensure consistency of interactive elements with our design system.

Mobile and desktop search

On mobile the search field is accessed by selected a toggle btn in the site header which then allows the user to access the search field. This pattern was designed based on a comparative review of a number of different search patterns used in design systems and government websites. We've reserved this pattern for mobile use only where space is an issue. This is because in our research we found that hiding search behind an icon has the following disadvantages:

• it makes the search feature field noticeable. When used without an open-entry text field, the icon alone is less prominent and, therefore, less noticeable (Babich 2017)
• it increases the “cost” of interaction because users have to take an extra action in order to access the search box (Babich 2017).

Within our mobile header pattern we've tried to ensure the search toggle button is positioned in the top right for consistency with the desktop design and it also includes the word search below it to make it as obvious and noticeable as possible.

Iconography

On large devices we've chosen to include the search icon at the beginning of the search field. This convention is used by Google which has one of the most recognisable search box designs. This pattern is also used by IBM carbon and Apple. Using an icon with the search field helps to ensure that it's instantly recognisable to users. This icon is removed on mobile though as the icon is already used in the menu and it replaces the word search on the button.

Advance search

We're currently working on advance search pattern that is available within the search results, this pattern only appears after the user has attempted their first search. The reason for this is the according to Nieslen and Norman (2001):

Advanced search leads users into trouble, as they invariably use it wrong. When it makes sense, offer advanced search as an option users can link to from the search results page: "Didn't find what you were looking for? Try advanced search."

Auto complete

According the the Gold design system (Formerly DTA) enabling the autocomplete attribute may risk the unintended exposure of sensitive queries for subsequent uses of the search form, especially where a browser may be in a shared environment. We've chosen to not include this on our websites by default for this reason.

Classes

Accessibility

Keep these considerations in mind if you're modifying the design system or creating a custom component.

Use a descriptive label

Provide a clear and descriptive label for the search box using the <label> element. Use the for attribute to link the label to the id attribute of the search input field. This makes the search box accessible for screen reader users and provides necessary context (WCAG 1.1.1, 1.3.1, 3.3.2).

Include a search button

Add a search button with a clear call-to-action, such as "Search" or a magnifying glass icon. Ensure that the button is accessible and includes a descriptive aria-label if using an icon (WCAG 1.1.1, 4.1.2).

Use appropriate input types and attributes

Use the type="search" attribute for the search input field, as this provides appropriate input controls for different devices and helps with accessibility (WCAG 1.3.1, 4.1.2).

Offer search suggestions with proper ARIA roles

If providing auto-suggestions or auto-completion, use appropriate ARIA roles (such as role="listbox" for the suggestion list container and role="option" for each suggestion) and manage ARIA attributes (aria-activedescendant, aria-expanded, aria-haspopup) to ensure the search suggestions are accessible (WCAG 1.3.1, 4.1.2).