Learn Accessibility Testing Basics

Learning Objectives

After completing this unit, you’ll be able to:

Recognize the importance of testing for accessibility.
Summarize the pros and cons of automating accessibility testing.
Identify tools you can use for automating accessibility testing.
Describe strategies for writing your own automated accessibility tests.

Why Do We Test for Accessibility?

Accessibility testing helps ensure that digital products—such as websites and apps—are usable by everyone, including those with disabilities. That means finding and removing accessibility barriers before users even encounter them. Ideally, there are never any accessibility bugs to begin with, but the reality is that bugs do occur during development. Whenever you’re developing something, your goal is to ensure that none of these bugs reach your users.

In an ideal world, accessibility testing takes place throughout the entire development lifecycle, starting with the design phase, continuing through development, and even after deployment. With this proactive approach, you ensure that you’re considering and integrating accessibility at every step.

By conducting accessibility testing, you help:

Create an inclusive digital experience that provides equal access.
Meet regulatory and legal requirements.
Reach a wider range of users.
Improve the overall user experience.

In this module, we cover automated and manual testing, both of which are vitally important to providing comprehensive accessibility testing. Let’s start by looking at automated accessibility testing.

The Pros and Cons of Automating Accessibility Tests

As you probably already know, automated accessibility testing allows you to quickly evaluate whether your digital product meets accessibility standards. For example, automated-testing software can scan a website and identify a range of accessibility barriers, from missing alt text to insufficient color contrast to missing headings. Automating the testing process boosts efficiency, improves consistency, and allows for greater scalability.

A developer conducting automated accessibility testing.

While automated testing has lots of benefits, it’s important to remember that it can miss significant accessibility issues as well as more subtle accessibility barriers that require human understanding and context. For example, an automated test will not necessarily flag images of text that are used as headings. And it can’t assess the real-world impact of accessibility barriers on users. For the most comprehensive assessment of accessibility, always conduct manual accessibility testing in conjunction with automated tests.

When automating your own accessibility tests, use a mix of prebuilt test utilities and customer test cases to catch accessibility regressions in your user interfaces. The mobile test frameworks for iOS and Android include basic accessibility checks. If you develop features using native code, add tests to perform basic checks supported by the test frameworks. For more information about mobile testing, check out the Resources at the end of this unit.

Use Accessibility-Testing Tools

There are a number of automated and semiautomated tools you can use to conduct accessibility testing. Most of them compare content against Web Content Accessibility Guidelines (WCAG) and identify accessibility barriers. Here’s a breakdown of a few helpful tools.

Tool	What It Is	What It Does
Axe	An open-source testing tool for websites and other HTML-based user interfaces that provides comprehensive accessibility testing	Allows you to catch accessibility errors while coding and integrates with your existing test environment so you can automate accessibility testing
WAVE	A free suite of evaluation tools that helps you identify common accessibility barriers—such as low contrast and missing alt text—that impact users with disabilities	Uses icons and indicators to highlight many accessibility issues and facilitates human evaluation of web content
Google Lighthouse	An open-source automated tool that audits for accessibility issues, including WCAG violations	Conducts accessibility audits and assigns a score out of 100, which reflects a page’s accessibility level
Linters	Automated tools—such as GitHub: infofarmer / eslint-plugin-jsx-a11y and GitHub: reactjs / react-a11y—that can be integrated into the development lifecycle from the start to prevent accessibility issues and violations	Analyzes source code such as HTML, CSS, and JavaScript for accessibility barriers such keyboard navigation issues and improper use of headings and landmarks
sa11y	A set of Salesforce-created, open-source JavaScript libraries that help you write automated accessibility tests	Enables you to detect machine-knowable static DOM accessibility issues

Note that the tests conducted with these tools aren’t all-encompassing. Even if your code passes every test, it’s not a guarantee that your product is fully accessible. However, these tests do surface major accessibility issues, and putting them in place helps ensure that a regression won’t make your code inaccessible. It’s recommended that you always conduct manual testing in addition to automated testing to ensure a comprehensive assessment of accessibility. Learn more about manual testing later.

Write Your Own Accessibility Tests

If you’ve done a lot of work to make a component accessible, you want to make sure it stays that way. You can write automated tests for a variety of accessibility concerns, including expected keyboard functionality and correct ARIA values for HTML elements.

Example: Testing a Lightning Button

Here’s some pseudo code for a Lightning Web Components (LWC) Jest test that creates a Lightning Button and validates that the structure of the component is accessible.

registerSa11yMatcher();
const element = createButton({
    label: 'Submit',
    variant: 'brand-outline',
    title: 'This is a submit button',
});
const button = shadowQuerySelector(element, 'button');


return Promise.resolve().then(async () => {
    await expect(button).toBeAccessible();
});

In this example code, first you register sa11y to be able to check components for accessibility. Then you create the button with a label, a particular variant, and a title. Then find this button and assign it to a variable. Finally, to introduce accessibility checks, you use an async function call to check the button for accessibility.

When checking for something to be accessible in Jest, take the HTML structure of the checked element and validate it against WCAG standards. This includes ensuring all aria attributes are correct for the element that is being rendered.

Those are a few accessibility-testing basics. Ready to put these principles into practice? Keep reading to learn how to conduct keyboard and screen-reader testing.

Estimación de tiempo

Temas

¿Necesita ayuda?

Recursos de Salesforce Platform