Adoption

Agent Skills are supported by leading AI development tools.

VS Code Gemini CLI GitHub Goose Amp Cursor Claude Code Letta OpenCode Claude OpenAI Codex Factory VS Code Gemini CLI GitHub Goose Amp Cursor Claude Code Letta OpenCode Claude OpenAI Codex Factory

michaelsvanbeek/accessibility-testing

Name: accessibility-testing
Author: michaelsvanbeek

skills/accessibility-testing/SKILL.md

npx skillsauth add michaelsvanbeek/personal-agent-skills accessibility-testing

Clean

TrivyContainer and dependency vulnerability scanner

Clean

SemgrepStatic code analysis for vulnerabilities

Clean

mcp-scan (Snyk)Model Context Protocol security validation

Skipped

Snyk (dep)Open source security scanning

Skipped

Socket.devSupply chain security analysis

Skipped

VirusTotalMulti-engine malware detection

Skipped

CrowdStrikeAdvanced threat intelligence

Skipped

OSV-ScannerOpen Source Vulnerability database check

Skipped

OWASP Dep-Check

Accessibility Testing

When to Use

Adding automated accessibility tests to a web project
Configuring axe-core, pa11y, or Lighthouse for a11y audits
Integrating accessibility checks into CI/CD pipelines
Auditing an existing application for WCAG 2.2 AA violations
Validating ARIA attributes and roles
Testing keyboard navigation flows
Building an accessibility regression suite
Retrofitting a11y testing into a project that has none

Core Principle: Automate the Automatable, Manually Test the Rest

Automated tools catch ~30-40% of WCAG violations (missing alt text, low contrast, invalid ARIA). The rest requires manual testing with screen readers and keyboard navigation. Automate the detectable, then build manual test plans for the rest.

Testing Pyramid for Accessibility

| Layer | Tool | Catches | Speed | |-------|------|---------|-------| | Static analysis | eslint-plugin-jsx-a11y | Missing alt, invalid ARIA in JSX | Instant (lint) | | Component tests | @axe-core/react, vitest-axe | Per-component violations | Fast (unit) | | Integration tests | Playwright + axe-core | Full-page violations, focus flow | Medium | | Audit | Lighthouse CI | WCAG score, best practices | Slow (CI) | | Manual | Screen reader + keyboard | Context, flow, comprehension | Slowest |

Rule: Start from the top. Catch what you can at lint time before it reaches tests.

Static Analysis (ESLint)

Setup

npm install -D eslint-plugin-jsx-a11y

Config (`eslint.config.ts`)

import jsxA11y from "eslint-plugin-jsx-a11y";

export default [
  // ... other config
  jsxA11y.flatConfigs.recommended,
];

What It Catches

Missing alt on <img>
Invalid ARIA attributes and roles
Missing htmlFor on <label>
Non-interactive elements with click handlers (missing role and keyboard support)
Missing lang on <html>

Component-Level Testing (Vitest + axe-core)

Setup

npm install -D @axe-core/react vitest-axe jsdom

Test Pattern

import { render } from "@testing-library/react";
import { axe, toHaveNoViolations } from "vitest-axe";
import { expect, test } from "vitest";
import { MyComponent } from "./MyComponent";

expect.extend(toHaveNoViolations);

test("MyComponent has no accessibility violations", async () => {
  const { container } = render(<MyComponent />);
  const results = await axe(container);
  expect(results).toHaveNoViolations();
});

Rules

Add an axe test for every major component (forms, modals, navigation, tables).
Run axe tests as part of the standard test suite — they execute in milliseconds.
When a violation is found, fix the component, not the test. Never disable axe rules without documenting why.

Integration Testing (Playwright + axe-core)

Setup

npm install -D @playwright/test @axe-core/playwright

Full-Page Audit

import AxeBuilder from "@axe-core/playwright";
import { expect, test } from "@playwright/test";

test("homepage has no accessibility violations", async ({ page }) => {
  await page.goto("/");
  const results = await new AxeBuilder({ page })
    .withTags(["wcag2a", "wcag2aa", "wcag22aa"])
    .analyze();

  expect(results.violations).toEqual([]);
});

