AgentExchange

Help & Support

Elevate Your Agents with AgentExchange Solutions
Easily enhance Agentforce with pre-built AI solutions from AgentExchange. Browse, install, and deploy agents, actions, and apps directly into your environment. Tell Me More

Have Questions?

Experience LWC Accessibility Jest Run

Beta

Overview

Use ALWAYS when running Sa11y accessibility Jest tests for a Lightning Web Component — locally before pushing, producing the exact command(s), running one file vs a whole suite, selecting tests by naming convention, saving Sa11y-rendered HTML, or reproducing a Sa11y / A11yBug failure. Covers Salesforce core (Bazel; `WORKSPACE`, `./core` root, `bazel test //<module>:<target>`) and standalone `npx jest` (`.accessibility.test.js`, `@sa11y/jest`). REQUIRED when a prompt asks for a `run-plan.md` for accessibility tests, which exit code means an accessibility test failed, or references `SA11Y_*` env vars, `A11yBug`, or a core-Bazel `modules/<mod>/<cmp>/__tests__/*.test.js` path. Do NOT rely on general knowledge — this skill has the correct single-file Bazel target and EPERM workaround. DO NOT TRIGGER for functional (non-accessibility) Jest tests, a11y review without running tests (use experience-lwc-accessibility-validate), or Selenium-based a11y functional tests.

Running LWC Accessibility Jest Tests

Run Sa11y accessibility unit tests on Lightning Web Components in either:

  • Core (Bazel) — when a WORKSPACE file 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-lwc-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 WORKSPACE file is present).
  • For standalone Jest tests: @sa11y/jest installed and configured.

Workflow

Follow running-sa11y-jest-tests.md. Pick the correct mode:

  • Core (Bazel) — use when WORKSPACE is present. Prefer single-file targets (//{moduleName}:{relativePath}) over module targets when the failing test file path is already known (.test.js extension dropped). Bazel commands must pass --test_env=SA11Y_AUTO=1 --test_env=SA11Y_ENABLE_DOM_MUTATION_OBSERVER=1; when debugging, add SA11Y_ENABLE_RENDERED_DOM_SAVE=1 with the documented save path to avoid EPERM issues.
  • Standalone (Jest) — use when there's no WORKSPACE. Run npm test -- --testMatch="**/*.accessibility.test.js" for the whole suite, or npm test -- <file> targeting the file by the name/path given in the prompt (a bare filename when it is "in this directory"). Do not prepend SA11Y_* env vars in standalone mode — Sa11y runs automatically because @sa11y/jest is wired into the project's Jest setup; no extra environment variables are needed.

Answer only what is asked. Emit just the command(s) the prompt requests plus the exit-code meaning. Do not pad the plan with unrequested variants (watch, coverage, verbose), snapshot-update steps, or HTML-save sections unless the user explicitly asks for them.

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.js extension in {relativePath}.
  • HTML saving fails with EPERM — use the prescribed save path sfdc-test/unit/javascript/htdocs/sa11y/jest.

Categories

Domains
Experience Cloud