Testing A11y using screen readers

Screen readers are essential tools for people who are visually impaired. They help users interact with computers and mobile devices. Automated accessibility testing can find some issues, but only real testing with a screen reader reveals all the errors.

Screen reader testing ensures a site meets accessibility standards like WCAG and ADA. True accessibility comes from designing every detail of a digital experience with inclusivity in mind. It invites people of all abilities to engage with content smoothly. 

Testing with a screen reader is more than finding mistakes. It’s about understanding users as individuals. We need empathy to see their experience on a site. By doing this, we connect design and development, always keeping the user at the center.

Types of screen readers

There are three screen readers, VoiceOver, NVDA, and JAWS. JAWS runs on Windows and is paid software. NVDA is free and only runs on Windows, and VoiceOver comes with MacOS.

JAWS is the most advanced screen reader and has many features that the other two don’t have. For instance, JAWS can add in words and text to help with semantics on elements. But if you know what to look for and how to test a site, using VoiceOver or NVDA will be sufficient to find accessibility errors on a site.

VoiceOver

VoiceOver is for macOS and it is only available on Mac computers. VoiceOver works best with Safari. While you can use it on other browsers, you may not get the best results or accurate testing.

To start VoiceOver, press Command + F5. Once VoiceOver starts, navigate to the page you would like to test.

VoiceOver short keys

NVDA

NVDA is a free screen reader for Windows users. It works best in Firefox, Chrome, and Edge.

If you're on a Mac, you can use BrowserStack to test NVDA. Start a new Windows test on Firefox, Chrome, or Edge and on the left navigation turn on Screen Reader to start testing with NVDA.

To start NVDA press Control + Alt + N. Once NVDA starts, open Firefox, Chrome, or Edge and navigate to the page you would like to test.

NVDA short keys

JAWS

JAWS is a paid screen reader for Windows users. It works best in Firefox, Chrome, and Edge.

Start JAWS, open Firefox, Chrome, or Edge, and navigate to the page you would like to test.

JAWS short keys

How to test

Turn on the screen reader, according to the OS that you are on. When testing, do not use your mouse; instead, use only your keyboard to navigate the site. Refer to the short keys for VoiceOver, NVDA, and JAWS.

As you test, put yourself in the shoes of someone who is visually impaired. Can you access the content, and does it make sense without seeing the visible page? Does it take too long to get to the content you want? Can hidden content—like a tooltip—be accessed? 

Turn on your preferred screen reader.

Start by having the screen reader read through the entire page and all of the content. 

1. Does it read all of the content?
2. Or is there content skipped which shouldn’t be?
3. Does it read the content in a logical order and follow the visible page layout? 

Once it has read through the entire page start checking these main things:

Headings and Landmarks to Bypass Blocks of Content

Screen readers help users navigate using landmarks. This approach bypasses content blocks and meets WCAG 2.4.1 standards. You can also use skip links, headings, and expand/collapse regions. These options work well with or instead of landmarks.

Does the name of the element match the visible element? For instance, does the screen reader say “heading” on visible headings?

Table Headers

Table headers should use <th>. Test this with a screen reader to ensure it reads the header before each row. Data cells must link to their matching header cells. If all cells in the first row are marked as <th> without a scope attribute, modern screen readers will usually assume the scope applies to the column beneath each header cell.

Link Text

Links must contain discernible text, either within the tag itself or programmatically. Many screen reader users like to listen to all the links on the page. If every link says “read more” that is not helpful to the user to distinguish between links. Ensure links have clear text. Change them to say, “read more about article x.” This gives users the info they need. Test menus with nested items to confirm the links are descriptive. Don’t forget to check the open/close menu button as well.

Forms

Check if “required” is read out on the form elements that are required. For checkboxes or radio buttons, does text read out telling the user what each one corresponds to?

Next, try entering wrong information into a form. Does it clearly show the error and give accurate details to fix it? Make sure it doesn’t depend on visual cues like color.

Then try submitting the form with the correct information. Is that success message informative when read with a screen reader, or is it just a visual cue like a green check mark? The message needs to clearly state to the user that the form was submitted, or that the search now has results to review. 

One part of the whole

Screen reader testing is just one part of ensuring a site meets WCAG and ADA accessibility. WCAG provides a list of rules for various areas that need testing. These rules cover everything, from text to multimedia, and offer clear examples for meeting each requirement.

True accessibility happens when every part of a digital experience is designed for everyone. This lets people with different abilities engage with the content easily. The main goal is to create a digital experience that users love.

If you are not visually impaired, you can make a site compliant. However, true accessibility requires several iterations and feedback from visually impaired users. It’s important to try your best to see things from their perspective. Testing with a screen reader helps you understand how users experience the site.