accessibility-scan
One page, automated tier — run the web accessibility (a11y) rule engine against a live page and locate every violation it can detect mechanically. Pass a URL, a config target name (e.g. accesslint:accessibility-scan dev), or nothing to use the default target from accesslint.config.json. Ensures a debuggable Chrome, runs the @accesslint/core engine over CDP, and returns a worklist of live-DOM WCAG 2.2 violations, each grounded to its DOM selector and source file:line. Locates; doesn't edit. Use it for 'is this page accessible', 'check a11y on this URL', 'find contrast and alt-text issues', or to verify a UI change. For hands-on keyboard and screen-reader checks use accessibility-inspect; for a whole site or product use accessibility-audit; to diff against uncommitted changes or a branch use accessibility-diff.
- Installs
- 1.1K
- Last 24h
- +18
- Trending rank
- #6301
- Security
- Not audited
Install
Works with every agent the skills CLI supports.
npx skills add https://github.com/accesslint/skills --skill accessibility-scan- 01
Install
Run the command in your project. The CLI asks which agents to install for.
- 02
Describe the task
Ask your agent for something this skill covers. It loads accessibility-scan automatically when relevant.
- 03
Review the result
The agent follows the SKILL.md steps, scripts and references bundled with the skill.
SKILL.md
The instructions your agent reads when the skill is triggered.
Audit a live page and report each violation and where it is. Locate; don't fix.
Shared grounding and honesty conventions: ../shared/methodology.md.
$ARGUMENTS is a URL, a config target name (dev, storybook, …), or empty to audit the default target from accesslint.config.json. If it's empty and no config exists, ask for a URL or suggest npx @accesslint/cli init.
1. Audit
PORT=$(npx -y @accesslint/chrome@latest ensure | node -e 'process.stdin.on("data",d=>process.stdout.write(""+JSON.parse(d).port))')
npx -y @accesslint/cli@latest scan <target> --port "$PORT" --format json
<target> is the URL or config target name from $ARGUMENTS. Omit it (don't pass "") to audit the config's default target. Add flags as needed: --selector, --wait-for "<selector>", --include-aaa, --disable <rules>, or pin them per-target in accesslint.config.json.
2. Report
Counts by impact, then one entry per violation:
- where: selector verbatim, plus
file:line (symbol)ifsourceis present. Don't fabricate. If no violation hassource, note "source mapping unavailable; located by selector only". - evidence: contrast ratio, missing attribute, empty name.
- fix: mechanical change, or
NEEDS HUMAN.
Don't edit. For fixes, apply the mechanical ones and re-run to verify; for bulk work hand off to accesslint:accessibility-fix.
3. Tear down
npx -y @accesslint/chrome@latest stop --all # skip if ensure reported "managed":false
Notes
ensuredetermines the port; don't hardcode 9222.- CLI exit 2 means a bad URL or target, or the page never loaded; check the dev server. An unknown target name makes the CLI list the available targets from
accesslint.config.json.
FAQ
What does the accessibility-scan skill do?
One page, automated tier — run the web accessibility (a11y) rule engine against a live page and locate every violation it can detect mechanically. Pass a URL, a config target name (e.g. accesslint:accessibility-scan dev), or nothing to use the default target from accesslint.config.json. Ensures a debuggable Chrome, runs the @accesslint/core engine over CDP, and returns a worklist of live-DOM WCAG 2.2 violations, each grounded to its DOM selector and source file:line. Locates; doesn't edit. Use it for 'is this page accessible', 'check a11y on this URL', 'find contrast and alt-text issues', or to verify a UI change. For hands-on keyboard and screen-reader checks use accessibility-inspect; for a whole site or product use accessibility-audit; to diff against uncommitted changes or a branch use accessibility-diff.
How do I install accessibility-scan?
Run npx skills add https://github.com/accesslint/skills --skill accessibility-scan in your project. The skills CLI detects the agents you use and copies the skill into the right folder. For Claude Code you can also place the skill folder at ~/.claude/skills/accessibility-scan/ (personal) or .claude/skills/accessibility-scan/ (project).
Which AI agents can use accessibility-scan?
Any agent that supports the open Agent Skills format (a folder with a SKILL.md file), including Claude Code, Codex, Cursor, GitHub Copilot, Gemini CLI, Windsurf, Cline, OpenCode and more.
Is accessibility-scan safe to install?
No partner security audit is available yet. Skills can run commands and scripts, so read the SKILL.md and any bundled files before installing.
Who maintains accessibility-scan?
It is published by accesslint in accesslint/skills. It has 1,063 recorded installs.
More from accesslint/skills
accessibility-audit
accesslint/skills
Whole site or product — a full web accessibility (a11y) audit against WCAG 2.2, following the WCAG-EM methodology. Defines scope, samples representative pages and flows, runs the automated tier (accessibility-scan) and the hands-on manual tier (accessibility-inspect), and produces one conformance report. Grades each finding by severity and evidence basis, and states per-criterion conformance as pass, fail, or undetermined (needs a human). Use it for 'audit my site for accessibility', 'is this product accessible', 'a11y audit', 'WCAG or Section 508 conformance report', or any multi-page assessment. Assesses; does not fix (use accessibility-fix) or diff (use accessibility-diff). For a single page use accessibility-scan; for hands-on keyboard and screen-reader checks use accessibility-inspect.
accessibility-fix
accesslint/skills
Remediation only — repair web accessibility (a11y) violations against WCAG 2.2 with a baseline, edit, and verify loop. Takes a target (URL, files, directory) or a findings worklist from accessibility-scan/accessibility-inspect/accessibility-audit, applies mechanical fixes as given, leaves TODOs for visual or contextual judgment, and verifies by re-running the baseline check. It only fixes. To find issues use accessibility-scan (one page, automated), accessibility-inspect (one page, manual), or accessibility-audit (whole site, WCAG-EM); to check for regressions use accessibility-diff. Use it for 'fix the a11y issues in X', 'make this accessible', 'add missing alt text and labels', 'apply these accessibility fixes', 'remediate these violations'.
accessibility-diff
accesslint/skills
Regression check — diff a live page's web accessibility (a11y) violations against a baseline. By default it compares your uncommitted changes (stash-based); pass --branch [ ] to compare against a branch. Reports the new WCAG violations introduced, the ones fixed, and the count of pre-existing ones. Use it for 'did my change break accessibility', 'what a11y issues did this PR add', or as a CI gate. For a full scan of one page use accessibility-scan; for a whole site use accessibility-audit.
accessibility-inspect
accesslint/skills
One page, hands-on manual tier — drive a live page through the web accessibility (a11y) checks a rule engine can't decide: keyboard operation and focus order, screen-reader names, roles and states from the accessibility tree, reflow and zoom, reduced motion, form errors, and target size. Grades each finding by evidence basis (verified / confirm-with-a-human / human-required) and severity, and closes every criterion in a ledger: verified, flagged, not exercised, or N/A. Locates and assesses; does not fix (use accessibility-fix). Use it for keyboard testing, focus-order checks, screen-reader or a11y-tree review, reflow and zoom at 200%, or 'is this operable, not just lint-clean'. The automated tier is accessibility-scan; accessibility-audit runs both across a sampled site.
Popular frontend & design skills
setup-matt-pocock-skills
mattpocock/skills
Configure this repo for the engineering skills: set up its issue tracker, triage label vocabulary, and domain doc layout. Run once before first use of the other engineering skills.
frontend-design
anthropics/skills
Guidance for distinctive, intentional visual design when building new UI or reshaping an existing one. Helps with aesthetic direction, typography, and making choices that don't read as templated defaults.
hyperframes-animation
heygen-com/hyperframes
All animation knowledge for HyperFrames — atomic motion rules, multi-phase scene blueprints, scene transitions, broader motion-design techniques, AND the seven runtime adapters (GSAP default, plus Lottie, Three.js, Anime.js, CSS keyframes, Web Animations API, TypeGPU). Use for any motion or animation task: pick 2-4 rules and compose, or load a blueprint, or look up runtime-specific API (e.g. GSAP eases / Lottie player / Three.js mixer). Also covers auditing an existing composition's choreography (animation map) and 24 named text-animation effects. HyperFrames-native: single paused timeline, seek-safe, deterministic.
prototype
mattpocock/skills
Build a throwaway prototype to answer a design question. Use when the user wants to sanity-check whether a state model or logic feels right, or explore what a UI should look like.
hyperframes-core
heygen-com/hyperframes
The HyperFrames composition contract — build one renderable project. Use for composition structure, the data- timing attributes, class="clip", tracks, sub-compositions, variables, framework-owned media playback, deterministic-render rules, and validation. Read before writing composition HTML.
vercel-react-best-practices
vercel-labs/agent-skills
React and Next.js performance optimization guidelines from Vercel Engineering. This skill should be used when writing, reviewing, or refactoring React/Next.js code to ensure optimal performance patterns. Triggers on tasks involving React components, Next.js pages, data fetching, bundle optimization, or performance improvements.