If you conduct remote usability research with accessibility top of mind, you will soon encounter users who rely on screen readers to help them navigate digital environments. Many researchers don’t have prior experience with screen reader users—and that’s ok! Follow these tips to make the most of your research sessions:
Tip 1: Remember that visual impairment is a spectrum.
Most screen reader users are visually impaired, but it’s important to keep in mind that blindness is a spectrum. According to the Perkins School for the Blind,
“When most sighted people think of blindness, they think of a world in total blackness. But, this is far from accurate. A variety of eye diseases, genetic disorders, and birth defects, as well as aging or suffering an injury, can interfere with healthy vision. And these visual impairments don’t all ‘look’ the same.”
Don’t assume that your participant is wholly blind. Plan your study around their use of assistive technology, not their assumed level of sight.
Tip 2: Create accessible prototypes.
Figma prototypes and Figma Sites don’t translate all necessary semantics to code, making them very difficult, if not impossible, for screen reader and voice command users to interact with.
For example, Figma doesn’t have a feature to create semantic headings (the equivalent of an <H1> or <H2>). Since many screen reader users navigate by heading, this creates a prototype that’s very frustrating to use and not true to the user’s actual experience. And some functionality simply doesn’t work or is completely inaccessible.
To conduct usability testing with screen reader or voice command users, you need to do one of the following:
- Create a coded prototype in a tool like CodePen, Codespace, or AI-powered prototyping tools like Lovable. Note: AI prototyping tools do not build fully accessible code and prototypes out-of-the-box. If using AI prototyping tools, plan time to review and edit the code generated.
- Create a coded prototype on a staging server.
- Create a partial prototype by putting your flows into Microsoft Word or Google Docs. Use semantic headings, accessible link text (if applicable), and appropriate color contrast.
If you can’t create an accessible prototype in time, you can try screen reader Wizard of Oz testing.
If your participant has limited vision, but doesn’t use a screen reader, you can use a Figma prototype. It might be difficult for them to interact with, so ask the participant to describe what they would do next, then have the researcher physically activate links and buttons.
And avoid asking users to log into an account to access the prototype (unless you’re testing the login process). Authentication can be very cumbersome; it may frustrate your participant and take time away from your research goals.
Tip 3: Prepare for assistive technology use ahead of time.
Find out what assistive technology and devices research participants plan to use during the session. Then, try out that technology, or something similar, on your own. This will give you a sense of what to expect during the session.
For example:
- Your participant is planning to use VoiceOver, a screen reader, on their iPhone. You don’t have access to an iPhone, so you watch iOS VoiceOver demos on YouTube and try out TalkBack, another screen reader, on your Android phone.
- Your participant is using a screen magnifier. You learn how to use your Mac’s Zoom feature, then try it while using your prototype.
If you’re testing with a screen reader user, have the relevant screen reader keyboard shortcut cheat sheet open so you can provide support, if needed.
Tip 4: Plan the session.
Write your conversation guide with the participant in mind:
- Give participants options for accessing your prototype: chat, email, or reading the URL aloud.
- Use a link shortener to create a URL that’s easier to dictate.
Don’t use directional language to refer to page elements. Remember, screen readers access one item on the page at a time. “Next” and “previous” make sense in that context, but “left” and “right” don’t. If a user asks where something is, give them directions relative to other items on the page.
- For example, if a participant doesn’t know where the “Submit” button is, tell them it’s the first button after the “Review” heading.
- Hold a pilot session to practice the moderation guide. A team member familiar with the assistive technology used in sessions can help you go through a pilot session.
Consider asking an accessibility specialist to provide support during the call, if one is available. It’s also valuable to have an accessibility specialist act as a notetaker during the session. They can often capture detailed notes on why certain issues are occurring with assistive technology as they happen.
Tip 5: Account for the screen reader during the session.
Screen readers are verbose by nature—they announce all semantic information on a web page—and start reading a screen on page load by default. It can be difficult for a screen reader user to hear someone talking over the screen reader, let alone take in two “conversations” at once.
There are many ways to navigate using a screen reader. Users may access content line by line, use the rotor to review headings or links, or tab to interactive elements.
Work with the screen reader, not against it. Here’s how:
Ask the participant to select the “Share sound” checkbox (on Zoom) when sharing their screen. On a desktop, this will allow everyone on the Zoom call to clearly hear the screen reader.
- Note: This feature doesn’t work on mobile devices. If the participant is using their phone, don’t expect to hear the screen reader; rely on the visual focus outline to see where the participant is focused on the page.
- Don’t talk over the screen reader. Give the participant time to hear their screen reader, then ask your questions.
Provide instructions before participants load a new page.
- For example, you could say, “After selecting ‘continue,’ I want you to explore the page. Don’t click on anything or leave the page. Tell me when you’re done, and then I’ll ask you a couple of questions.”
Observe the participant’s screen reader settings and navigation habits. The screen reader may be set to a very fast speed or a slow one; they may navigate by heading or by tabbing. Don’t ask the participant to change how they use their technology.
- If you aren’t sure how they’re navigating your product, ask. “I wanted to confirm—are you using headings to explore the page?”
Tip 6: Follow-up after the session.
After the research session, pay the participant and thank them for their time. If the project allows, you can follow up with the participant after the study is completed to share the improvements made to the product/service as a result of the feedback gathered. This can help participants feel that their participation had a real impact.
Tip 7: Document and make a plan to address findings.
Ensure any research findings are documented in a backlog, and that there’s a plan in place to address them. You want to avoid research findings and opportunities for improvement getting lost or forgotten. High-priority issues (e.g., 508 compliance violations) identified in user research sessions should be addressed as soon as possible.