Scoped Audit (Specific Section)

test("checkout form is accessible", async ({ page }) => {
  await page.goto("/checkout");
  const results = await new AxeBuilder({ page })
    .include("#checkout-form")
    .withTags(["wcag2a", "wcag2aa"])
    .analyze();

  expect(results.violations).toEqual([]);
});

Keyboard Navigation Test

test("modal can be operated with keyboard only", async ({ page }) => {
  await page.goto("/");
  await page.click('[data-testid="open-modal"]');

  // Focus should be trapped in modal
  const modal = page.locator('[role="dialog"]');
  await expect(modal).toBeFocused();

  // Tab through focusable elements
  await page.keyboard.press("Tab");
  await expect(page.locator('[data-testid="modal-input"]')).toBeFocused();

  // Escape closes the modal
  await page.keyboard.press("Escape");
  await expect(modal).not.toBeVisible();

  // Focus returns to trigger element
  await expect(page.locator('[data-testid="open-modal"]')).toBeFocused();
});

Rules

Test every route/page for WCAG 2.2 AA compliance.
Test interactive flows (forms, modals, dropdowns) for keyboard operability.
Test focus management: opening modals traps focus, closing returns it to trigger.
Use withTags(["wcag2a", "wcag2aa", "wcag22aa"]) to target the correct WCAG level.

Lighthouse CI

Setup

npm install -D @lhci/cli

Config (`lighthouserc.js`)

module.exports = {
  ci: {
    collect: {
      url: ["http://localhost:3000/", "http://localhost:3000/dashboard"],
      startServerCommand: "npm run preview",
      numberOfRuns: 3,
    },
    assert: {
      assertions: {
        "categories:accessibility": ["error", { minScore: 0.9 }],
        "color-contrast": "error",
        "image-alt": "error",
        "label": "error",
        "link-name": "error",
        "button-name": "error",
      },
    },
    upload: {
      target: "temporary-public-storage",
    },
  },
};

CI Integration (Drone)

- name: lighthouse-a11y
  image: node:22-alpine
  commands:
    - npm ci
    - npm run build
    - npx @lhci/cli autorun

Rules

Accessibility score must be ≥90 (0.9). Regression below this blocks the build.
Specific checks (color-contrast, image-alt, label, link-name, button-name) are always errors.
Run Lighthouse 3 times and take the median score to reduce flakiness.

WCAG 2.2 AA Compliance Checklist

The most commonly violated WCAG criteria:

Perceivable

[ ] All images have descriptive alt text (or alt="" for decorative images)
[ ] Color contrast ratio ≥4.5:1 for normal text, ≥3:1 for large text
[ ] Information is not conveyed by color alone
[ ] Video has captions; audio has transcripts
[ ] Content is readable at 200% zoom without horizontal scrolling

Operable

[ ] All interactive elements are reachable and operable via keyboard
[ ] Focus order follows logical reading order
[ ] Focus indicator is visible (never outline: none without replacement)
[ ] No keyboard traps (user can always Tab/Escape out)
[ ] Touch targets are ≥24x24 CSS pixels (WCAG 2.2 Level AA)
[ ] Motion respects prefers-reduced-motion media query

Understandable

[ ] <html lang="..."> is set on every page
[ ] Form inputs have visible <label> elements
[ ] Error messages identify the field and describe the fix
[ ] Navigation is consistent across pages

Robust

[ ] Valid HTML (no duplicate IDs, proper nesting)
[ ] ARIA roles and attributes are valid and correctly applied
[ ] Custom components have appropriate ARIA roles, states, and properties
[ ] Status messages use role="status" or aria-live regions

Screen Reader Testing (Manual)

Tools

| OS | Screen Reader | Browser | |----|--------------|---------| | macOS | VoiceOver (built-in) | Safari | | Windows | NVDA (free) | Firefox or Chrome | | Windows | JAWS (paid) | Chrome |

Test Script

Navigate to the page using only keyboard (Tab, Enter, Arrow keys, Escape).
Listen to how the screen reader announces page landmarks, headings, and interactive elements.
Complete the primary user flow (e.g., submit a form, navigate to a detail page) without using the mouse.
Verify that dynamic content changes (modals, toasts, live regions) are announced.
Check that images are described meaningfully and decorative images are skipped.

