/experience-lwc-accessibility-jest-run

name: experience-lwc-accessibility-jest-run
description: "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."
metadata:
  version: "1.0"
  domains: ["Experience"]
  cliTools:
    - tool: ["npm"]
      semver: ">=8.0"

<!-- adk-managed-skill -->

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](references/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`.