accesslint-audit

Name: accesslint-audit
Author: sickn33

44kstars6.5kforks

How to install accesslint-audit?

sickn33/agentic-awesome-skills/accesslint-audit

$npx -y skills add sickn33/agentic-awesome-skills --skill accesslint-audit

Installs into the current project.

Summary

Find and fix WCAG 2.2 accessibility issues. Two modes — report (sweep a codebase or page, produce a prioritized written report, no edits) and fix (audit→edit→verify loop on a target). Prefers direct-CDP live-DOM auditing; falls back to a browser-MCP composition or HTML-string aud

Files · 1

View on GitHub

SKILL.md

1	You audit accessibility and optionally fix what's broken.
2
3	## When to Use
4	- Use this skill when the task matches this description: Find and fix WCAG 2.2 accessibility issues. Two modes — report (sweep a codebase or page, produce a prioritized written report, no edits) and fix (audit→edit→verify loop on a target). Prefers direct-CDP live-DOM auditing; falls back to a browser-MCP composition or HTML-string audits.
5
6	## Pick a mode from the user's intent
7
8	- Report mode — "audit my codebase", "review src/components/", "what's wrong with this page?", "give me an a11y report". You audit + write a report. You do not edit files.
9	- Fix mode — "fix the a11y issues in X", "audit and fix", "make this accessible", "verify the contrast fix landed", or hands you a violation report and asks to apply it. You audit → edit → verify.
10
11	If unsure, ask. Don't default-to-fix when the user only asked for an audit.
12
13	For very large sweeps where main-thread context cost matters, you can be invoked via `Task` (general-purpose agent) for context isolation. The recipe is the same either way.
14
15	## Picking a flow
16
17	Three flows, in order of preference.
18
19	1. `audit_live` — try first for any URL. Connects to a running Chrome debug session, or auto-launches Chrome minimized — no user setup needed. Single call; IIFE bytes don't enter your context.
20	2. `audit-live-page` prompt — use when the user needs their existing browser session audited (authenticated app, specific state) and a browser MCP (chrome-devtools-mcp, playwright-mcp, puppeteer-mcp) is connected. Invoke via `Skill` with `mode: "fix"` or `mode: "plan"`.
21	3. `audit_html` — for raw HTML strings, files (`Read` first, then `audit_html`), or JSX you've rendered to a string. Pair with `audit_diff({ html })` for fix-mode verification.
22
23	For non-URL targets, skip straight to flow 3. For URLs, try flow 1; on auto-launch failure, try flow 2 if a browser MCP is connected; otherwise fall back to flow 3 with a note that live-DOM coverage is limited.
24
25	## Scope handling (report mode)
26
27	- Directory path — analyze all relevant files within.
28	- Multiple files — analyze the listed files plus imports they reach.
29	- A URL — audit it. If it's a dev-server URL, that's flow 1 or 2.
30	- No arguments — ask the user to narrow scope. Whole-codebase sweeps are rarely the right thing.
31
32	State the scope explicitly at the start of your report.
33
34	## Approach (report mode)
35
36	1. Map the surface. Glob/Grep to enumerate components, templates, styles. Sample representative files; don't open everything blindly.
37	2. Audit live where possible — the rendered DOM catches issues source can't show. Use the flow picker above.
38	3. Look for patterns. If one component fails a rule, similar components likely do too. Group by rule ID and component family — don't list 30 instances of the same issue 30 times.
39	4. Prioritize by user impact. Critical/serious first. Many low-impact violations of one rule are often a single root-cause fix.
40	5. Use `format: "compact"` for sweep-time calls. Reserve verbose output for rules you'll expand in the report.
41	6. Trust `Source:` lines. Live-DOM audits against React dev builds attach `Source: <file>:<line> (Symbol)` per violation via DevTools fibers. Use it as the file pointer instead of grepping selectors. Fall back to stable hooks → visible text → tree position when absent.
42	7. Stop and ask if a single audit returns more than ~50 violations — a 200-violation report isn't actionable.
43
44	The engine catches what's mechanically detectable. Manual judgment is needed for content clarity, screen-reader announcement quality, keyboard flow coherence, and complex visual contrast — flag those for human review, don't guess.
45
46	### Report format
47
48	```
49	# Accessibility audit — <scope>
50
51	## Summary
52	- N critical, M serious, K moderate, J minor (after deduplication)
53	- Most impactful patterns: <one-line each, max 3>
54
55	## Critical (blocks access)
56	For each pattern:
57	- Pattern: <one-line description>
58	- WCAG: <ID> — <name>
59	- Affected files: <file:line> (×N if repeated)
60	- Fix: <directive from engine output, or specific code change>
61	- Why critical: <user impact>
62
63	## Serious
64	[same shape]
65
66	## Moderate / Minor
67	[Bullet list, deduplicated by rule. Skip per-instance detail unless the fix differs.]
68
69	## Recommendations
70	- Architectural / pattern-level changes that would prevent recurrence.
71	- Tooling or component abstractions worth introducing.
72	- What to verify manually (screen reader, keyboard, low-vision testing).
73
74	## Positive findings
75	What the codebase does wel

People who liked this also viewed

6 picks

Type

accesslint-audit

44kstars6.5kforks

View on GitHub

How to install accesslint-audit?

sickn33/agentic-awesome-skills/accesslint-audit

$npx -y skills add sickn33/agentic-awesome-skills --skill accesslint-audit

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	You audit accessibility and optionally fix what's broken.
2
3	## When to Use
4	- Use this skill when the task matches this description: Find and fix WCAG 2.2 accessibility issues. Two modes — report (sweep a codebase or page, produce a prioritized written report, no edits) and fix (audit→edit→verify loop on a target). Prefers direct-CDP live-DOM auditing; falls back to a browser-MCP composition or HTML-string audits.
5
6	## Pick a mode from the user's intent
7
8	- Report mode — "audit my codebase", "review src/components/", "what's wrong with this page?", "give me an a11y report". You audit + write a report. You do not edit files.
9	- Fix mode — "fix the a11y issues in X", "audit and fix", "make this accessible", "verify the contrast fix landed", or hands you a violation report and asks to apply it. You audit → edit → verify.
10
11	If unsure, ask. Don't default-to-fix when the user only asked for an audit.
12
13	For very large sweeps where main-thread context cost matters, you can be invoked via `Task` (general-purpose agent) for context isolation. The recipe is the same either way.
14
15	## Picking a flow
16
17	Three flows, in order of preference.
18
19	1. `audit_live` — try first for any URL. Connects to a running Chrome debug session, or auto-launches Chrome minimized — no user setup needed. Single call; IIFE bytes don't enter your context.
20	2. `audit-live-page` prompt — use when the user needs their existing browser session audited (authenticated app, specific state) and a browser MCP (chrome-devtools-mcp, playwright-mcp, puppeteer-mcp) is connected. Invoke via `Skill` with `mode: "fix"` or `mode: "plan"`.
21	3. `audit_html` — for raw HTML strings, files (`Read` first, then `audit_html`), or JSX you've rendered to a string. Pair with `audit_diff({ html })` for fix-mode verification.
22
23	For non-URL targets, skip straight to flow 3. For URLs, try flow 1; on auto-launch failure, try flow 2 if a browser MCP is connected; otherwise fall back to flow 3 with a note that live-DOM coverage is limited.
24
25	## Scope handling (report mode)
26
27	- Directory path — analyze all relevant files within.
28	- Multiple files — analyze the listed files plus imports they reach.
29	- A URL — audit it. If it's a dev-server URL, that's flow 1 or 2.
30	- No arguments — ask the user to narrow scope. Whole-codebase sweeps are rarely the right thing.
31
32	State the scope explicitly at the start of your report.
33
34	## Approach (report mode)
35
36	1. Map the surface. Glob/Grep to enumerate components, templates, styles. Sample representative files; don't open everything blindly.
37	2. Audit live where possible — the rendered DOM catches issues source can't show. Use the flow picker above.
38	3. Look for patterns. If one component fails a rule, similar components likely do too. Group by rule ID and component family — don't list 30 instances of the same issue 30 times.
39	4. Prioritize by user impact. Critical/serious first. Many low-impact violations of one rule are often a single root-cause fix.
40	5. Use `format: "compact"` for sweep-time calls. Reserve verbose output for rules you'll expand in the report.
41	6. Trust `Source:` lines. Live-DOM audits against React dev builds attach `Source: <file>:<line> (Symbol)` per violation via DevTools fibers. Use it as the file pointer instead of grepping selectors. Fall back to stable hooks → visible text → tree position when absent.
42	7. Stop and ask if a single audit returns more than ~50 violations — a 200-violation report isn't actionable.
43
44	The engine catches what's mechanically detectable. Manual judgment is needed for content clarity, screen-reader announcement quality, keyboard flow coherence, and complex visual contrast — flag those for human review, don't guess.
45
46	### Report format
47
48	```
49	# Accessibility audit — <scope>
50
51	## Summary
52	- N critical, M serious, K moderate, J minor (after deduplication)
53	- Most impactful patterns: <one-line each, max 3>
54
55	## Critical (blocks access)
56	For each pattern:
57	- Pattern: <one-line description>
58	- WCAG: <ID> — <name>
59	- Affected files: <file:line> (×N if repeated)
60	- Fix: <directive from engine output, or specific code change>
61	- Why critical: <user impact>
62
63	## Serious
64	[same shape]
65
66	## Moderate / Minor
67	[Bullet list, deduplicated by rule. Skip per-instance detail unless the fix differs.]
68
69	## Recommendations
70	- Architectural / pattern-level changes that would prevent recurrence.
71	- Tooling or component abstractions worth introducing.
72	- What to verify manually (screen reader, keyboard, low-vision testing).
73
74	## Positive findings
75	What the codebase does wel

People who liked this also viewed

6 picks

Type