I often rely on the experience and research of others to work out the best way to do things. Today it was search forms.
I’m talking about the simple forms most sites have for searching their contents, often positioned at the top of every page. There’s not much to them but they can vary, and I wanted to know what best practice was, particularly in terms of accessibility. Should they have a visible label (“Search”)? Should they also have some placeholder text (the pale text in the search field itself)? Should they have a submit button?
Because I’m getting on a bit I tend to assume that the more clunky and old-fashioned something is the better (assuming the correct HTML mark-up behind the scenes). With search forms, this often competes with wanting something neat and compact and attractive, and I see that on both The Diary of Samuel Pepys and this site I’ve opted to hide the form’s label (but show it to screen readers) and keep a submit button.
I’ve seen people say that you should avoid relying on placeholder text, but these are usually talking about bigger forms with several fields. To quickly pick two posts from a Google search, Placeholders in Form Fields Are Harmful and 4 reasons to avoid using placeholder text in forms.
But what about little search forms? I did some googling and, so far, I am only slightly wiser. These days there are a lot of good people in governmental organisations making, and writing about, accessible web development so, as examples, here are three things I read from these folks…
(By the way, I’m ignoring some of the gritty details of the HTML markup, such as ARIA attributes, because that’s a whole other set of things for people to disagree about how best to use.)
First, GOV.UK’s Design System has a page about text input fields which is all very nice. But it doesn’t specifically mention simple search forms, and the site’s own search form contradicts the page’s advice that says:
All text inputs must have visible labels; placeholder text is not an acceptable replacement for a label as it vanishes when users click on the text input.
The search form itself doesn’t have a visible label or a submit button, because it’s not quite a standard search form. As you type it provides a list of auto-completed results and you must select one of these. Pressing Return to submit the form does nothing if your term doesn’t match one of those results:
If we look at the search form on the main GOV.UK site we see it has no visible label and has a button that shows a magnifying glass icon (it’s an
input with a
value of “Search” and the icon is a
Parliamentary Digital Service
The UK’s Parliamentary Digital Service has a blog post about its search form component, which is currently in use on its beta website. Again, they don’t have a visible label and the submit button shows an icon of a magnifying glass. In this case it’s a
button containing an SVG icon that has a
title of “Search icon”.
The U.S. government’s Web Design System site has a page all about their search bar component. Again, they only keep the label for screen readers and have a submit button:
The smallest size only shows a magnifying glass for the button: it’s a
button element with a
background-image and screen-reader-only text reading “Search”. Regarding this icon, they say:
The magnifying glass has been shown to be almost universally recognized by users as an indicator of search, and doesn’t need to be visually paired with the word “Search” as long as it remains for screen readers.
I’m not 100% sure which U.S. government sites have been brushed by the Web Design System. Data.gov looks clean, although I think it uses Bootstrap so maybe it doesn’t use the same components. Anyway, their search form looks similar:
This one has no visible label, and has a
button containing an icon and screen-reader-only text of “Search”.
These examples are all pretty consistent:
labelcan be visually hidden, kept only for screen readers.
- Use placeholder text to say it’s a form for searching the site.
- The submit button can read “Search” but can only show a magnifying glass, keeping the text for screen readers.
- The submit button can be “grouped” with the text input, rather than keeping a space between them.
I guess this consistency is good, and it’s a recommendation for how to do it. I’m still a little wary though. I’ve heard of people being confused of placeholder text, wondering why this text disappears when they click/tap the field. I wouldn’t be surprised if some people don’t realise the magnifying glass is a thing to click/tap to submit the form, although Google uses one that is even less button-like so maybe submit buttons aren’t even expected?
If you know of any well-reasoned articles/posts about this, or have conducted or seen good user research, then do let me know, particularly if it conflicts with the examples above.
UPDATE: There’s a discussion of search forms on the GOV.UK Design System backlog GitHub repository, although it doesn’t really have a conclusion about the best way to do things. (2018-12-06)