Handling Violations

Severity Triage

| axe-core Impact | Action | |----------------|--------| | critical | Fix before merge. Blocks users entirely. | | serious | Fix before merge. Significant barrier. | | moderate | Fix within current sprint. Degraded experience. | | minor | Add to backlog. Low-impact inconvenience. |

Disabling Rules

When a rule must be disabled (rare), document it:

const results = await new AxeBuilder({ page })
  .withTags(["wcag2a", "wcag2aa"])
  .disableRules(["color-contrast"]) // Known issue: #1234, tracking upstream fix
  .analyze();

Rule: Never disable a rule without a tracking issue and a comment explaining why.

Anti-Patterns

| Anti-Pattern | Problem | Fix | |-------------|---------|-----| | aria-label on everything | Overrides visible text, confuses screen readers | Use visible labels; ARIA is a last resort | | outline: none without replacement | Keyboard users can't see focus | Use :focus-visible with custom styles | | role="button" on <div> | Missing keyboard support, missing semantics | Use <button> element instead | | Testing only with automation | Misses flow, context, and comprehension issues | Pair automation with manual screen reader testing | | Fixing tests instead of components | Violations persist for users | Fix the component, then verify the test passes | | tabindex="1" or higher | Breaks natural focus order | Only use tabindex="0" or tabindex="-1" |

Audit Checklist

When auditing an existing project for accessibility testing:

[ ] ESLint jsx-a11y plugin is configured and enforced in CI
[ ] Major components have axe-core unit tests
[ ] Every route has a Playwright + axe-core integration test
[ ] Lighthouse CI runs with accessibility score ≥0.9 threshold
[ ] Critical and serious axe violations block the build
[ ] Keyboard navigation is tested for all interactive flows (modals, forms, menus)
[ ] Focus management is tested (modal trap, return to trigger)
[ ] Manual screen reader testing is scheduled for major releases
[ ] prefers-reduced-motion is respected for animations
[ ] Disabled axe rules have tracking issues and comments

michaelsvanbeek/accessibility-testing

skills/accessibility-testing/SKILL.md

Automated accessibility testing and WCAG compliance validation. Use when: adding accessibility tests to a project, configuring axe-core or pa11y, integrating a11y checks into CI, auditing an existing application for accessibility violations, validating ARIA usage, testing keyboard navigation, or building an accessibility regression suite. Covers axe-core, Playwright a11y testing, Lighthouse accessibility audits, CI integration, and WCAG 2.2 AA compliance.

1 stars

development

Updated Apr 20, 2026

$ install --global

skillsauth

npx skillsauth add michaelsvanbeek/personal-agent-skills accessibility-testing

Install this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.

Security Scan Results

3 of 9 scanners reported clean

Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.

Scanners Passed

Scanners in report

Clean

TrivyContainer and dependency vulnerability scanner

95%

Clean

SemgrepStatic code analysis for vulnerabilities

95%

Clean

mcp-scan (Snyk)Model Context Protocol security validation

95%

Skipped

Snyk (dep)Open source security scanning

50%

Skipped

Socket.devSupply chain security analysis

50%

Skipped

VirusTotalMulti-engine malware detection

50%

Skipped

CrowdStrikeAdvanced threat intelligence

50%

Skipped

OSV-ScannerOpen Source Vulnerability database check

50%

Skipped

OWASP Dep-Check

50%

Last scanned: Apr 20, 2026, 9:29 AM5.5s1 file scanned

SKILL.md

name:: accessibility-testing
description:: Automated accessibility testing and WCAG compliance validation. Use when: adding accessibility tests to a project, configuring axe-core or pa11y, integrating a11y checks into CI, auditing an existing application for accessibility violations, validating ARIA usage, testing keyboard navigation, or building an accessibility regression suite. Covers axe-core, Playwright a11y testing, Lighthouse accessibility audits, CI integration, and WCAG 2.2 AA compliance.

Accessibility Testing

When to Use

