accessibility-testing
Test web applications for WCAG compliance and ensure usability for users with disabilities. Use for accessibility test, a11y, axe, ARIA, keyboard navigation, screen reader compatibility, and WCAG validation.
Install
npx skills add https://github.com/aj-geddes/useful-ai-prompts --skill accessibility-testingSKILL.md
Accessibility Testing
Table of Contents
Overview
Accessibility testing ensures web applications are usable by people with disabilities, including those using screen readers, keyboard navigation, or other assistive technologies. It validates compliance with WCAG (Web Content Accessibility Guidelines) and identifies barriers to accessibility.
When to Use
- Validating WCAG 2.1/2.2 compliance
- Testing keyboard navigation
- Verifying screen reader compatibility
- Testing color contrast ratios
- Validating ARIA attributes
- Testing form accessibility
- Ensuring focus management
- Testing with assistive technologies
Quick Start
Minimal working example:
// tests/accessibility/homepage.a11y.test.ts
import { test, expect } from "@playwright/test";
import AxeBuilder from "@axe-core/playwright";
test.describe("Homepage Accessibility", () => {
test("should not have any automatically detectable WCAG A or AA violations", async ({
page,
}) => {
await page.goto("/");
const accessibilityScanResults = await new AxeBuilder({ page })
.withTags(["wcag2a", "wcag2aa", "wcag21a", "wcag21aa"])
.analyze();
expect(accessibilityScanResults.violations).toEqual([]);
});
test("navigation should be accessible", async ({ page }) => {
await page.goto("/");
const results = await new AxeBuilder({ page }).include("nav").analyze();
expect(results.violations).toEqual([]);
});
// ... (see reference guides for full implementation)
Reference Guides
Detailed implementations in the references/ directory:
| Guide | Contents |
|---|---|
| axe-core with Playwright | axe-core with Playwright |
| Keyboard Navigation Testing | Keyboard Navigation Testing |
| ARIA Testing | ARIA Testing |
| Jest with jest-axe | Jest with jest-axe |
| Cypress Accessibility Testing | Cypress Accessibility Testing |
| Python with Selenium and axe | Python with Selenium and axe |
Best Practices
✅ DO
- Test with real assistive technologies
- Include keyboard-only users
- Test color contrast
- Use semantic HTML
- Provide text alternatives
- Test with screen readers
- Run automated tests in CI
- Follow WCAG 2.1 AA standards
❌ DON'T
- Rely only on automated tests (they catch ~30-40% of issues)
- Use color alone to convey information
- Skip keyboard navigation testing
- Forget focus management in dynamic content
- Use div/span for interactive elements
- Hide focusable content with display:none
- Ignore ARIA best practices
- Skip manual testing
Related skills
improve-codebase-architecturemattpocock1MScan a codebase for deepening opportunities, present them as a visual HTML report, then grill through whichever one you pick.codebase-designmattpocock691KShared vocabulary for designing deep modules. Use when the user wants to design or improve a module's interface, find deepening opportunities, decide where a seam goes, make code more testable or AI-navigable, or when another skill needs the deep-module vocabulary.web-design-guidelinesvercel-labs676KReview UI code for Web Interface Guidelines compliance. Use when asked to "review my UI", "check accessibility", "audit design", "review UX", or "check my site against best practices".code-reviewmattpocock631KReview the changes since a fixed point (commit, branch, tag, or merge-base) along two axes: Standards (does the code follow this repo's documented coding standards?) and Spec (does the code match what the originating issue/spec asked for?). Runs both reviews in parallel sub-agents and reports them side by side. Use when the user wants to review a branch, a PR, work-in-progress changes, or asks to \"review since X\".