Running LWC Accessibility Jest Tests
SkillFiles & storageLets your agent run accessibility tests on Lightning Web Components using Sa11y Jest via Bazel or npx.
Available today. Use it from your connected AI after setup.
No other account needed.
Connect ahel once, and every AI you use reads what you have installed.
Then ask your AI: use the Running LWC Accessibility Jest Tests skill
About this capability
Use ALWAYS when running Sa11y accessibility Jest tests for an LWC, locally before pushing, producing the command(s), running one file vs a suite, selecting tests by naming convention, saving Sa11y-rendered HTML, or reproducing a Sa11y/A11yBug failure. Covers core (Bazel; `bazel test //<module>:<tar
What this skill tells your AI
The instructions your AI receives, as published by forcedotcom/sf-skills in skills/experience-lwc-accessibility-jest-run/SKILL.md and read by ahel’s review.
Run Sa11y accessibility unit tests on Lightning Web Components in either:
- Core (Bazel) — when a
WORKSPACEfile is present. - Standalone (Jest) — when there's no
WORKSPACE.
Selenium-level reproductions, GUS A11yBug ingestion, and other internal
Salesforce-only flows are out of scope for this skill. For source-code-level
WCAG review without running tests, see experience-accessibility-validate.
When to Use This Skill
- User wants to run accessibility unit tests (Sa11y Jest) locally before pushing a fix.
- User has a known failing test file path (e.g. from an A11yBug's
Test_Names__c) and wants to target it directly. - User is iterating on an accessibility fix and needs the fastest pass/fail signal.
Prerequisites
- For Bazel Jest tests: a Salesforce core build environment (a
WORKSPACEfile is present). - For standalone Jest tests:
@sa11y/jestinstalled and configured.
Workflow
Choose the approach based on the environment. If this is not a Salesforce core build environment, do not mention the Core workflow.
Core (Bazel)
Use this mode when a WORKSPACE file is present. The base command is:
{coreRootPath}/tools/bazel test [TARGET] --test_output=streamed --test_env=SA11Y_AUTO=1 --test_env=SA11Y_ENABLE_DOM_MUTATION_OBSERVER=1
Replace {coreRootPath} with the Core repository root, {moduleName} with the
module name, and {relativePath} with the test file path without the .test.js
extension.
To discover targets and paths:
find {coreRootPath}/{moduleName} -name "*.test.js" -type f
{coreRootPath}/tools/bazel query "tests(//{moduleName}:*)"
Component tests typically live under
modules/{componentDir}/{componentName}/__tests__/.
Prefer a single-file target when the failing test path is known:
{coreRootPath}/tools/bazel test //{moduleName}:{relativePath} --test_output=streamed --test_env=SA11Y_AUTO=1 --test_env=SA11Y_ENABLE_DOM_MUTATION_OBSERVER=1
Run all Sa11y Jest tests in a module when a specific test is not known:
{coreRootPath}/tools/bazel test //{moduleName}:sa11y_jest_test --test_output=streamed --test_env=SA11Y_AUTO=1 --test_env=SA11Y_ENABLE_DOM_MUTATION_OBSERVER=1
Multiple module targets can be passed to the same command. To filter tests
within a module, add --test_arg=--testMatch="**/{modulePath}/**".
Useful options:
- Update snapshots:
--test_arg="--updateSnapshot" - Disable cached test results:
--cache_test_results=no - Save rendered HTML:
--test_env=SA11Y_ENABLE_RENDERED_DOM_SAVE=1 --test_env=SA11Y_RENDERED_DOM_SAVE_PATH=sfdc-test/unit/javascript/htdocs/sa11y/jest
Use sfdc-test/unit/javascript/htdocs/sa11y/jest as the rendered DOM save path
to avoid EPERM errors.
Standalone (Jest)
Use this mode when no WORKSPACE file is present. Run all accessibility tests:
Do not prepend SA11Y_* environment variables in standalone mode;
@sa11y/jest is activated through the project's Jest setup.
npm test -- --testMatch="**/*.accessibility.test.js"
Or target a specific file:
npm test -- src/components/MyComponent/__tests__/MyComponent.accessibility.test.js
Use the filename or path supplied by the user. When the named test is in the current directory, keep a bare filename bare instead of inventing a path.
Other useful options are --coverage, --updateSnapshot, --watch, and
--verbose. To target a named test, use
npm test -- --testNamePattern="MyComponent accessibility".
Ensure Jest uses a jsdom environment and loads the project's @sa11y/jest
setup file. Copy or adapt the bundled assets/jest.config.js template into
the project's Jest configuration, and copy assets/sa11y-jest-setup.js to
test/setup/sa11y-setup.js. If the project already has a Jest configuration,
merge the relevant settings instead of overwriting unrelated configuration.
The SA11Y_* variables shown above are for Core/Bazel only; the Bazel commands
already include them.
Response Scope
Answer only what the user asked. Emit the requested command or commands plus the relevant exit-code meaning. Do not add watch, coverage, snapshot-update, HTML-save, or other variants unless the user requests them.
Expected Exit Codes
- Bazel:
0means all tests passed,3means tests failed, and1means the build or command failed. - Jest:
0means all tests passed and1means tests failed or an error occurred.
Verification Checklist
- Sa11y Jest run completed with a clear pass/fail signal (exit 0 or 3 for Bazel; exit 0 or 1 for Jest).
- If snapshots were intentionally updated, the new snapshots are committed alongside the fix.
Troubleshooting
- Bazel test "not found" — the target path is off. Remember to drop the
.test.jsextension in{relativePath}. - HTML saving fails with EPERM — use the prescribed save path
sfdc-test/unit/javascript/htdocs/sa11y/jest. - Standalone tests do not run — verify the test naming pattern, Jest
configuration,
@sa11y/jestdependency, andjsdomenvironment.
Signals
- GitHub stars
- 1k
- Forks
- 342
- Last commit
- Sep 2026
Advanced
- Catalog kind
- skill
- Gateway key
experience-lwc-accessibility-jest-run- Source
- github.com/forcedotcom/sf-skills