Salesforce is committed to delivering a high-quality user experience and making a positive impact for our customers by allowing customers to focus on strategic tasks while improving overall efficiency and user satisfaction. A key part of this is ensuring that our products are accessible to all, including people with disabilities. To meet the growing need for universal design, we must be proactive, not reactive — and integrate accessibility from the beginning. Shifting left in our development process ensures accessibility with minimal extra effort.
In this blog post, we’ll walk you through how to automate accessibility testing using sa11y, a set of open source libraries created by Salesforce. We’ll also share how we use the tool internally.
Product accessibility at Salesforce
In a broad sense, accessibility allows people with a variety of disabilities to use products and services independently. In practice, that means designing with the community in mind.
Salesforce products strive to conform with WCAG 2.1 AA, a globally recognized standard for accessible technology with detailed guidelines and techniques. This ensures that our products align with numerous federal, state, and international accessibility requirements.
Assessing whether a Salesforce application meets these practices can feel daunting, but there are tools available to help automate the testing of key requirements. And that’s where sa11y comes in!
Streamlining accessibility: Automated testing with sa11y
sa11y is Salesforce’s automation framework for product accessibility testing. The name is a combination of “Salesforce” and “Accessibility.” Accessibility is often abbreviated as “A11y” (pronounced A-eleven-y or ally), similar to the abbreviations i18n and l10n.
At its core, sa11y is a suite of JavaScript libraries created by Salesforce, built on the open-source, axe-core accessibility testing framework. However, they are not specific to Salesforce and can be used to test any UI supported by axe-core for accessibility. These libraries are designed to be flexible, customizable, and reusable to support automated accessibility testing in different testing workflows, from unit to integration tests.
sa11y was built to help engineers easily identify accessibility issues and catch many common and critical ones at an early stage. With a rule set of over 80 criteria, sa11y helps teams validate code against WCAG 2.2 standards, helping them integrate accessibility testing into their workflow. By automating tests early in the development process, sa11y allows teams to catch a large number of accessibility issues before they’re shipped.
Since sa11y automatically runs accessibility checks, there is no additional overhead on Salesforce developers. sa11y saves time and enables engineering teams to address accessibility issues before they are pushed to production.
sa11y is also available to the wider developer community as an open source tool.
How sa11y fits into the process at Salesforce
sa11y is widely used internally at Salesforce. For example, we’re using the tool to test updates to Agentforce, enhancing the reliability of Salesforce’s platform for proactive, agentic AI. For all code in the main codebase that uses Jest tests, accessibility checks run automatically with sa11y/Jest.
At Salesforce, sa11y runs daily in our Jest and Selenium automated Lightning build and test frameworks, and it can automatically log defects in Salesforce’s internal defect tracking system. While automated testing does not capture all accessibility issues, sa11y serves as an invaluable assistive tool in the pursuit of accessibility excellence. While automated testing is the best place to start, manual testing is still a critical step to ensure that the components and products being built are accessible.
How sa11y meets developer needs
sa11y makes accessibility easier for developers in a number of ways, including:
Accuracy and reliability
- Reduces false positives and false negatives to ensure developers trust the results
- Detects critical accessibility issues with precision, minimizing unnecessary noise and helping developers prioritize real accessibility barriers
- Provides clear explanations and actionable fixes for developers that can be directly applied within existing development processes, reducing friction in accessibility remediation
Seamless integration
- Integrates into build and test pipelines across various DevOps tools like GitHub, ensuring a hassle-free execution and with no third-party setup requirement
- Integrates with defect tracking systems, reducing manual effort and ensuring that accessibility issues are addressed earlier in the development cycle
Developer ease of use
- Provides detailed documentation to help new users quickly understand and implement accessibility testing without extensive training
- Provides easy setup and a dedicated Slack support channel to help teams get started without delays
Get started with Sa11y/Jest for automated accessibility testing
In the Jest framework, sa11y offers a custom matcher toBeAccessible() via the @sa11y/jest package, which is compatible with Lightning Web Components (LWC) and other Jest-based unit tests. sa11y can run automatic checks with minimal configuration. By registering sa11y auto-runners at the framework level, accessibility checks run automatically across all tests without the need for explicit API calls.
Onboarding to sa11y/Jest
Follow these easy steps below to onboard to Sa11y/Jest. For additional information and instructions see the Sa11y ReadMe file on GitHub.
Install the @sa11y/jest package:
- Using yarn:
- Using npm:
Create and add a Jest setup file:
- Create a setup file (e.g., sa11y-jest-setup.js) and add the following code:
Modify Jest configuration:
- Update your jest.config.js to include the setup file:
- If using pre-existing Jest configurations (e.g., for LWC):
Note: It is recommended to onboard to Renovate for automating package update PRs, ensuring that sa11y and other dependencies stay current.
For additional and more specific information, see the sa11y ReadMe file on GitHub.
Driving success with teamwork
Through frequent developer feedback and continuous improvements to sa11y, we’ve been able to enhance automated accessibility testing, which not only fosters inclusive design, but also reduces remediation costs and compliance risks, benefiting both users and the business.
By integrating sa11y more deeply into our development workflows and leveraging developer insights, we are refining automated accessibility testing, making it a seamless part of the software development lifecycle (SDLC) and improving accessibility outcomes from the start.
Learn more about sa11y
In this post, we’ve covered just a few aspects of how to help ship accessible products. To learn more, you can begin by taking the Get Started with Web Accessibility trail on Trailhead. Then, check the accessibility section in the Lightning Design System guide, which contains accessibility guidance for our interactive components.
About the author
Megan Alfaro is a Senior Product Manager at Salesforce focusing on accessibility. Learn more about Megan Alfaro on LinkedIn.