Jump to

Skill · Accessibility audit

Accessibility audit.

A WCAG audit that goes past the automated scanner.

A thorough accessibility audit and a remediation plan, anchored to WCAG 2.1 AA. The four principles (perceivable, operable, understandable, robust) checked in depth, then a five-stage methodology: automated scan, manual keyboard testing, screen reader testing, visual testing, and cognitive accessibility.

Automated tools catch 30 to 50% of issues; the rest live in keyboard, screen reader, and cognitive testing. This skill is for when accessibility itself is the goal: pre-launch verification, compliance work, or remediation after a finding.

Audience: developers, designers, QA, and product teams preparing for compliance (ADA, EN 301 549, AODA, Section 508) or systematically improving a site's accessibility.

View the skill on GitHubBrowse the full catalog

The framework

WCAG's four principles, checked in depth.

WCAG organizes accessibility around four principles. The audit covers each one, scoring against the success criteria at level A, AA, and AAA where relevant.

  1. 01Perceivable: text alternatives, captions and transcripts, content structure conveyed through markup, and contrast that meets AA (4.5:1 normal text, 3:1 large text and UI elements).
  2. 02Operable: full keyboard access with no traps, adjustable time limits, no flashing more than three times a second, navigable structure (skip links, titles, focus order), and pointer and motion alternatives.
  3. 03Understandable: declared page language, readable content, focus and navigation that do not change context unexpectedly, and input assistance that identifies errors and suggests fixes.
  4. 04Robust: valid markup, programmatically determinable name, role, and value for UI components, and status messages assistive technology can announce.

Audit methodology

Five stages. The scanner is only the first.

Each stage catches a different class of issue. Skipping the manual stages is how 'we thought we were accessible' happens.

  1. 01

    Automated scan

    Run axe DevTools, Lighthouse, WAVE, and Pa11y across the priority pages. Catches 30 to 50% of issues and misses the rest; it is the start, not the audit.

  2. 02

    Manual keyboard testing

    Unplug the mouse. Tab and Shift+Tab in logical order, Enter and Space activation, arrow keys in composite widgets, Escape to dismiss, always-visible focus, no keyboard trap.

  3. 03

    Screen reader testing

    Test at least one real combination (VoiceOver+Safari, NVDA+Firefox or Chrome, JAWS+Chrome, TalkBack+Chrome). Structure, labels, and error and status announcements.

  4. 04

    Visual testing

    Contrast for every text and UI pair, color-blindness simulation, 200% zoom with no horizontal scroll, 320px reflow, text-spacing tolerance, and honored reduced-motion.

  5. 05

    Cognitive accessibility

    Often overlooked and never reached by scanners. Reading level, clear instructions, error messages that explain the fix, correction before submission, and avoidable time limits.

Where this skill fits

Conformance is a floor, not a ceiling.

This audit goes deeper than the accessibility checks in qa-testing and design-standards. Use it when accessibility itself is the goal: pre-launch verification, compliance work, remediation after a finding or complaint, or a regular health check.

Anchor to WCAG 2.1 AA. AAA is rarely the right target; AA is the practical baseline for most products. A page that passes every success criterion is still not automatically usable, which is why the audit includes cognitive accessibility, the class of issue automated scans never reach.

Accessibility erodes with every deploy. Treating it as a one-time project means new issues keep appearing, so the durable version bakes the checks into the development cycle, fixes root causes rather than individual symptoms, and treats accessibility as a shared responsibility across content, product, design, QA, and leadership.

Reference files

Three references that go alongside the SKILL.md.

  • references/audit-report-template.md

    The full audit report template: executive summary, methodology, findings by WCAG principle, severity tiers with URLs and fixes, and a sequenced remediation roadmap.

  • references/wcag-quick-reference.md

    Condensed WCAG 2.1 AA criteria paired with the specific audit check for each, so scoring against the success criteria stays concrete.

  • references/aria-patterns.md

    Decision-grade ARIA patterns. The semantic-HTML-first principle, common interactive widgets (accordion, tabs, modal, toggle, disclosure, navigation), live regions, hiding and labeling patterns, state indicators, and anti-patterns.

Browse all reference files on GitHub

Bridges to other skills

What this audit hands off to.

The audit names the problem and the standard. These skills cover the lighter checks upstream and the component-level fixes downstream.

  • General QA

    qa-testing

    Runs smoke, standard, and full QA passes after deploys, with lighter accessibility checks folded in. Use it for routine post-deploy verification, and bring out this audit when accessibility itself is the goal.

  • Component-level fixes

    frontend-component-build

    Implements the fix once the audit names it: accessible markup, defined states, and tested behavior at the level of a single component.

  • Design-time contrast

    design-standards

    Most contrast failures can be caught at design time. This sets the contrast, spacing, and hierarchy rules for pages and components before they ship, ahead of where the audit catches what already reached production.

  • Color system

    brand-identity

    A brand color that fails AA against white makes the UI inaccessible by default. The identity system tests contrast when the palette is chosen, so the AA baseline is met before a line of UI is built.

Open source under MIT

Read the SKILL.md on GitHub.

The skill source lives in the rampstackco/claude-skills repository alongside dozens of other skills covering the full lifecycle of brand and product work. This page is a structured overview; the SKILL.md is the source. MIT licensed.

View SKILL.mdBrowse the full catalog

Frequently asked questions.

What standard does this audit use?
WCAG 2.1 AA, with notes on AAA where relevant. AA is the practical baseline for most products; AAA is rarely the right target and is reserved for above-baseline improvements. Meeting every success criterion does not guarantee a usable page, so the audit covers cognitive accessibility alongside the formal criteria.
Why is an automated scan not enough?
Automated scanners (axe DevTools, Lighthouse, WAVE, Pa11y) catch only 30 to 50% of issues. The remaining 50 to 70% live in manual keyboard testing, screen reader testing, and cognitive accessibility, which no scanner reaches. A related trap is testing only the home page: the home page is usually the most accessible, and bugs hide in deeper flows. Run scanners as the first stage, then do the manual passes.
What are the stages of the audit?
Five. An automated scan across priority pages; manual keyboard testing of the priority flows; screen reader testing with at least one real combination; visual testing for contrast, zoom, color blindness, reflow, and motion; and cognitive accessibility for reading level, instructions, error handling, and time limits. After the stages, score against WCAG per success criterion, prioritize the findings by severity, write the report, and build a sequenced remediation plan.
How are findings prioritized?
By severity. P0 (critical) blocks an entire flow for an assistive-tech user: a form with no labels, a modal without focus management, a primary CTA that is not keyboard-accessible. P1 (important) significantly degrades the experience: missing alt text on key images, low-contrast body text, errors that do not announce. P2 (minor) affects edge cases or specific assistive-technology combinations. P3 (polish) covers above-AA improvements that are not compliance-blocking. The remediation plan sequences fixes by impact and effort.
Which screen reader should I test with?
At least one real combination, since each has its own quirks: VoiceOver with Safari (macOS and iOS), NVDA with Firefox or Chrome (Windows), JAWS with Chrome (Windows, common in enterprise), or TalkBack with Chrome (Android). Check that page structure is announced (headings, landmarks), form labels read with their inputs, errors announce when they appear, status changes announce, and modal context announces on open. Skipping screen reader testing is the single biggest source of 'we thought we were accessible' surprises.
Is passing the audit a one-time thing?
No. Accessibility erodes with every deploy, so treating it as a one-time project means new issues keep appearing. Bake the checks into the development cycle, fix root causes rather than patching individual symptoms (which only makes new ones appear), and treat accessibility as a shared responsibility across content, product, design, QA, and leadership rather than a developer-only task.