At Sajari we regularly review the search interfaces we provide to ensure they meet Web Content Accessibility Guidelines (WCAG) and the Americans with Disabilities Act (ADA) digital standards. WCAG are guidelines that are published by the Web Accessibility Initiative of the World Wide Web Consortium, the international organization dedicated to developing international standards for the internet.
After conducting our most recent audit we decided to put down some of the different aspects of accessibility that need to be considered when building and managing a search interface. As daunting as it may sound, conducting a WCAG compliance audit was not as complicated as we first imagined it to be.
If you are building a custom search interface or reviewing a site search installation on your website, this blog will guide you to ensure that your website search experience is compliant with WCAG 2.1 AA standards.
As an aside, we also created this checklist to track my WCAG audit, and it might help if you are running one, too.
But first we wanted to touch on why accessibility matters.
Why does accessibility matter?
A 2016 report by The Global Economics of Disability estimates that the global population of people with disabilities, including age-related disabilities, is approximately 1.3 billion. This amounts to nearly one in every five people.
It's reasonable to assume that a significant number of your website visitors will be people with disabilities. Governments, community services organizations, educational institutions, and large enterprises across the world need to make sure that their digital services and websites are compliant with WCAG.
The increasing importance of web accessibility is clear from this Google Trends chart over 3 years for the term ‘WCAG’.
When designing websites and interfaces, developers and designers alike should be mindful of users with disabilities and temporary or situational limitations, such as:
- Vision-related impairments, such as color blindness.
- Auditory impairments, such as deafness or people hard-of-hearing
- Cognitive impairments
- Neurological impairments, such as photosensitive epilepsy, autism or seizure disorders.
- Speech impairments
- Physical impairments
- Age-related impairments.
- Temporary disabilities, such as a broken arm or lost glasses.
- Situational limitations, including things like bright sunlight, slow internet connections, or environments where audio cannot be played.
For such disabilities, aspects of your website like color contrast, animations and transitions need careful consideration, and appropriate alternatives should be made available. For a complete list of disabilities that may affect the use of the web, click here.
Key principles of WCAG
WCAG consists of 4 key principles, and being compliant with WCAG means that sites must be:
- Perceivable - Information and interface must be presentable to users in ways that makes it easier to perceive.
- Operable - The user interface components can be operated with ease.
- Understandable - the information presented is understandable.
- Robust and structurally sound - so it can be compatible with future assistive technologies.
A more detailed description of these four principles can be found here.
Levels of conformance
The WCAG guidelines have four main principles (as mentioned above), and each principle has various guidelines. Each guideline is then categorized into three levels of conformance:
- A (lowest),
- AA (mid-range), and
- AAA (highest).
To see the detailed list of guidelines and conformance, click here.
Level A sets a minimum level of accessibility and does not achieve broad accessibility for many users. Generally, most organizations attempt to achieve AA.
It is crucial to note that if your search interface or any other web component does not comply with the same level of conformance as the rest of your website, then the overall website will also be degraded to the level of compliance of the component.
How to ensure WCAG compliance for your Search Interfaces?
A quick audit tip
One of the easiest methods to test compliance is to use the Voiceover utility in Mac OSX. If you are testing on Windows, you can use Jaws (https://www.freedomscientific.com/Products/Blindness/JAWS) or other voice assistance software.
This user experience test will accomplish a few things:
- Test accessibility for people with vision impairments.
- Test compatibility with accessibility software and assistive technologies.
- Test HTML structure, as the voiceover utility will only make sense and work properly if the content is structured correctly with the right descriptions and alt-tags.
By completing this simple test, you will uncover most (but not all) of the problems that need to be addressed to achieve compliance with WCAG.
How to make Search Bar and Icon accessible?
A few key considerations for making sure that the search experience of the search bar and/or icon on your website conforms with WCAG 2.1 (AA) are mentioned below:
- Predictable. The search bar should be placed in a predictable location. Generally, this is the top right corner of the website.
- Distinguishable. The color contrast of the icon or text should be distinguishable and have a contrast ratio of at least 4.5:1.
- Alt-text. If you are using a search icon, such as a magnifying glass, the image should have an alt-text = “Search” within the <img> tag. The icon in the search bar should have an alt-text to describe the icon as it is non-text content. Sajari’s standard website search interface uses aria-label=”Search” within the ‘button’ div-class. Aria-labels are used to provide a label for objects that can be read by assistive technology. See examples and application in detail here.
- Focus Order. Users should be able to navigate and operate the search interface easily. When they enter the search query in the search bar, the keyboard focus should remain within the search bar so the user can continue to enter or modify their search query. Moreover, if they navigate using 'Tab', the focus order should be sequential and match the HTML/DOM. Ideally, users should be able to navigate from the search bar to search results, then to pagination, and then to URL of the page in the browser and then back into the webpage using their keyboard.
- Identify Input Purpose. If you are using a search bar, the search field should have a label describing the purpose of the text field. In Sajari's standard website search interface code below, you can see the aria-label ”Search through the site content”.
- Keyboard Accessible. Users should be able to navigate in and out of the search input field using keyboard ‘tab’ button (watch out for the keyboard trap).
How to make Search Results accessible?
The search results page on your website can be set up in a variety of ways, such as a grid or list, depending on your website design and user experience requirements. Here I’ll use the example of our standard website search results displayed as a list, but the key considerations will apply to any design that you are using on your website.
- Keyboard Accessibility. Once the search results are displayed, the users should be able to navigate through the results using the keyboard ‘tab’ key. The description and the status message (i.e x results for ‘search query’) is not accessible through the keyboard ‘tab’ button. However, the screen-reader software or voiceover utility should be able to read the description and status message. This ensures all the necessary information is available to the user but it does not interfere with navigation.
- Status Message. After a user enters a search term, the content of the page is updated and results are displayed. A status message should be picked up and read by a screen reader automatically. By adding a role=”status” message in the code, the screen reader will announce, "x results returned". To view an example of the use of aria-label ‘status’ and a further explanation, click here.
- Search Results Images or Media. The search results interface only shows images for decorative purposes. Hence, the images of the search results do not need to be focused on when the user navigates through the search results. They don’t require an alt-text either as there is no loss in information.
- Pagination. If you use pagination to allow users to navigate through the search results, it should be accessible and operable through the keyboard.
- Distinguishable. The color of the text for title, description, URL and other elements should have a contrast ratio of at least 4:5:1 for visibility. You can test the contrast ratio using this tool.
- Adaptable. Check the search results in both ‘Portrait’ and ‘Landscape’ orientation on both desktop and mobile devices. The text of the search results must be able to be resized up to 200% without any loss in content or functionality.
- Using an overlay Interface. If you are displaying search results in an overlay window, the user should be able to navigate to the close button, and the close button should have the correct aria label or alt-description (if it's an icon).
- Filters & Facets. All filters and facets should be accessible and operable through the keyboard and have the right aria-label descriptions that explain them appropriately, along with the status of those features. View the details about the aria-labels grouping controls here.
These were the few key considerations that we keep an eye on while testing out our SDK releases or if there are new updates to the WCAG, which happen frequently.
By ensuring WCAG compliance, you standardize the experiences for people with disabilities across the web and make it easy for everyone to understand the content and operate your user interfaces. Moreover, you also broaden your market substantially by opening up access to some of the 1.3 billion adults estimated to be living with a disability.