Guide · Agent skill
How to use the accessibility-testing agent skill
Updated · written with AI from the project's own documentation and checked against our catalogue data
The accessibility-testing skill is a set of instructions that teaches an AI coding agent how to review your component libraries, page flows and CI pipelines for automated accessibility checks. It is aimed at front-end developers and teams who want accessibility checks in their test suites before doing manual audits. After this guide you will know how to install the skill, how to ask the agent for help with it, and what it cannot replace.
Accessibility Testing Guidethedaviddias/Front-End-Checklist · MIT Download the skill Quick start
- 1Download the ZIP. Get the accessibility-testing ZIP from the skill page on this site.
- 2Unzip into a skills folder. Unzip it into ~/.claude/skills/ for personal use, or into the project's .claude/skills/ folder for one project.
- 3Or upload it in the Claude apps. Go to Settings, then Capabilities, then Skills, and upload the ZIP.
- 4Confirm your test tools. Check that the project uses jest-axe, @axe-core/playwright or cypress-axe, and that the agent can read your test suite and CI configuration.
- 5Ask for a review. Describe the component library, page flow or CI pipeline you want checked in plain language.
- 6Add the flagged checks. Have the agent write the suggested axe tests, run your test suite, and fix any failures it reports.
- 7Plan manual testing. Schedule keyboard, screen reader and manual UX testing for the issues the skill says automation cannot cover.
What the accessibility-testing skill makes the agent do
Once installed, the agent can review component libraries, page flows and CI pipelines for automated accessibility checks, such as jest-axe or @axe-core/playwright tests. It explains how to add these checks, and it flags critical pages or shared components that ship without them.
The skill is also clear about limits. Automated testing is strongest at catching structural and attribute-level issues. It does not replace keyboard, screen reader and manual UX testing, and the agent will point out where those are still needed.
- Reviews component tests, E2E suites and CI workflows for axe-based coverage
- Explains how to implement automated accessibility checks
- Flags critical pages or shared components without checks
- Notes issues that still need manual keyboard or screen reader validation
Install the accessibility-testing skill
You can install the skill in one of two ways. Download the ZIP from the skill page on this site, then either unzip it into your personal skills folder or into a project-level skills folder. Alternatively, upload the ZIP in the Claude apps.
For a personal install, unzip it into ~/.claude/skills/. For a single project, unzip it into the project's .claude/skills/ folder. To use the Claude apps instead, go to Settings, then Capabilities, then Skills, and upload the ZIP there.
- Personal install: ~/.claude/skills/
- Project install: the project's .claude/skills/ folder
- Claude apps: Settings → Capabilities → Skills, then upload the ZIP
Check that your project meets the requirements
The skill expects you to use one of three libraries depending on your project: jest-axe for component tests, @axe-core/playwright for end-to-end tests, or cypress-axe if you use Cypress. The skill also needs access to your project's test suite and CI configuration, because its reviews are based on those files.
The skill does not run scripts and does not use the network, according to its own documentation. It is a set of instructions for the agent, not a tool that changes your system.
- jest-axe, @axe-core/playwright or cypress-axe, depending on the project
- Access to the project's test suite and CI configuration
- A JavaScript test setup, since the examples focus on jest-axe, Playwright and Cypress
Trigger the skill with natural requests
You do not need a special command. Describe what you want in plain language and the agent will use the skill when the request matches its purpose, which is reviewing component libraries, page flows or CI pipelines for repeatable accessibility checks.
Name the part of the project you want reviewed. Asking about a specific component, page or workflow file usually gets a more useful answer than asking about the whole codebase at once.
- Review our component library and tell me which components have no accessibility tests.
- Check whether our Playwright end-to-end tests cover the checkout flow for accessibility.
- Look at our CI workflow and suggest where to run axe checks so regressions get caught early.
- Add a jest-axe test to the Button component and explain what it checks.
expect.extend(toHaveNoViolations); const results = await axe(container); expect(results).toHaveNoViolations();Test specific WCAG rules
The skill's reference material shows that you can enable a single axe rule, such as color-contrast, inside a jest-axe test. This is useful when you want a focused check on one issue rather than the full rule set.
Ask the agent to add a targeted rule check when a specific problem matters for your project, for example contrast on warning messages.
- Use targeted rule checks for known problem areas such as color contrast
- Keep broad axe checks on shared components so they run everywhere they are used
const results = await axe(container, { rules: { 'color-contrast': { enabled: true } } }); expect(results).toHaveNoViolations();Know what automated checks will not catch
The skill states that automated testing catches a share of WCAG violations, not all of them, and that it does not replace keyboard, screen reader or manual UX testing. Treat axe-based tests as an early warning layer that stops regressions and obvious structural problems from reaching users.
Use the agent's output as a list of gaps to fill. Anything it flags as needing manual validation should go to a person who tests with a keyboard and a screen reader.
- Good for: structural and attribute-level issues, repeatable checks in CI
- Not enough for: full compliance audits, keyboard-only flows, screen reader behaviour, manual UX review
What people use it for
- Adding jest-axe tests to a shared component library so each component is checked for violations
- Reviewing Playwright or Cypress end-to-end tests to see whether key user journeys include axe checks
- Adding an accessibility step to a CI pipeline so regressions are caught before merge
- Getting a starting list of pages and components to cover before a manual accessibility audit
Frequently asked questions
How do I install the accessibility-testing agent skill?
Download the ZIP from the skill page on this site. Unzip it into ~/.claude/skills/ for personal use or into the project's .claude/skills/ folder for one project. You can also upload the ZIP in the Claude apps under Settings, then Capabilities, then Skills.
What do I need to use the accessibility-testing skill?
You need jest-axe, @axe-core/playwright or cypress-axe, depending on your project, and access to your test suite and CI configuration. The skill is focused on JavaScript test setups.
Is the accessibility-testing skill free and what is its licence?
The source for this skill is published under the MIT licence. Check the licence file in the repository for the full terms.
Does this skill replace an accessibility audit?
No. The skill states that automated tests miss many issues and do not replace keyboard, screen reader or manual UX testing. It is a starting point for repeatable automated checks, not a full compliance audit.
Does the skill run scripts or use the internet?
According to its documentation, the skill does not run scripts and does not use the network. It provides instructions for the agent.
Which test tools does the skill support?
Its examples focus on jest-axe for component tests, @axe-core/playwright for Playwright end-to-end tests and cypress-axe for Cypress. Teams not using JavaScript test frameworks will get less from it.
New agent skills, repos and AI tools — every week
The best new skills and open-source projects, the fastest-growing repos, and one free prompt. Five minutes to read. Unsubscribe anytime.
Our verdict
Use this skill if your front-end team wants axe-based accessibility checks in component tests, E2E tests and CI, and needs a clear starting point. Pick something else, or add a dedicated audit, if you need full compliance testing or your project does not use a JavaScript test framework. Either way, keep manual keyboard and screen reader testing in your process.
Download the skill