How to Accessibility Test

We’ve gone through 46 weeks of technical accessibility from a design and dev perspective, covering everything from navigation menus to color contrast, ambiguous links, and more. If you missed an article, you can find all Accessibility Weekly posts here.

As we near the end of this series, I’m switching gears from the nuts and bolts of accessible code to answering your questions about selling accessibility and building it into your processes. Starting with, how do you know if a website is accessible?

How To Know if a Website is Accessible

There are four ways to test websites for accessibility. Whether we’re building websites for clients or remediating existing websites, these are the steps that we follow to accessibility test the website.

1. Automated testing + fix all issues from automated checks.
2. Keyboard testing
3. Screen reader testing + fix all issues from keyboard and screen reader tests.
4. User testing

If the client’s budget isn’t big enough, we stop with screen reader testing and do not user-test the website.

Automated Accessibility Testing

Automated accessibility testing refers to using automated checkers to find problems. Automated accessibility checkers can help you find problems quickly – scanning your entire site within minutes.

You don’t want to pay a human to tell you all the images missing alternative text across a website. Instead, use an automated testing tool to find problems as you build or publish new content.

Here are some popular accessibility testing tools you might want to consider.

Single Page Scanners

These tools scan one page at a time and show you the accessibility status at the time of the scan but do not save the results.

• Axe by Deque: Free, open-source browser extension with paid upgrades. The pro version includes the ability to export issues to CSV and has guided tests to help with manual accessibility testing.
• Lighthouse Accessibility Audits: Free, included in dev tools in Chromium-based browsers. It uses some axe rules, but not all, and shouldn’t be solely relied on due to limited tests and lack of thoroughness.
• WAVE by WebAIM: Free, has a browser extension or webpage where you can enter a URL to test. One of the first to market and most well-known.

Other free browser extensions previously mentioned in Accessibility Weekly posts are HeadingsMap and TabA11y.

WordPress Plugins

The benefit of using a WordPress plugin to test for accessibility problems is that you see the reports in the WordPress admin on the edit screen, much like with an SEO plugin.

WordPress plugins that check for accessibility give you real-time feedback and can help you, your team, and your clients learn accessibility as you work on the website.

• Equalize Digital Accessibility Checker: (This is my plugin.) Has a free version that scans unlimited posts and pages, plus a paid version that includes full-site scanning and centralized reports on accessibility status over time. Has a front-end view of issues on the page to make them easier to find.
• Editoria11y Accessibility Checker: This free plugin scans the content area only with a small set of rules. It is intended for non-technical users and to supplement other testing tools.
• Sa11y: Another free scanner that checks the content area only and is geared toward content authors rather than developers.
• WP ADA Compliance Check: Free plugin scans 15 posts or pages with a smaller ruleset. The paid version includes more checks and doesn’t limit the number of posts and pages.

SaaS Scanners

In addition to the browser extensions and WordPress plugins, there are also SaaS Accessibility scanners that allow you to schedule weekly scans. These tools store scan results in an off-site reporting platform. SaaS accessibility scanners charge per URL and can be expensive – typically starting at $5-10,000 per year, but can be a good option for large government and university websites. They also sometimes check for other things like SEO and broken links.

Popular SaaS accessibility scanners are:

• Monsido
• PopeTech
• Siteimprove

Keyboard Testing

After fixing all the accessibility problems you can find with an automated checker, the next step is to keyboard-test the website.

To keyboard test, open the page you want to test and ensure you can do everything a visitor would do on the website without using a mouse.

Things to Look For

• Can you tab to every actionable element (links, buttons, form fields, etc.) using the Tab key? (Tab to move forward; Shift + Tab to move backward.)
• Are there functioning skip links?
• Can you always tell where you are because there’s a clear focus indicator?
• Can you access all the pages in the navigation menu?
• If a popup opens, does it function as an accessible popup?
• Can you use carousels?
• Can you open and close accordions?
• Can you fill out and submit the forms?
• Can you add products to the cart and complete a purchase?

Screen Reader Testing

After keyboard testing, turn on a screen reader and test how the website sounds for someone who is blind.

What Screen Readers to Use

There are two screen readers you can test with:

• VoiceOver – the screen reader built into Mac computers.
• NVDA – a free open-source screen reader for Windows.

Most blind people use Windows computers, so even if you’re a Mac user, you should test with NVDA. BrowserStack is one way to test with NVDA if you don’t have a PC.

How to Screen Reader Test

After turning on your screen reader, go through the website like you did during keyboard testing. You can tab through, but having the screen reader read the entire page can be helpful so you don’t miss anything.

You’ll want to reference the keyboard shortcuts for your screen reader to make it easier to use:

• NVDA Keyboard Shortcuts
• VoiceOver Keyboard Shortcuts

Things to Listen For

Listen carefully to what the screen reader tells you as you go through each part of the page, listening for anything that sounds confusing or wrong.

Here are some examples of issues to listen for while conducting screen reader testing:

• Inconsistent or unclear descriptions of page elements.
• Missing or improperly labeled form fields.
• Navigation that doesn’t provide adequate context.
• Images with incorrect alternative text.
• Dynamic content updates not announced by the screen reader.

Ask yourself as you go through the website: if you couldn’t see, would you understand the content and functionality on the website based on what you’re hearing?

User Testing

The gold standard in accessibility testing is hiring users with disabilities who use assistive technology daily to test your websites. If you can budget this into your client projects, it is well worth it because of how much you’ll learn from watching a screen reader user navigate a website.

If you want to learn more about planning and running user tests, watch this WordPress Accessibility Meetup presentation on how to run tests with real-world users.

Integrating Accessibility Testing in Your Workflow

The least expensive way to build accessible websites is to include accessibility early in the process. Start looking for accessibility before you start coding, checking for color contrast in your design files and that client copy includes meaningful links and headings.

If you have a developer on your team or you are the developer, teach them to, at a minimum, accessibility test with automated tools as they build before a website hits Q/A. In our agency, we expect developers to pay attention to the reports in our Accessibility Checker plugin and to fix these obvious problems before they submit the website for Q/A.

If you’re building from templates, you can use browser extensions and keyboard testing techniques on the theme demos before you suggest them to clients, so you make sure to start from a more accessible theme.

If you have a custom starter, invest time testing it and fixing it. This requires some upfront effort, but once you’ve made those fixes, they’ll already be in place for each new website you spin up.

Test early and often to reduce the need to go back and redo work. This saves money and time – all of our two favorite things.

Have questions about accessibility testing? Post them in the Facebook comments, and I’d happily answer them.