How to Use the Accessibility Agent Skill to Run WCAG Tests

What Is the Accessibility Agent Skill?

An agent skill is a folder of instructions, code patterns, and a reference doc that an AI coding agent reads before it writes anything. Instead of the agent inferring a capability name from a stale blog post or hallucinating an API, it reads the skill's SKILL.md and follows verified patterns. The agent-skills repository packages one such skill per framework and testing discipline; accessibility-skill is the one for WCAG scanning.

The skill's core claim is specific: accessibility testing is layered onto automation you already have. You are not installing axe-core yourself or wiring up a separate scanner. You turn on a capability on your existing Selenium, Playwright, or Cypress driver, and TestMu AI's cloud grid does the scanning during the run.

Prerequisites

• Node.js and npm, to run the skill installer.
• An AI coding agent - Claude Code, GitHub Copilot, Cursor, or Gemini CLI all read the same skill format.
• A TestMu AI account with a username and access key from your Profile page.
• An existing Selenium, Playwright, or Cypress suite already running on TestMu AI's cloud grid. The skill adds scanning to automation you have, it does not generate a new suite from nothing.
• Chrome or Edge version 90 or higher if you plan to use Playwright, since the scan runs through an internal Chrome extension and does not work on Chromium.

Installing the Skill

Clone the repository and install just the accessibility skill with the official installer, rather than copying the folder by hand:

git clone https://github.com/LambdaTest/agent-skills && cd agent-skills
npx agentskillsforall add https://github.com/LambdaTest/agent-skills.git --skill accessibility-skill

Set your TestMu AI credentials as environment variables so the agent can authenticate against the cloud grid:

export LT_USERNAME="YOUR_USERNAME"
export LT_ACCESS_KEY="YOUR_ACCESS_KEY"

Run npx agentskillsforall list https://github.com/LambdaTest/agent-skills.git to confirm the skill is installed alongside any framework skills, such as Selenium Skill, you already have.

Enabling Scans by Framework

Every framework shares one master switch, the accessibility capability, plus optional refinements for WCAG version, best-practice checks, and ambiguous issues that need human review. How the scan actually fires differs by framework, and this is exactly the kind of detail the skill exists to get right on the first try instead of the third.

ChromeOptions options = new ChromeOptions();
options.setCapability("browserName", "Chrome");

Map<String, Object> ltOptions = new HashMap<>();
ltOptions.put("user", System.getenv("LT_USERNAME"));
ltOptions.put("accessKey", System.getenv("LT_ACCESS_KEY"));
ltOptions.put("build", "Accessibility Build");
options.setCapability("LT:Options", ltOptions);

// Master switch, required
options.setCapability("accessibility", true);
options.setCapability("accessibility.wcagVersion", "wcag21aa");
options.setCapability("accessibility.needsReview", true);

WebDriver driver = new RemoteWebDriver(new URL("https://hub.lambdatest.com/wd/hub"), options);

driver.get("https://www.testmuai.com/selenium-playground/");
driver.executeScript("lambda-accessibility-scan"); // scans the current page

const capabilities = {
  browserName: 'Chrome',
  browserVersion: 'latest',
  'LT:Options': {
    user: process.env.LT_USERNAME,
    accessKey: process.env.LT_ACCESS_KEY,
    build: 'Playwright Accessibility',
  },
  accessibility: true,
  'accessibility.wcagVersion': 'wcag21a',
  'accessibility.needsReview': true,
};

// After page creation, load the report-generating extension:
await ltPage.goto("chrome://extensions/?id=johgkfjmgfeapgnbkmfkfkaholjbcnah");
await ltPage.locator('#crToggle').nth(0).click();

{
  "accessibility": true,
  "accessibility.wcagVersion": "wcag21aa",
  "accessibility.needsReview": true
}

Running Your First Scan

Once the capability is on, ask your agent something concrete instead of something abstract. A prompt like this gives the agent enough to act on:

"Add the accessibility capability to my Selenium suite, scan the checkout page and the login page with WCAG 2.1 AA, and run it."

Run the suite with your normal command - mvn test, npx playwright test, or lambdatest-cypress-cli run. Then open your TestMu AI dashboard and go to the Accessibility tab under Automation. Every scan you triggered appears there as a build with a report, regardless of which framework produced it.

Reading the Score and Severity

Each scan produces a score from 0 to 100. It is not a pass or fail flag; it is 100 - (density x weighted severity), where density is the ratio of issues to elements on the page and weighted severity blends the proportion of Critical (weight 1.0), Serious (0.75), Moderate (0.5), and Minor (0.25) issues found.

Two issues that push a page below 70 come up constantly: missing or non-descriptive alt text (WCAG 1.1.1, Critical) and insufficient color contrast (WCAG 1.4.3, Serious, which needs at least a 4.5:1 ratio for normal text). Both are fast to fix once the scan tells you exactly which element failed.

What Automation Does Not Catch

The accessibility skill's own reference playbook is direct about this: automated detection covers roughly a third to a half of WCAG success criteria. A clean scan is not a compliance certificate.

What scans catch reliably: presence of alt attributes, color contrast on solid backgrounds, form labels, heading structure, and name/role/value markup. What still needs a person with a keyboard and a screen reader: whether alt text is actually meaningful, keyboard operability and focus order, use of color as the only signal, and how status messages announce to assistive technology. Treating "0 issues" as "accessible" is the single most common mistake teams make with this skill.

Reading Results Programmatically

The Selenium, Playwright, and Cypress capability paths all write to the dashboard only. There is no results API, no exit code, and nothing to gate a CI build on directly from automation. If your agent needs to read a report back and act on it, for example to decide whether a newly built page is safe to deploy, the Accessibility MCP server is the path that returns data instead of just a dashboard entry.

• getAccessibilityReport - scans a public URL and returns the report directly to the calling agent.
• buildLocalAppForAnalysis - builds and serves a local app, then scans it before it is ever deployed.
• AnalyseAppViaTunnel - scans a local app already running behind a TestMu AI tunnel.

This is the closest thing to "scan after every build and act on the result" that the platform offers today, and it is worth reaching for whenever the requirement is programmatic, not just visible on a dashboard.

Anti-Patterns to Avoid

• Setting accessibility: true but never calling the scan hook - Selenium generates nothing without either the hook or autoscan turned on.
• Expecting autoscan on Playwright or Cypress - it is Selenium only and is silently ignored elsewhere.
• Running Playwright accessibility tests on Chromium - the scan extension requires Chrome specifically.
• Registering the Cypress scanner in the wrong file for your version - v10+ and v9 use different support and plugin files.
• Assuming HyperExecute accessibility scanning works without setup - it is a gated feature that TestMu AI support has to enable on your account first.

Conclusion

Install the skill, turn on the accessibility capability in the suite you already run, and scan one page you suspect is broken before you scan everything. The dashboard report and severity score will tell you exactly where to start fixing, and the reference playbook tells you honestly where automation stops and a person with a screen reader needs to take over.

For the full capability reference, WCAG-to-fix mapping, and mobile notes, see the accessibility-skill playbook on GitHub, or read the Accessibility Testing documentation to set up scheduled and mobile scanning alongside this automation path.