If your company is working on improving the accessibility of the website for people with disabilities, ensuring your content is accessible to screen reader users will be one of the focuses. As you and your team are busy making changes to your website, software and other digital assets to ensure they’re accessible, you will likely have a lot of questions:
- How can you tell if these changes are effective?
- What tests should you run?
- When should you test? During design or after deployment?
This post aims to demystify the accessibility screen reader compatibility testing process and show you how screen reader testing can reveal your successes and where your site still contains accessibility barriers.
Screen reader basics
Screen reader software is an assistive technology tool, often used by people with vision impairments, that converts text, buttons, images, and other screen elements into speech or braille.
JAWS® (Job Access With Speech) is the world’s most popular screen reader, made for use with the Microsoft Windows operating system. This software can read text and other elements at varying speeds and has more than 100 shortcuts for navigating and searching. While there are other screen reader software available, we will be focusing on JAWS® in this article.
What is screen reader accessibility testing?
What’s the best way to see if your site can be read by a screen reader? One option is to purchase the screen reader software and actually experience how a screen reader could read the content on your website. While this seems like a good option, there is a steep learning curve to using these tools.
Another option is using a screen reader testing tool, such as JAWS Inspect. JAWS Inspect is an excellent tool that helps companies simplify the JAWS compatibility testing process. It produces transcripts of JAWS output so that you can easily diagnose issues and export them across quality control and compliance systems. JAWS Inspect won’t specifically call out errors and bugs, but it’s a tool you can use to find those issues.
JAWS Inspect is also very easy to use. It doesn’t require technical expertise–really just simple training to run the program. The testing results are also clear and easy to understand without the need for deep expertise in the WCAG guidelines.
What makes a good screen reader test?
When selecting screen reader accessibility tests, companies should find tools that test the user experience as well as technical accessibility. This doesn’t have to be an all-in-one solution, but your accessibility testing tools should cover both sides of the accessibility coin.
For example, in JAWS Inspect, you would review whether images have alternate text descriptions written in a way that makes sense from a user perspective. On the other hand, a technical testing tool like ARC Toolkit looks at whether the alt text for the image has been coded correctly following the WCAG guidelines and technical standards.
Using both tools is essential to get a full accessibility picture. While some companies may opt for simply reviewing only the technical side of accessibility, it won’t tell you how usable or understandable it is unless you use screen reader software to navigate through that content, listen to how it is announced, and interact with it.
Five screen reader software accessibility tests
When building your accessibility testing process, it helps to start with essential elements on the page for basic navigation. These five tests, while only a part of overall accessibility compliance testing, cover a large range of baseline standards.
Test 1: Non-text content
Because computers cannot “see” images like charts, illustrations and photographs, website developers must include alternative text, known as alt text, for all non-text elements that convey information. The alt text describes the elements in a way that can be read by screen readers.
To test whether your site uses effective alt text, use the Full Page Report in JAWS Inspect. Start by going to the Graphics section in the report. There you can see what JAWS announces to the user when it reads the page.
What kind of errors should you look for? If there is no alt text on the page, JAWS will look for something that can serve as a description, often the image file name. While this might offer some description, often it is not enough to provide context. Look at all the images listed in the report to make sure they have adequate and not overly verbose descriptions.
Test 2: Headings and document structure
People who visually read pages may take structure for granted, but when it comes to screen readers, structure is important to interpreting complex page content and layouts.
Bring up the JAWS Inspect menu again and run the Say All report. This reads the page in linear order, top to bottom. On pages with multiple items in multiple sections, it can be arduous to go through the entire page via a screen reader to hear what’s there and decide how to navigate it. Having proper headings (H tag) hierarchy is essential for effective screen reader navigation (as well as SEO and an overall positive user experience). That means H tags that are short and easy to understand and are nested in a logical order.
In addition, developers can add “regions” to the page which divide a page up into semantic chunks (header, main body, footer, etc.). This makes it easier for someone using a screen reader to know if a section has what they’re looking for right and for users to quickly skip to the content they want.
Test 3: Form labels
When creating a form for lead capture or contacting the company, each field has a label, such as first name, last name, and email address. If the form controls are not properly coded it may not be clear to the screen reader users what the controls are, what they are supposed to do with them and what state they are in (e.g. checked or unchecked)
Using the full page report in JAWS Inspect, go to the control section and review the form fields. Here, you can see a transcript of what the screen reader provides the user. Look for places where required fields are not indicated, where the labels are not announced together with their related controls, and other errors within the form.
The ARC Toolkit is also helpful in determining the accessibility of your forms. The Forms section of the Toolkit report will indicate accessibility issues in red, such as improper tagging and what information is missing on the technical side of the site.
Test 4: Keyboard and interaction
Keyboard accessibility is a basic and essential requirement for screen reader users but it also affects a great many other users. To test, open the Speech Viewer in JAWS Inspect. This tool provides a transcript in real time of what the user would hear when browsing the site with JAWS running.
Using just the keyboard to navigate the page, look at what you see and what the screen reader is providing. For example, did the developers highlight where the cursor is moving when you hit tab? How does it navigate through menus and options?
Remember, If it’s not operable using the keyboard alone, then chances are most assistive technology users are really not going to be able to use your site.
Test 5: Links
Links connect users to the pages and features of a website and application. If not accessible, users can only access a portion of what your site has to offer.
In JAWS Inspect, open the Links tab in the Full Page Report. You can quickly see where the anchor text of each link fails to provide context to the link, such as where the link goes and what users might find when they get there.
Need assistance with your screen reader accessibility testing?
Screen reader testing is an important first step in determining the accessibility of your website. It’s also an important part to ensuring inclusive user experiences for people with disabilities.
While we focused primarily on JAWS Inspect and ARC Toolkit in this post, you can continue your learning by better understanding some best practices for accessibility testing. If you are looking for assistance in running other tests or would like to review important user journeys on your website, contact us. We love testing and are happy to chat.