Adding automated accessibility tests to a web project
Configuring axe-core, pa11y, or Lighthouse for a11y audits
Integrating accessibility checks into CI/CD pipelines
Auditing an existing application for WCAG 2.2 AA violations
Validating ARIA attributes and roles
Testing keyboard navigation flows
Building an accessibility regression suite
Retrofitting a11y testing into a project that has none

Core Principle: Automate the Automatable, Manually Test the Rest

Testing Pyramid for Accessibility

Rule: Start from the top. Catch what you can at lint time before it reaches tests.

Static Analysis (ESLint)

Setup

npm install -D eslint-plugin-jsx-a11y

Config (`eslint.config.ts`)

import jsxA11y from "eslint-plugin-jsx-a11y";

export default [
  // ... other config
  jsxA11y.flatConfigs.recommended,
];

What It Catches

Missing alt on <img>
Invalid ARIA attributes and roles
Missing htmlFor on <label>
Non-interactive elements with click handlers (missing role and keyboard support)
Missing lang on <html>

Component-Level Testing (Vitest + axe-core)

Setup

npm install -D @axe-core/react vitest-axe jsdom

Test Pattern

import { render } from "@testing-library/react";
import { axe, toHaveNoViolations } from "vitest-axe";
import { expect, test } from "vitest";
import { MyComponent } from "./MyComponent";

expect.extend(toHaveNoViolations);

test("MyComponent has no accessibility violations", async () => {
  const { container } = render(<MyComponent />);
  const results = await axe(container);
  expect(results).toHaveNoViolations();
});

Rules

Add an axe test for every major component (forms, modals, navigation, tables).
Run axe tests as part of the standard test suite — they execute in milliseconds.
When a violation is found, fix the component, not the test. Never disable axe rules without documenting why.

Integration Testing (Playwright + axe-core)

Setup

npm install -D @playwright/test @axe-core/playwright

Full-Page Audit

import AxeBuilder from "@axe-core/playwright";
import { expect, test } from "@playwright/test";

test("homepage has no accessibility violations", async ({ page }) => {
  await page.goto("/");
  const results = await new AxeBuilder({ page })
    .withTags(["wcag2a", "wcag2aa", "wcag22aa"])
    .analyze();

  expect(results.violations).toEqual([]);
});

Scoped Audit (Specific Section)

test("checkout form is accessible", async ({ page }) => {
  await page.goto("/checkout");
  const results = await new AxeBuilder({ page })
    .include("#checkout-form")
    .withTags(["wcag2a", "wcag2aa"])
    .analyze();

  expect(results.violations).toEqual([]);
});

Keyboard Navigation Test

test("modal can be operated with keyboard only", async ({ page }) => {
  await page.goto("/");
  await page.click('[data-testid="open-modal"]');

  // Focus should be trapped in modal
  const modal = page.locator('[role="dialog"]');
  await expect(modal).toBeFocused();

  // Tab through focusable elements
  await page.keyboard.press("Tab");
  await expect(page.locator('[data-testid="modal-input"]')).toBeFocused();

  // Escape closes the modal
  await page.keyboard.press("Escape");
  await expect(modal).not.toBeVisible();

  // Focus returns to trigger element
  await expect(page.locator('[data-testid="open-modal"]')).toBeFocused();
});

Rules

Test every route/page for WCAG 2.2 AA compliance.
Test interactive flows (forms, modals, dropdowns) for keyboard operability.
Test focus management: opening modals traps focus, closing returns it to trigger.
Use withTags(["wcag2a", "wcag2aa", "wcag22aa"]) to target the correct WCAG level.

Lighthouse CI

Setup

npm install -D @lhci/cli

Config (`lighthouserc.js`)

module.exports = {
  ci: {
    collect: {
      url: ["http://localhost:3000/", "http://localhost:3000/dashboard"],
      startServerCommand: "npm run preview",
      numberOfRuns: 3,
    },
    assert: {
      assertions: {
        "categories:accessibility": ["error", { minScore: 0.9 }],
        "color-contrast": "error",
        "image-alt": "error",
        "label": "error",
        "link-name": "error",
        "button-name": "error",
      },
    },
    upload: {
      target: "temporary-public-storage",
    },
  },
};

