# Accessibility Review > Audits a digital product against recognized accessibility standards — WCAG (the W3C Web Content Accessibility Guidelines) and IBM's accessibility requirements — and produces a prioritized findings report mapping each issue to the specific success criterion it fails, with severity and a concrete fix. Use this whenever the user wants an accessibility review, a11y audit, WCAG check, Section 508 / EN 301 549 conformance pass, or wants to know whether a screen, component, flow, PDF, or document is accessible; wants to fix contrast, keyboard, screen-reader, focus, alt-text, form-label, or ARIA problems; or asks which WCAG criterion something violates. Reach for it even when "accessibility" isn't named — any request to make a UI usable for people with disabilities, or to meet a legal accessibility requirement, qualifies. - Skill: `joaomonteiro100/accessibility-review` (Agent Skill, multi-file: 4 files) - Install (CLI): `npx skillmds@latest add joaomonteiro100/accessibility-review` - Raw SKILL.md: https://api.skillmd.com/api/skills/joaomonteiro100/accessibility-review/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Web & Frontend - Author: JoaoMonteiro100 (https://skillmd.com/u/joaomonteiro100) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/joaomonteiro100/accessibility-review --- # Accessibility Review This skill audits a product for accessibility — how well people with disabilities (visual, motor, auditory, cognitive, situational) can perceive, operate, and understand it — and writes up what to fix, tied to the standard it fails. Accessibility isn't a subjective "nice to have": it's governed by published, testable standards, and much of it is a legal requirement (ADA, Section 508 in the US, EN 301 549 / the European Accessibility Act in the EU). Grounding findings in those standards is what makes the report credible and actionable. Two honest framing points to carry into any review: - **Automated checks catch only part of it.** Tools (axe, WAVE, Lighthouse) find maybe a third of issues — mostly contrast, missing alt, missing labels. The rest (meaningful focus order, sensible reading order, whether alt text is *good*, whether an interaction is truly operable by keyboard and screen reader) needs human judgment. Say so, and don't imply a clean automated scan means "accessible." - **You often can't fully verify from a description.** Real conformance testing needs the running product, a keyboard, and a screen reader. When you only have a screenshot or a description, give your best assessment, be explicit about what you couldn't verify, and never claim conformance you didn't test. ## The standards to reference Reference these directly and by name — they're public norms, and citing them precisely is what gives the review authority. - **WCAG (Web Content Accessibility Guidelines)** — the W3C standard, the backbone of nearly every accessibility law. Organized under four principles (the **POUR** model): content must be **Perceivable, Operable, Understandable, Robust.** Each principle contains testable **success criteria**, each at a conformance level: **A** (must), **AA** (the near-universal legal/industry target), and **AAA** (enhanced). Cite criteria by number and name, e.g. *1.4.3 Contrast (Minimum, AA)*, *2.1.1 Keyboard (A)*, *4.1.2 Name, Role, Value (A)*. Default target is **WCAG 2.1 (or 2.2) Level AA** unless the user states otherwise. Paraphrase the requirement in plain language — don't paste long verbatim spec text; point to the criterion so they can look it up. - **IBM Accessibility** — IBM publishes an accessibility requirements checklist and practical developer/designer guidance built on top of WCAG. Reference it as a well-regarded, actionable interpretation of the same criteria, useful for concrete "how to fix" direction. - Mention the relevant **legal framework** when the user's context implies one (Section 508, EN 301 549, ADA) — they mostly adopt WCAG AA by reference, so the technical work is the same. ## How to run the review ### 1. Set scope and target Pin down: what's being reviewed (screen, flow, component, whole product, a PDF or document), the **conformance target** (default WCAG 2.2 AA), and the context (web, native mobile, email, document — the criteria apply but the techniques differ). Ask what you're working from — live URL, prototype, screenshots, code — since that determines how much you can actually verify. ### 2. Evaluate across the POUR principles Walk the interface against each principle. The high-frequency checks, grouped: **Perceivable** - **Text alternatives (1.1.1):** every informative image/icon has meaningful alt text; decorative images are marked so screen readers skip them. - **Color contrast (1.4.3 / 1.4.11):** text meets ≥4.5:1 (≥3:1 for large text); UI components and meaningful graphics meet ≥3:1. **Measure it, don't eyeball** — run the bundled `scripts/contrast.py ` (accepts hex, `rgb()`, or basic names) to get the exact ratio and per-threshold pass/fail, and cite that number in the finding. - **Color not the only cue (1.4.1):** information (errors, status, links) isn't conveyed by color alone — pair with text, icon, or underline. - **Captions & transcripts (1.2.x):** video has captions, audio has transcripts. - **Reflow & resize (1.4.4 / 1.4.10):** content works zoomed to 200% and reflows to a narrow viewport without loss. - **Meaningful sequence (1.3.2):** the DOM/reading order matches the visual order. **Operable** - **Keyboard (2.1.1 / 2.1.2):** everything works with keyboard alone; no traps. - **Focus visible & order (2.4.7 / 2.4.3):** a clear focus indicator, and focus moves in a logical order. - **Target size (2.5.8):** interactive targets are large enough (≥24×24 CSS px). - **Timing & motion (2.2.1 / 2.3.1):** adjustable time limits; nothing flashes more than 3×/second; respect reduced-motion. - **Skip/bypass & headings (2.4.1 / 2.4.6):** a way past repeated blocks; descriptive headings and labels. **Understandable** - **Labels & instructions (3.3.2):** every input has a programmatic, visible label; instructions aren't placeholder-only. - **Errors (3.3.1 / 3.3.3):** errors are identified in text, tied to the field, and offer a correction. - **Consistency & predictability (3.2.x):** navigation and components behave consistently; nothing changes context unexpectedly on focus/input. - **Language & clarity (3.1.1):** page language is set; plain language for cognitive accessibility. **Robust** - **Name, Role, Value (4.1.2):** custom components expose correct name, role, and state to assistive tech — usually via native HTML first, ARIA only where needed and correct. Prefer semantic HTML over ARIA patches. - **Status messages (4.1.3):** dynamic updates (toasts, validation, live results) are announced to screen readers. Beyond the checklist, **test the way disabled users actually operate** where you can: tab through with the keyboard only, run a screen reader (VoiceOver, NVDA, TalkBack), zoom to 200%, and check reduced-motion / dark-mode. Cognitive accessibility (clear language, low memory load, forgiving flows) matters too and is easy to overlook. ### 3. Log each issue against a criterion For each problem, capture: - **Location** — screen/component/element. - **The barrier** — who it blocks and how (e.g. "keyboard users can't reach the Close button; the modal traps focus"). - **WCAG criterion (and level)** it fails — cite number + name. - **Severity** — see below. - **How to fix** — concrete, ideally the accessible-HTML/ARIA technique or design change. ### 4. Rate severity Combine **user impact** (does it *block* a task for someone, or just add friction?) with **how many users and how central the path is**. A pragmatic scale: - **Blocker** — makes a task impossible for a group (e.g. unlabeled checkout button unusable by screen readers; keyboard trap). Must fix. - **Serious** — major difficulty or exclusion on a common path (e.g. failing contrast on body text, no visible focus). - **Moderate** — noticeable barrier with a workaround. - **Minor** — small friction or best-practice gap. Note conformance level too: an **A** failure is more fundamental than an **AA** one. Where a legal target applies, flag which failures put conformance at risk. ### 5. Write the report ``` # Accessibility Review: [product / screen] — [WCAG 2.2 AA] ## Overview What was reviewed, target standard, what you tested with, what you could/couldn't verify ## Summary Issue counts by severity, top blockers, overall conformance read (honest) ## Findings (most to least severe) For each: location, barrier + who it affects, WCAG criterion (number + name + level), severity, how to fix ## Prioritized fixes Blockers first; group quick wins ## What still needs manual/AT testing Explicitly list what a keyboard + screen-reader pass on the live product must confirm ``` Lead with blockers, cite the criterion on every finding, and make fixes concrete enough to act on. Frame accessibility as designing for the full range of human ability — it overwhelmingly improves the experience for *everyone* (the curb-cut effect), not just users with disabilities. ## Producing the deliverable Default to a Markdown report; offer a `.xlsx` issue log (one row per issue: location / barrier / WCAG criterion / level / severity / fix / status) when the user wants to track remediation. Use `[placeholders]` for anything you couldn't verify, and clearly separate confirmed findings from "likely — needs testing." ## Bundled tools & automated checks - `scripts/contrast.py ` — exact WCAG contrast ratio and per-threshold pass/fail (used in the contrast check above). Accepts hex, `rgb()`, or basic names. - `scripts/readability.py ""` — Flesch Reading Ease / grade level, for plain-language and cognitive-accessibility checks (relevant to WCAG 3.1.5 and cognitive load generally). - **For the automated ~30%** — missing `alt`, unlabeled inputs, name/role/value, missing `lang`, and similar mechanical failures — point the user to the free, well-maintained scanners (**axe / axe DevTools, Google Lighthouse, Pa11y, WAVE**) rather than hand-checking them. Don't reinvent those. This skill focuses on the ~70% they can't catch: meaningful focus and reading order, whether alt text is actually *good*, sensible error recovery, and real keyboard/screen- reader operability. ## Pairs well with - **heuristic-evaluation** — general usability audit; run both to cover usability *and* accessibility. - **design-fundamentals** — contrast, hierarchy, and type choices that prevent many a11y issues. - **inclusive-design** — accessibility is inclusion for disability; inclusive-design widens the lens further. ## Standards & sources WCAG is an open W3C standard and IBM's accessibility guidance is publicly published; referencing them by name, citing criteria by number, and paraphrasing their requirements is encouraged and builds credibility. The one caution is about *their* text: don't paste long verbatim passages of the copyrighted specification or guideline prose — paraphrase the requirement and point to the source. Auditing the user's own product and using their own screens/code is exactly the intended use.