القائمة
Full WCAG 2.2 AA accessibility audit procedure. Goes beyond the reference checklist with step-by-step testing methodology, tooling, and remediation guidance.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
Design a RESTful API from requirements. Use when creating a new API, adding endpoints, or restructuring an existing API. Produces endpoint specifications, schemas, and implementation guidance.
Assess system architecture, identify risks and bottlenecks, document decisions with ADRs. Covers modular monolith, microservices, event-driven, and serverless patterns.
Shift Left quality gates, feature flag pipelines, and deployment automation. Use when setting up or modifying build and deploy pipelines, or when establishing quality gates for a project.
Perform a thorough code review with structured feedback. Use when reviewing pull requests, code submissions, or when you want a quality check on your code. Covers correctness, security, performance, readability, and maintainability.
Reduce complexity while preserving exact behavior. Use when code works but is harder to read or maintain than it should be. Applies Chesterton's Fence — understand the code before simplifying it.
Generates a codebase overview for onboarding. Use when you need to understand a new project's architecture, conventions, and key files. Produces a structured summary.
| name | accessibility-audit |
| description | Full WCAG 2.2 AA accessibility audit procedure. Goes beyond the reference checklist with step-by-step testing methodology, tooling, and remediation guidance. |
An accessibility audit systematically tests a web application against WCAG 2.2 Level AA criteria using a combination of automated tools and manual testing. Automated tools catch roughly 30-40% of accessibility issues — the rest require human testing with keyboards, screen readers, and careful review of interaction patterns.
This skill provides a repeatable, step-by-step audit procedure that goes beyond running a scanner. It covers every major category of accessibility failure and provides specific remediation guidance for each.
When NOT to use: For quick spot-checks of individual components. Use the accessibility reference checklist instead. This skill is for comprehensive audits of pages or flows.
Run automated tools to catch the low-hanging fruit.
Tools (run all three — they catch different things):
| Tool | What It Catches | How to Run |
|---|---|---|
| axe-core | DOM-level WCAG violations | Browser extension or @axe-core/cli |
| Lighthouse | Performance + accessibility score | Chrome DevTools → Lighthouse tab |
| WAVE | Visual overlay of issues | Browser extension |
Procedure:
Document automated findings:
## Automated Scan Results
Tool: [axe-core / Lighthouse / WAVE]
Pages scanned: [list]
Date: [date]
| # | Issue | WCAG Criterion | Severity | Page | Element | Count |
| --- | ----------------------- | -------------- | -------- | ------ | ---------- | ----- |
| 1 | Images missing alt text | 1.1.1 | Critical | /home | img.hero | 3 |
| 2 | Low contrast text | 1.4.3 | Serious | /about | p.subtitle | 12 |
Put your mouse away. Everything in the application must be operable with only a keyboard.
Test procedure:
Tab to move through every interactive element| Check | Key | Expected |
|---|---|---|
| Focus is visible | Tab | Every focused element has a visible outline or indicator |
| Order is logical | Tab | Focus follows visual/reading order, left-to-right, top-to-bottom |
| No keyboard traps | Tab | You can always move forward — never get stuck |
| Escape closes overlays | Escape | Modals, dropdowns, popovers close and return focus |
| Enter/Space activates | Enter/Space | Buttons and links activate on keypress |
| Arrow keys work in widgets | Arrows | Tabs, menus, sliders, date pickers respond to arrow keys |
| Skip link exists | Tab (first) | First Tab press reveals "Skip to main content" link |
Keyboard traps to check specifically:
Test with at least one screen reader. Two is better.
Recommended combinations:
| Platform | Screen Reader | Browser |
|---|---|---|
| macOS | VoiceOver | Safari |
| Windows | NVDA (free) | Firefox or Chrome |
| Windows | JAWS | Chrome |
| Mobile | VoiceOver (iOS) | Safari |
| Mobile | TalkBack (Android) | Chrome |
Test procedure:
| Check | Expected |
|---|---|
| Page title is announced | Descriptive, unique title on every page |
| Headings form a logical hierarchy | h1 → h2 → h3, no skipped levels |
| Images have alt text | Decorative images have alt="", informative images have descriptive alt |
| Links describe their destination | No "click here" or "read more" without context |
| Form fields have labels | Every input is announced with its label |
| Error messages are announced | Errors are associated with fields via aria-describedby or live regions |
| Dynamic content updates are announced | aria-live regions announce changes |
| Tables have headers | <th> elements with scope attribute |
| ARIA roles are correct | Custom widgets have appropriate role, aria-expanded, aria-selected |
Text contrast (WCAG 1.4.3):
| Element | Minimum Ratio |
|---|---|
| Normal text (< 18px / 14px bold) | 4.5:1 |
| Large text (≥ 18px / 14px bold) | 3:1 |
| UI components and graphical objects | 3:1 |
Tools:
Additional color checks:
Forms are where most accessibility failures impact users.
Form checklist:
| Check | WCAG | How to Verify |
|---|---|---|
Every input has a visible <label> | 1.3.1 | Inspect DOM — <label for=""> or aria-label |
| Required fields are indicated | 1.3.1 | Visual indicator + aria-required="true" |
| Input purpose is identified | 1.3.5 | autocomplete attribute on name, email, address, etc. |
| Error messages identify the field | 3.3.1 | Error text names the specific field |
| Error messages suggest correction | 3.3.3 | "Email format: name@example.com" not just "Invalid input" |
| Errors are announced to screen readers | 4.1.3 | aria-describedby linking error to field, or aria-live region |
| Form can be submitted with Enter key | 2.1.1 | Press Enter in last field — form submits |
| Success/confirmation is announced | 4.1.3 | aria-live="polite" for success messages |
Error pattern implementation:
<!-- Correct: error linked to input -->
<label for="email">Email</label>
<input id="email" type="email" aria-describedby="email-error" aria-invalid="true" />
<span id="email-error" role="alert">Enter a valid email address</span>
<!-- Incorrect: error not associated -->
<label>Email</label>
<input type="email" />
<span class="error">Invalid</span>
Checks:
prefers-reduced-motion media query is respected — animations are disabled or reducedImplementation:
@media (prefers-reduced-motion: reduce) {
*,
*::before,
*::after {
animation-duration: 0.01ms !important;
animation-iteration-count: 1 !important;
transition-duration: 0.01ms !important;
scroll-behavior: auto !important;
}
}
Produce the audit report.
## Accessibility Audit Report
**Application**: [Name]
**Date**: [Date]
**Auditor**: [Name]
**Standard**: WCAG 2.2 Level AA
### Summary
| Severity | Count |
| ------------------------ | ----- |
| Critical (blocks access) | X |
| Serious (major barrier) | X |
| Moderate (inconvenient) | X |
| Minor (best practice) | X |
### Findings
#### Critical — Blocks Access for Some Users
| # | Issue | WCAG | Page | Element | Remediation |
| --- | ------------- | ----------- | ----- | ---------- | ----------- |
| 1 | [Description] | [Criterion] | [URL] | [Selector] | [Fix] |
#### Serious — Major Barrier
| # | Issue | WCAG | Page | Element | Remediation |
| --- | ----- | ---- | ---- | ------- | ----------- |
#### Moderate — Inconvenient
| # | Issue | WCAG | Page | Element | Remediation |
| --- | ----- | ---- | ---- | ------- | ----------- |
#### Minor — Best Practice
| # | Issue | WCAG | Page | Element | Remediation |
| --- | ----- | ---- | ---- | ------- | ----------- |
### Prioritized Remediation Plan
| Priority | Issue | Effort | Sprint |
| -------- | ----------------- | ------- | ------- |
| P1 | [Critical issues] | [S/M/L] | Current |
| P2 | [Serious issues] | [S/M/L] | Next |
| P3 | [Moderate issues] | [S/M/L] | Backlog |
| Rationalization | Reality |
|---|---|
| "Our users don't have disabilities" | ~15-20% of the population has a disability. You also have users with temporary impairments (broken arm, bright sunlight, loud environment). |
| "We'll fix accessibility later" | Retrofitting accessibility is 10x more expensive than building it in. Fix it now. |
| "The automated scan found no issues" | Automated tools catch 30-40% of issues. Manual testing is required for keyboard, screen reader, and cognitive accessibility. |
| "ARIA will fix it" | aria- attributes don't add behavior — they add semantics. Use native HTML elements first. ARIA is a last resort, not a shortcut. |
| "Screen reader users are a tiny percentage" | Accessibility benefits everyone: keyboard users, power users, users with slow connections, users with temporary injuries, and SEO. |
prefers-reduced-motion not addressedprefers-reduced-motion