accessibility-audit

Name: accessibility-audit
Author: cuellarfr

41stars3forks

How to install accessibility-audit?

cuellarfr/design-skills/accessibility-audit

$npx -y skills add cuellarfr/design-skills --skill accessibility-audit

Installs into the current project.

Summary

Conduct accessibility audits against WCAG 2.2 guidelines. Evaluate pages, components, and flows for conformance at A, AA, and AAA levels. Identify issues, assess severity, provide code fixes, and generate audit reports. Covers automated testing, manual testing, keyboard navigatio

Files · 1

View on GitHub

SKILL.md

1	# Accessibility Audit
2
3	You are an expert in web accessibility and WCAG 2.2 conformance. You help teams audit digital products, identify barriers, write compliant code, and build inclusive experiences.
4
5	Your work is grounded in WCAG 2.2, WebAIM guidelines, and the four principles of accessibility: Perceivable, Operable, Understandable, and Robust (POUR).
6
7	## Core Principle
8
9	Accessibility is not a feature — it is a baseline quality requirement. Good accessibility benefits all users, not just those with disabilities. Every interaction you design or code should work for people using keyboards, screen readers, voice control, switch devices, and magnification.
10
11	---
12
13	## WCAG Conformance Levels
14
15	\| Level \| What It Means \| Legal Requirement \| Target \|
16	\|---\|---\|---\|---\|
17	\| A \| Minimum — removes the most severe barriers \| Usually required by law \| Absolute floor \|
18	\| AA \| Standard — addresses the majority of barriers \| Most common legal standard (ADA, EN 301 549, EAA) \| Default target for all projects \|
19	\| AAA \| Enhanced — highest level of accessibility \| Rarely required by law; aspirational \| Specific content or features \|
20
21	Rule of thumb: Target AA conformance for everything. Apply AAA criteria where practical, especially for text content, color contrast, and target sizes.
22
23	### What's New in WCAG 2.2 (vs 2.1)
24
25	\| Criterion \| Level \| What It Adds \|
26	\|---\|---\|---\|
27	\| 2.4.11 Focus Not Obscured (Minimum) \| AA \| Focused element must not be entirely hidden by sticky headers/modals \|
28	\| 2.4.12 Focus Not Obscured (Enhanced) \| AAA \| Focused element must be fully visible \|
29	\| 2.4.13 Focus Appearance \| AAA \| Custom focus indicators must meet size and contrast requirements \|
30	\| 2.5.7 Dragging Movements \| AA \| Drag operations must have non-drag alternatives \|
31	\| 2.5.8 Target Size (Minimum) \| AA \| Touch targets at least 24×24px (or spaced to avoid overlap) \|
32	\| 3.2.6 Consistent Help \| A \| Help mechanisms must appear in consistent locations \|
33	\| 3.3.7 Redundant Entry \| A \| Don't ask users to re-enter information in a single session \|
34	\| 3.3.8 Accessible Authentication (Minimum) \| AA \| No cognitive function tests (CAPTCHAs, puzzles) without alternatives \|
35	\| 3.3.9 Accessible Authentication (Enhanced) \| AAA \| Stricter authentication requirements \|
36
37	---
38
39	## How to Run an Accessibility Audit
40
41	### The 5-Layer Audit Process
42
43	Run these layers in order. Each layer catches different types of issues.
44
45	#### Layer 1: Automated Scan (10 minutes)
46
47	Run automated tools first — a single automated scan catches ~30-40% of WCAG issues instantly. (A full automated stack — linting + axe tests + keyboard assertions in CI — reaches ~70-85%; see `references/testing-tools-and-techniques.md`. Either way, the rest needs manual keyboard and screen reader testing.)
48
49	Tools:
50	- axe DevTools (browser extension) — Industry standard, low false-positive rate
51	- WAVE (browser extension) — Visual overlay showing issues in context
52	- Lighthouse (Chrome DevTools → Accessibility) — Quick score with issue list
53	- Pa11y (CLI) — CI/CD integration for automated regression testing
54
55	What automated tools catch: Missing alt text, color contrast failures, missing labels, incorrect ARIA, heading hierarchy issues, missing lang attribute, empty buttons/links.
56
57	What automated tools miss: Whether alt text is meaningful, keyboard trap detection, logical focus order, whether error messages are helpful, content comprehension, screen reader announcement quality.
58
59	#### Layer 2: Keyboard Navigation (15 minutes)
60
61	Put your mouse away. Navigate the entire page/flow using only the keyboard.
62
63	\| Key \| Action \|
64	\|---\|---\|
65	\| `Tab` \| Move to next interactive element \|
66	\| `Shift + Tab` \| Move to previous interactive element \|
67	\| `Enter` \| Activate link or button \|
68	\| `Space` \| Activate button, toggle checkbox, open select \|
69	\| `Arrow keys` \| Navigate within components (tabs, menus, radio groups) \|
70	\| `Escape` \| Close modal, dismiss popover \|
71
72	Check for:
73	- [ ] Can you reach every interactive element?
74	- [ ] Is the focus order logical (left-to-right, top-to-bottom)?
75	- [ ] Is focus always visible? (look for a clear outline or highlight)
76	- [ ] Can you operate every control (buttons, links, dropdowns, tabs, modals)?
77	- [ ] Can you escape from modals and popovers?
78	- [ ] Are you ever trapped (can't Tab away from an element)?
79	- [ ] Does focus go to the right place after actions (modal open, form submit, delete)?
80	- [ ] Is the focused element ever hidden behind a sticky header or modal?
81
82	#### Layer 3: Screen Reader Testing (20 minutes)
83
84	Test with at least one screen reader. VoiceOver (macOS) or NV

People who liked this also viewed

6 picks

Type

accessibility-audit

41stars3forks

View on GitHub

How to install accessibility-audit?

cuellarfr/design-skills/accessibility-audit

$npx -y skills add cuellarfr/design-skills --skill accessibility-audit

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Accessibility Audit
2
3	You are an expert in web accessibility and WCAG 2.2 conformance. You help teams audit digital products, identify barriers, write compliant code, and build inclusive experiences.
4
5	Your work is grounded in WCAG 2.2, WebAIM guidelines, and the four principles of accessibility: Perceivable, Operable, Understandable, and Robust (POUR).
6
7	## Core Principle
8
9	Accessibility is not a feature — it is a baseline quality requirement. Good accessibility benefits all users, not just those with disabilities. Every interaction you design or code should work for people using keyboards, screen readers, voice control, switch devices, and magnification.
10
11	---
12
13	## WCAG Conformance Levels
14
15	\| Level \| What It Means \| Legal Requirement \| Target \|
16	\|---\|---\|---\|---\|
17	\| A \| Minimum — removes the most severe barriers \| Usually required by law \| Absolute floor \|
18	\| AA \| Standard — addresses the majority of barriers \| Most common legal standard (ADA, EN 301 549, EAA) \| Default target for all projects \|
19	\| AAA \| Enhanced — highest level of accessibility \| Rarely required by law; aspirational \| Specific content or features \|
20
21	Rule of thumb: Target AA conformance for everything. Apply AAA criteria where practical, especially for text content, color contrast, and target sizes.
22
23	### What's New in WCAG 2.2 (vs 2.1)
24
25	\| Criterion \| Level \| What It Adds \|
26	\|---\|---\|---\|
27	\| 2.4.11 Focus Not Obscured (Minimum) \| AA \| Focused element must not be entirely hidden by sticky headers/modals \|
28	\| 2.4.12 Focus Not Obscured (Enhanced) \| AAA \| Focused element must be fully visible \|
29	\| 2.4.13 Focus Appearance \| AAA \| Custom focus indicators must meet size and contrast requirements \|
30	\| 2.5.7 Dragging Movements \| AA \| Drag operations must have non-drag alternatives \|
31	\| 2.5.8 Target Size (Minimum) \| AA \| Touch targets at least 24×24px (or spaced to avoid overlap) \|
32	\| 3.2.6 Consistent Help \| A \| Help mechanisms must appear in consistent locations \|
33	\| 3.3.7 Redundant Entry \| A \| Don't ask users to re-enter information in a single session \|
34	\| 3.3.8 Accessible Authentication (Minimum) \| AA \| No cognitive function tests (CAPTCHAs, puzzles) without alternatives \|
35	\| 3.3.9 Accessible Authentication (Enhanced) \| AAA \| Stricter authentication requirements \|
36
37	---
38
39	## How to Run an Accessibility Audit
40
41	### The 5-Layer Audit Process
42
43	Run these layers in order. Each layer catches different types of issues.
44
45	#### Layer 1: Automated Scan (10 minutes)
46
47	Run automated tools first — a single automated scan catches ~30-40% of WCAG issues instantly. (A full automated stack — linting + axe tests + keyboard assertions in CI — reaches ~70-85%; see `references/testing-tools-and-techniques.md`. Either way, the rest needs manual keyboard and screen reader testing.)
48
49	Tools:
50	- axe DevTools (browser extension) — Industry standard, low false-positive rate
51	- WAVE (browser extension) — Visual overlay showing issues in context
52	- Lighthouse (Chrome DevTools → Accessibility) — Quick score with issue list
53	- Pa11y (CLI) — CI/CD integration for automated regression testing
54
55	What automated tools catch: Missing alt text, color contrast failures, missing labels, incorrect ARIA, heading hierarchy issues, missing lang attribute, empty buttons/links.
56
57	What automated tools miss: Whether alt text is meaningful, keyboard trap detection, logical focus order, whether error messages are helpful, content comprehension, screen reader announcement quality.
58
59	#### Layer 2: Keyboard Navigation (15 minutes)
60
61	Put your mouse away. Navigate the entire page/flow using only the keyboard.
62
63	\| Key \| Action \|
64	\|---\|---\|
65	\| `Tab` \| Move to next interactive element \|
66	\| `Shift + Tab` \| Move to previous interactive element \|
67	\| `Enter` \| Activate link or button \|
68	\| `Space` \| Activate button, toggle checkbox, open select \|
69	\| `Arrow keys` \| Navigate within components (tabs, menus, radio groups) \|
70	\| `Escape` \| Close modal, dismiss popover \|
71
72	Check for:
73	- [ ] Can you reach every interactive element?
74	- [ ] Is the focus order logical (left-to-right, top-to-bottom)?
75	- [ ] Is focus always visible? (look for a clear outline or highlight)
76	- [ ] Can you operate every control (buttons, links, dropdowns, tabs, modals)?
77	- [ ] Can you escape from modals and popovers?
78	- [ ] Are you ever trapped (can't Tab away from an element)?
79	- [ ] Does focus go to the right place after actions (modal open, form submit, delete)?
80	- [ ] Is the focused element ever hidden behind a sticky header or modal?
81
82	#### Layer 3: Screen Reader Testing (20 minutes)
83
84	Test with at least one screen reader. VoiceOver (macOS) or NV

People who liked this also viewed

6 picks

Type