a11y-audit
Accessibility Audit
Workflow
- Detect framework from
package.json(React, Vue, Svelte) - Run static analysis -- grep JSX/TSX/HTML files for violations using the checklist below
- If dev server is running, optionally run axe-core CLI:
npx @axe-core/cli@4 http://localhost:3000 - Report findings grouped by severity
WCAG Checklist
Level A -- Critical (blocks assistive technology users)
Images:
- Every
<img>hasalt; decorative images usealt="" - Complex images (charts, diagrams) have detailed
altor linked description
Forms:
- Every input has
<label>(viahtmlFor/fororaria-label) - Required fields indicated (not by color alone)
- Error messages are descriptive and linked to the field
Interactive elements:
- All interactive elements are focusable (no
tabindex="-1"on clickable elements) - No
<div onClick>or<span onClick>-- use<button>or<a> - Links have descriptive text (not "click here")
- Buttons have accessible names (text content or
aria-label)
Structure:
- Single
<h1>per page; heading levels not skipped - Lists use
<ul>/<ol>, not manual bullet characters
Level AA -- Serious (significantly impacts usability)
Color & contrast:
- Text contrast >= 4.5:1 (normal), >= 3:1 (large 18pt+)
- Information not conveyed by color alone
- Focus indicator visible (not removed without replacement)
Navigation:
- Skip-to-content link present
- Landmarks:
<main>,<nav>,<header>,<footer> - Navigation order matches visual order
Dynamic content:
- Modals trap focus and return focus on close
- Loading states announced (
aria-liveoraria-busy) - Error messages announced (not just shown visually)
Common React anti-patterns
// Bad: non-semantic interactive element
<div onClick={handleClose}>x</div>
// Good
<button onClick={handleClose} aria-label="Close dialog">x</button>
// Bad: unlabeled input
<input type="text" placeholder="Email" />
// Good
<label htmlFor="email">Email</label>
<input id="email" type="email" />
// Bad: color-only error
<input style={{ border: '1px solid red' }} />
// Good
<input aria-invalid="true" aria-describedby="email-error" />
<span id="email-error" role="alert">Email is required</span>
Output format
Group by WCAG criterion:
- Critical (A) -- blocks assistive technology
- Serious (AA) -- significantly impacts usability
- Suggestions -- best practice improvements
Use file:line references. Include the fix for each finding.
Rules
- Report
file:line+ violation + WCAG criterion + fix - Never auto-fix -- show what to change and why
- Prioritize keyboard navigation and screen reader issues
Error Handling
@axe-core/clifails (no dev server) -- fall back to static analysis; note axe was skipped- No JSX/HTML files found -- report incompatible project and stop
- Framework undetected -- scan all
.html,.jsx,.tsx,.vuefiles
More from helderberto/skills
explain-code
Explains code with visual diagrams and analogies. Use when explaining how code works, teaching about a codebase, or when the user asks "how does this work?" Don't use for modifying code, fixing bugs, or generating new implementations.
45ship
Commit and push changes using atomic commits. Use when user asks to "ship", "commit and push", or requests committing and pushing changes. Don't use for creating pull requests or reviewing changes before committing.
45refactor-plan
Create structured refactoring plans. Use when user wants to plan a refactor, needs a refactoring strategy, or mentions breaking down large changes into small commits. Don't use for implementing code changes directly, small one-line fixes, or renaming a single variable.
44safe-repo
Check for sensitive data in repository. Use when user asks to "check for sensitive data", "/safe-repo", or wants to verify no company/credential data is in the repository. Don't use for general code review, adding .gitignore entries, or scanning non-git directories.
41lint
Run linting and formatting checks. Use when user asks to "run linter", "/lint", "check linting", "fix lint errors", or requests code linting/formatting. Don't use for running tests, type-checking only, or projects without a lint script in package.json.
40tdd
Guides test-driven development with red-green-refactor loop. Use when user wants to build features or fix bugs using TDD, mentions "red-green-refactor", wants test-first development, or requests TDD workflow. Don't use for writing tests after implementation, adding tests to existing untested code, or one-off test fixes.
40