A search feature can help your users find the content they need, and in some instances (such as eCommerce), search forms provide essential functionality.
That’s why you need to think about accessibility when designing search components. By following accessibility best practices, you can create a search form that works for users with disabilities — regardless of the techniques or technologies they use to access your website.
In this article, we’ll discuss some of the most common errors that developers make when building search forms, and we’ll explain how to fix those errors. For help with a specific accessibility issue, send us a message to connect with an expert.
1. Make sure your search component has a descriptive label
Every search form needs a visible label that accurately describes its purpose. Otherwise, people who use screen readers (software that outputs text as audio or braille) may not understand that they’re dealing with a search component.
Use the <label> element with the for attribute, and make sure that the for attribute matches the id of the input field. For instance:
<label for="search-field">Search:</label>
<input type="text" id="search-field" name="search">
The label should read something like “search.” If the search field is specific to a certain part of your website (for example, your eStore), you can also include that info. Just don’t write too much — users don’t need a complete set of instructions within the <label> element.
Providing an accurate and appropriately descriptive label will help you conform with several criteria in the Web Content Accessibility Guidelines (WCAG), including Success Criterion (SC) 3.3.2, “Labels or Instructions,” WCAG SC 1.3.1, “Info and Relationships,” and WCAG 2.1 SC 4.1.2, “Name, Role, Value."
By including the label, you’re showing the purpose of the input field — which screen readers cannot do on their own. Visual and non-visual users will be able to interact with the search feature.
For additional guidance, read: Missing Input Labels: How to Fix a Common Accessibility Issue
2. Make sure that placeholder text is readable
Placeholder text appears inside of the input field to provide users with an example of the expected input. It’s helpful shorthand for showing the user what a query should look like, provided that you use it in an accessible way.
Keep these tips in mind:
- Make sure that the placeholder text conforms with WCAG’s requirements for color contrast. Low contrast between placeholder text and the background can make the text difficult or impossible to read.
- Make sure that the text disappears when the user begins to type. If the user needs to delete all the placeholder text before entering a query, that’s obviously not a great experience.
WCAG SC 1.4.3, Contrast (Minimum) requires a contrast ratio of at least 4.5:1 for normal text (and at least 3:1 for large text, but in context, placeholder text is almost always “normal,” not “large”). You can test color-pairs against WCAG guidelines with AudioEye’s free color contrast accessibility checker.
3. Make sure that form errors are relayed to the user
If a user makes an error when interacting with a search form (for example, if they submit a blank query), they need to be informed of the error.
- The error message should concisely explain what went wrong and how the user can fix it.
- If the query needs to be in a certain format (for example, a date search must follow a month/day/year format), include that info.
- The error message must be programmatically determinable (different user agents can recognize it and present the info to the user).
Use clear and concise language to describe the problem, and provide instructions for fixing the error. Note that you may need to use ARIA (Accessible Rich Internet Applications) markup to ensure that the error message is programmatically determinable for assistive technology (AT) software — if the new text appears on screen without sending a signal to AT, the user might not be aware of it.
Identifying the error will help conformance with WCAG 2.1 SC 3.3.1, “Error Identification,” and WCAG SC 4.1.3, “Status Messages.”
For additional guidance, read: Tips for Meeting WCAG's Requirement for "Error Suggestion."
4. Test your search form for keyboard accessibility
Keyboard accessibility issues can severely impact users. If you ignore the rest of this article, don’t ignore this point: You must test input fields with a keyboard to make sure that they’re accessible without a mouse.
To test your search form, try navigating to the form and completing a search using only your keyboard (use the Tab and Shift+Tab commands to move between elements). You should be able to access the search field, enter text, and submit the form.
You should also be able to move your keyboard focus away from the input field without executing the search. That’s crucial: Keyboard traps, which prevent users from regaining control of their web browsers, are extremely frustrating for real-life users.
WCAG SC 2.1.1, “Keyboard,” requires that all functionality is available via a keyboard interface. while SC 2.1.2, “No Keyboard Trap,” prohibits anything that traps the keyboard focus within a subsection of the content. These are easy issues to test, though fixing bad JavaScript might be tricky in some circumstances.
For additional guidance, read: Avoid "Keyboard Traps" To Make Your Site More Accessible.
5. Make sure that the input field has a visual focus indicator
WCAG SC 2.4.7, “Focus Visible,” requires that “any keyboard operable user interface has a mode of operation where the keyboard focus indicator is visible.”
So, why is visual focus important? As we’ve discussed, many people use keyboards to browse the web, but they may not use screen readers — and if they don’t have a visual focus indicator to show them where they’re at, they’ll become confused (and they’ll probably have a bad impression of your website).
To that end:
- When a keyboard user navigates to an interactive element, that element should have a clear visual focus indicator.
- The focus indicator might appear as a colored outline or a change in the element’s style.
- While you can use color as a way to draw attention to the focus indicator, you should not rely on color alone.
The safest course of action is to avoid messing with the default CSS for focus indicators, but even if you haven’t made changes, make sure you test your search field.
Is the focus indicator clearly visible? If yes — and you’re not relying on color alone for the focus indicator — you’re in good shape.
Related: What You Need to Know About Visual Focus and Accessibility
Remember to test all user input components — particularly forms that provide important functionality
If you’ve read through all of these points, you’ve probably recognized that accessible search fields are simply good search fields. All of these best practices are simply good user experience (UX) design.
But while they’re easy to implement, if you never test your content, you’re bound to make mistakes. Prioritize accessibility when designing your website (especially if you’re implementing something like a search bar, which has a high potential to impact the end user).
If you’re ready to start testing your content against WCAG, get started with a free automated audit from AudioEye’s Website Accessibility Checker.