CI Integration (Drone)

- name: lighthouse-a11y
  image: node:22-alpine
  commands:
    - npm ci
    - npm run build
    - npx @lhci/cli autorun

Rules

Accessibility score must be ≥90 (0.9). Regression below this blocks the build.
Specific checks (color-contrast, image-alt, label, link-name, button-name) are always errors.
Run Lighthouse 3 times and take the median score to reduce flakiness.

WCAG 2.2 AA Compliance Checklist

The most commonly violated WCAG criteria:

Perceivable

[ ] All images have descriptive alt text (or alt="" for decorative images)
[ ] Color contrast ratio ≥4.5:1 for normal text, ≥3:1 for large text
[ ] Information is not conveyed by color alone
[ ] Video has captions; audio has transcripts
[ ] Content is readable at 200% zoom without horizontal scrolling

Operable

[ ] All interactive elements are reachable and operable via keyboard
[ ] Focus order follows logical reading order
[ ] Focus indicator is visible (never outline: none without replacement)
[ ] No keyboard traps (user can always Tab/Escape out)
[ ] Touch targets are ≥24x24 CSS pixels (WCAG 2.2 Level AA)
[ ] Motion respects prefers-reduced-motion media query

Understandable

[ ] <html lang="..."> is set on every page
[ ] Form inputs have visible <label> elements
[ ] Error messages identify the field and describe the fix
[ ] Navigation is consistent across pages

Robust

[ ] Valid HTML (no duplicate IDs, proper nesting)
[ ] ARIA roles and attributes are valid and correctly applied
[ ] Custom components have appropriate ARIA roles, states, and properties
[ ] Status messages use role="status" or aria-live regions

Screen Reader Testing (Manual)

Tools

| OS | Screen Reader | Browser | |----|--------------|---------| | macOS | VoiceOver (built-in) | Safari | | Windows | NVDA (free) | Firefox or Chrome | | Windows | JAWS (paid) | Chrome |

Test Script

Navigate to the page using only keyboard (Tab, Enter, Arrow keys, Escape).
Listen to how the screen reader announces page landmarks, headings, and interactive elements.
Complete the primary user flow (e.g., submit a form, navigate to a detail page) without using the mouse.
Verify that dynamic content changes (modals, toasts, live regions) are announced.
Check that images are described meaningfully and decorative images are skipped.

Handling Violations

Severity Triage

Disabling Rules

When a rule must be disabled (rare), document it:

const results = await new AxeBuilder({ page })
  .withTags(["wcag2a", "wcag2aa"])
  .disableRules(["color-contrast"]) // Known issue: #1234, tracking upstream fix
  .analyze();

Rule: Never disable a rule without a tracking issue and a comment explaining why.

Anti-Patterns

Audit Checklist

When auditing an existing project for accessibility testing:

[ ] ESLint jsx-a11y plugin is configured and enforced in CI
[ ] Major components have axe-core unit tests
[ ] Every route has a Playwright + axe-core integration test
[ ] Lighthouse CI runs with accessibility score ≥0.9 threshold
[ ] Critical and serious axe violations block the build
[ ] Keyboard navigation is tested for all interactive flows (modals, forms, menus)
[ ] Focus management is tested (modal trap, return to trigger)
[ ] Manual screen reader testing is scheduled for major releases
[ ] prefers-reduced-motion is respected for animations
[ ] Disabled axe rules have tracking issues and comments

Related Skills

michaelsvanbeek/typescript

development

VerifiedTrustedCommunity

TypeScript coding standards and type safety conventions. Use when: creating TypeScript files, defining interfaces and types, writing type-safe code, reviewing TypeScript for type correctness, auditing a codebase for type safety gaps, eliminating any or ts-ignore usage, or improving strict-mode compliance. Covers strict typing, avoiding any and ts-ignore, discriminated unions, Zod runtime validation, immutability patterns, and proper type definitions.

1SKILL.mdUpdated Apr 20, 2026

michaelsvanbeek/typescript

michaelsvanbeek/ticket-writing

testing

VerifiedTrustedCommunity

