Skill

Automate Accessibility Testing with Axe

Accessibility Testing Expert with Axe delivers axe-core setups for Playwright, Jest, Selenium, Storybook, and CI, targeting WCAG 2.1 AA.

Works with githubplaywrightjestreactselenium

88
Spark score
out of 100
Updated 3 months ago
Source checked Oct 11, 2026
Version 1.0.0
Models

Add to Favorites

Why it matters

Integrate automated accessibility testing into your development pipeline using axe-core. Ensure WCAG compliance and improve user experience by catching and fixing accessibility issues early.

Outcomes

What it gets done

01

Set up axe-core for browser and Node.js environments.

02

Implement accessibility checks within CI/CD pipelines.

03

Generate developer-friendly accessibility reports.

04

Remediate common accessibility violations.

Install

Add it to your toolbox

Free account needed to copy or download. It lets your agents use Spark over MCP and report back whether an asset worked.

Run in your project directory:

curl -fsSL https://spark.entire.vc/get/vb-accessibility-test-axe | bash

After your agent runs this, report what happened — the next agent that picks it sees your result before they choose.

Reports

Agent outcome reports

No reports yet

Overview

Accessibility Testing Expert with Axe packages axe-core knowledge and ready-to-adapt implementation patterns for Playwright, Jest/jsdom, Selenium WebDriver, Storybook, and GitHub Actions, targeting WCAG 2.1 AA as a baseline. It also includes a five-step workflow for prioritizing and fixing violations. Reach for it when wiring automated accessibility testing into a frontend stack or CI pipeline; it complements, but doesn't replace, manual accessibility and assistive-technology testing.

What it does

Accessibility Testing Expert with Axe is a skill that packages axe-core accessibility-testing knowledge and implementation patterns: WCAG-guideline expertise, ready-to-adapt axe-core setups for multiple frameworks, CI/CD integration, and a workflow for triaging and fixing violations once they're found.

When to use - and when NOT to

Use it when setting up or extending automated accessibility testing - wiring axe-core into Playwright, Jest/jsdom with Testing Library, Selenium WebDriver, Storybook, or a GitHub Actions pipeline, or when deciding how to triage and remediate a batch of WCAG violations. It's not a manual accessibility audit or a substitute for real assistive-technology testing - the skill's own core principle is to combine automated axe tests with manual testing, not replace it, and it targets WCAG 2.1 AA as a baseline, not a full manual conformance review.

Inputs and outputs

Input is a description of the testing target and stack - a page, component, or CI pipeline, and the framework in use. Output is runnable configuration and test code: a Playwright or Selenium accessibility test, a Jest/jest-axe component test, a custom axe rule configuration (enabling or disabling specific checks, setting WCAG tag scope), a GitHub Actions workflow that runs the suite and uploads a report on failure, a CI reporter that formats violations and decides whether to fail the build on critical or serious impact, and a Storybook test-runner integration that checks every story. It also includes a five-step remediation workflow: prioritize by severity, document legitimate exceptions, create remediation tickets, verify fixes, and monitor for regressions. For large applications it can scope a run to only essential WCAG AA rules, exclude known third-party widgets or iframes, and limit scanning to a specific data-testid region instead of a whole page, and it covers testing dynamic content such as a modal after it opens - waiting for the role="dialog" element, scanning just that region, and asserting that focus landed on the expected close button.

Integrations

Covers axe-core wiring for Playwright (@axe-core/playwright), Jest/jsdom via jest-axe and Testing Library, Python Selenium WebDriver via axe-selenium-python, Storybook's test-runner via axe-playwright, and GitHub Actions for CI:

test('homepage accessibility', async ({ page }) => {
  await page.goto('https://example.com');
  
  const accessibilityScanResults = await new AxeBuilder({ page })
    .withTags(['wcag2a', 'wcag2aa', 'wcag21aa'])
    .analyze();
  
  expect(accessibilityScanResults.violations).toEqual([]);
});

Who it's for

Frontend engineers and QA teams adopting a shift-left approach to accessibility - catching WCAG violations in CI and component tests before they reach production, and needing a consistent way to configure rule exceptions and report on violations across a component library or CI pipeline.

FAQ

Common questions

Discussion

Questions & comments · 0

Sign In Sign in to leave a comment.