Research approach to accessibility

magnifying glass icon to denote research

“The ADA standard for reasonable accommodation asks ‘what is the minimum standard?’ It doesn’t ask ‘what is the best way for people to engage in this space?’” - Keith Doane, Gallaudet Innovation & Entrepreneurship Initiative

Compliance with Section 508 of the Rehabilitation Act of 1973 is the bare minimum standard for a website to be considered accessible. It is possible for a website to be technically compliant and still be functionally insufficient for someone who is blind, uses a screen reader, or navigates the internet using a keyboard only.

Accessibility testing is necessary, but it is not sufficient. Watching real people use our sites with screen readers, keyboards and other web navigation methods beyond sight helps us implement web products not merely pass a test, but are truly usable for all of our users. Here are some of our best practices for accessibility usability research:

Run accessibility research with the participant’s own equipment.

Observing how actual people navigate your site using their preferred computer, web browser, and assistive technology provides the best vantage point to observe where a participant’s patterns for browsing might be impeded by your website. As you recruit participants, ensure your overall research panel includes a variety of combinations of devices, browsers, and assistive technology: some of the most popular combinations include JAWS and Internet Explorer, or NVDA and Firefox on a PC, and VoiceOver and Safari on MacOS and iOS devices.

How do they get from your homepage to an interior page?

People who do not navigate websites by sight relate differently to website structures as well, and sometimes tools that are helpful for sighted users, including navigation, can get in the way. By asking a screen-reader user to navigate to a specific page or topic from your homepage, you will observe how they orient themselves to the page structure, and whether they use search or tab through the navigation to figure out where the requested item might be. You’ll also hear how the screen reader identifies elements of the page, and you can ask follow-up questions to learn whether the participant’s understanding of what components will do match up with what will actually occur. Once on the interior page, listen for whether the participant can skip past headers and navigation to the content they want, or whether the presence of navigation confuses their understanding of what page they’re on.

Will this button do what I think it’s going to do?

A user who navigates by sight may interact with buttons and links the same way, but buttons respond to different key presses than links do, meaning that someone who navigates only by keyboard might understand them as serving different purposes. Even more confusing, some websites might have an element that looks like a button, but uses an ARIA label that identifies it as a link. Ask your participant to perform a task that will take them between pages via a link, or that involves a button that will trigger an action. While they do so, ask about what they expect the element will do, observe how they interact with the keyboard to trigger the element, and ask again whether the result of the action is what they expected. Our team has had success in asking participants directly how they think about what buttons and links do and whether they’re different; in the end, the most important part is being consistent about how you label your elements. If there are forms or interactive menus on your site, make sure to ask the participant to interact with those as well. Are they able to interact with the elements? If new text or options appear after the interaction, how are they notified about these new components? Are they able to browse through a form’s fields without having to fill it out as they go? Is there a pop-up that is invisible to the screen reader and can’t be closed?

Making accessibility a part of our research process

At Ad Hoc, working with research participants who are blind has led our teams to think deeper about overall information architecture, and to keep our focus on function over flashiness. When we ensure our websites are usable by people who use assistive technology, we build better experiences for everyone.