Writing clear, actionable tickets in any issue tracker (Jira, Linear, GitHub Issues, ServiceNow, etc.). Use when: creating epics, stories, tasks, bugs, or spikes; writing acceptance criteria; decomposing work for a sprint; linking dependencies between tickets; auditing backlog items for clarity; or coaching a team on ticket quality. Covers title conventions, description templates, acceptance criteria, decomposition rules, dependency linking, and org-specific pluggable configuration.

1SKILL.mdUpdated Apr 20, 2026

michaelsvanbeek/ticket-writing

michaelsvanbeek/testing

development

VerifiedTrustedCommunity

Testing strategy, patterns, and evaluation for software and LLM/AI systems. Use when: writing tests, choosing test boundaries, designing test data, structuring test suites, evaluating LLM outputs, building evaluation pipelines, setting coverage thresholds, auditing test coverage gaps in existing projects, or improving test quality and structure.

1SKILL.mdUpdated Apr 20, 2026

michaelsvanbeek/testing

michaelsvanbeek/status-updates

development

VerifiedTrustedCommunity

Writing effective status updates for different audiences and cadences. Use when: writing a weekly status update, preparing a monthly summary, drafting a quarterly review, sending updates to leadership, sharing progress with stakeholders, or improving the clarity and impact of team communications. Covers weekly, monthly, and quarterly formats tailored for upward, lateral, and downward communication.

1SKILL.mdUpdated Apr 20, 2026

michaelsvanbeek/status-updates

Download

For Claude Desktop. Download once, then upload the file in the app — no terminal needed.

Need help? View full Cowork setup guide →

Install manually

Choose your platform

# Clone the repo
git clone https://github.com/michaelsvanbeek/personal-agent-skills.git

# Copy into Claude Code skills folder (global)
cp -r personal-agent-skills/skills/accessibility-testing ~/.claude/skills/

Claude Code Skills — official skills path docs.

Repository

michaelsvanbeek/personal-agent-skills

1 stars

Compatible with

Claude Code

OpenAI Codex CLI

ChatGPT

Adoption

michaelsvanbeek/accessibility-testing

$ install --global

Security Scan Results

SKILL.md

Accessibility Testing

When to Use

Core Principle: Automate the Automatable, Manually Test the Rest

Testing Pyramid for Accessibility

Static Analysis (ESLint)

Setup

Config (eslint.config.ts)

What It Catches

Component-Level Testing (Vitest + axe-core)

Setup

Test Pattern

Rules

Integration Testing (Playwright + axe-core)

Setup

Full-Page Audit

Scoped Audit (Specific Section)

Keyboard Navigation Test

Rules

Lighthouse CI

Setup

Config (lighthouserc.js)

CI Integration (Drone)

Rules

WCAG 2.2 AA Compliance Checklist

Perceivable

Operable

Understandable

Robust

Screen Reader Testing (Manual)

Tools

Test Script

Handling Violations

Severity Triage

Disabling Rules

Anti-Patterns

Audit Checklist

Related Skills

michaelsvanbeek/typescript

michaelsvanbeek/ticket-writing

michaelsvanbeek/testing

michaelsvanbeek/status-updates

michaelsvanbeek/accessibility-testing

$ install --global

Security Scan Results

SKILL.md

Accessibility Testing

When to Use

Core Principle: Automate the Automatable, Manually Test the Rest

Testing Pyramid for Accessibility

Static Analysis (ESLint)

Setup

Config (eslint.config.ts)

What It Catches

Component-Level Testing (Vitest + axe-core)

Setup

Test Pattern

Rules

Integration Testing (Playwright + axe-core)

Setup

Full-Page Audit

Scoped Audit (Specific Section)

Keyboard Navigation Test

Rules

Lighthouse CI

Setup

Config (lighthouserc.js)

CI Integration (Drone)

Rules

WCAG 2.2 AA Compliance Checklist

Perceivable

Operable

Understandable

Robust

Screen Reader Testing (Manual)

Tools

Config (`eslint.config.ts`)

Config (`lighthouserc.js`)

Config (`eslint.config.ts`)

Config (`lighthouserc.js`)