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 <fg> <bg> (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 <fg> <bg> — exact WCAG contrast ratio and per-threshold pass/fail (used in the contrast check above). Accepts hex, rgb(), or basic names.
• scripts/readability.py "<text>" — 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.