accessibility-audit
The accessibility-audit skill generates a structured WCAG 2.2 compliance checklist and prioritised remediation plan for digital interfaces. Use it when auditing UI components, screens, or designs for accessibility barriers; checking against WCAG Level A, AA, or AAA standards; or creating actionable fix lists across perceivable, operable, understandable, and robust criteria. It requires input on what's being audited, the platform, target compliance level, and known assistive technology users, then produces a detailed pass/fail assessment with specific fixes ranked by severity.
git clone --depth 1 https://github.com/mohitagw15856/pm-claude-skills /tmp/accessibility-audit && cp -r /tmp/accessibility-audit/plugins/pm-design/skills/accessibility-audit ~/.claude/skills/accessibility-auditSKILL.md
# Accessibility Audit Skill This skill produces a structured accessibility audit based on WCAG 2.2 guidelines. It covers visual, motor, cognitive, and screen reader accessibility — with prioritised remediation for each issue found. ## Required Inputs Ask the user for these if not provided: - **What is being audited** (screen, component, full product, design spec) - **Description or image** of the UI - **Target WCAG level** (A / AA / AAA — default to AA, which is the legal standard in most jurisdictions) - **Known assistive technology users?** (Yes/No — if yes, which: screen reader / switch access / voice control / magnification) - **Platform** (Web / iOS / Android / Desktop app) ## Output Structure --- # Accessibility Audit: [Component or Screen Name] **Target standard:** WCAG 2.2 Level [AA] **Platform:** [Platform] **Date:** [Date] --- ## Audit Summary | Category | Issues Found | Critical | Moderate | Minor | |---|---|---|---|---| | Perceivable | | | | | | Operable | | | | | | Understandable | | | | | | Robust | | | | | | **Total** | | | | | **Overall compliance status:** ✅ Compliant / 🟡 Minor issues / 🔴 Fails AA standard --- ## Perceivable ### 1.1 Text Alternatives - [ ] All images have descriptive alt text (not filename or "image") - [ ] Decorative images have `alt=""` to be skipped by screen readers - [ ] Icons without visible labels have accessible names - [ ] Complex images (charts, diagrams) have extended descriptions **Issues found:** [List specific issues or "None"] ### 1.3 Adaptable - [ ] Content structure uses semantic HTML (headings, lists, landmarks) — not just visual formatting - [ ] Reading order in DOM matches visual order - [ ] Form inputs have associated labels (not placeholder text as label) - [ ] Data tables have proper headers and scope **Issues found:** ### 1.4 Distinguishable - [ ] Text contrast ratio ≥ 4.5:1 (normal text) or ≥ 3:1 (large text 18px+) - [ ] UI component contrast ratio ≥ 3:1 against background - [ ] Information is not conveyed by colour alone - [ ] Text can be resized to 200% without loss of content - [ ] No content that auto-plays audio **Issues found:** --- ## Operable ### 2.1 Keyboard Accessible - [ ] All interactive elements are reachable by keyboard (Tab key) - [ ] No keyboard traps - [ ] Custom components have keyboard interactions (arrow keys for menus, Escape to close modals) - [ ] Skip navigation link available for pages with repeated navigation **Issues found:** ### 2.4 Navigable - [ ] Focus is visible at all times (not removed with `outline: none` without replacement) - [ ] Focus order is logical and predictable - [ ] Page/screen has a descriptive title - [ ] Link text is descriptive (not "click here" or "read more") - [ ] Headings are hierarchical (H1 → H2 → H3, no skips) **Issues found:** ### 2.5 Input Modalities - [ ] Touch targets are at least 44x44px - [ ] No functionality requires complex gestures (pinch, multi-touch) without a simple alternative - [ ] Motion or dragging interactions have button alternatives **Issues found:** --- ## Understandable ### 3.1 Readable - [ ] Language of the page is set (`lang` attribute) - [ ] Unusual words, abbreviations, or jargon are explained ### 3.2 Predictable - [ ] Navigation is consistent across screens - [ ] Components behave consistently (same button does the same thing) - [ ] No unexpected context changes on focus or input ### 3.3 Input Assistance - [ ] Error messages identify the field and describe the error in plain language (not just "Invalid input") - [ ] Required fields are labelled (not just with colour or asterisk alone) - [ ] Forms provide suggestions for correcting errors where possible **Issues found:** --- ## Robust ### 4.1 Compatible - [ ] HTML is valid and well-structured - [ ] ARIA roles and attributes are used correctly (not to fix broken semantics) - [ ] Status messages (success, error, loading) are announced to screen readers without focus change **Issues found:** --- ## Prioritised Remediation List | Priority | Issue | WCAG Criterion | Fix | Effort | |---|---|---|---|---| | 🔴 Critical | [Issue] | [e.g. 1.4.3 Contrast] | [Specific fix] | [Low/Med/High] | | 🟡 Moderate | [Issue] | | | | | 🟢 Minor | [Issue] | | | | **Priority definitions:** - 🔴 Critical: Blocks access for users with disabilities. Legal risk. Fix before launch. - 🟡 Moderate: Significant friction. Fix in next sprint. - 🟢 Minor: Best practice. Address in roadmap. --- ## Quick Wins (Fix in < 1 hour) [List any issues that are trivially fixable — e.g. adding alt text, fixing contrast with a colour swap, adding a `lang` attribute. These are easy to ship immediately.] --- ## Testing Recommendations - **Manual keyboard test:** Tab through the entire flow. Can you complete every task without a mouse? - **Screen reader test:** VoiceOver (Mac/iOS), NVDA or JAWS (Windows). Is every piece of content and every action accessible? - **Colour contrast check:** Use Stark (Figma plugin) or WebAIM Contrast Checker - **Automated scan:** Axe DevTools or Lighthouse accessibility audit (catches ~30% of issues automatically) --- ## Quality Checks - [ ] Issues are mapped to specific WCAG criteria - [ ] Every critical issue has a specific fix recommendation - [ ] Quick wins are separated from larger fixes - [ ] Effort estimates are included for prioritisation - [ ] Testing recommendations are included ## Anti-Patterns - [ ] Do not rely solely on automated scanning tools — automated checks catch ~30% of issues; manual keyboard and screen reader testing is required - [ ] Do not label an issue "minor" simply because it only affects a small percentage of users — for those users it may block all access - [ ] Do not add ARIA roles to fix broken semantics — use correct semantic HTML first; ARIA is a last resort - [ ] Do not confuse colour contrast of text with colour contrast of UI components — they have different minimum ratios (4.5:1 vs 3:1) - [ ] Do not audit only the happy path — error
Conduct a structured ethical review of an AI or ML feature, model, or product. Use when preparing to deploy an AI system, assessing algorithmic risk, auditing a model for bias, or producing a responsible AI impact assessment. Produces a structured ethics review covering fairness, transparency, privacy, safety, accountability, and societal impact with a risk tier score, pre-deployment checklist, and prioritised mitigations.
Structure AI and ML product decisions with the rigour of any product decision. Use when building AI-powered features, evaluating LLM integrations, designing AI products, or assessing AI readiness. Produces a complete AI product canvas covering problem definition, model approach, data requirements, evaluation framework, UX design, responsible AI checklist, and launch monitoring plan.
Transform feature briefs into structured design briefs that give designers the context they need before opening Figma. Use when asked to write a design brief, create a design handoff, brief a designer on a new feature, or translate a PRD into design requirements. Produces a brief with user goal, emotional context, success criteria, constraints, edge cases, and out-of-scope boundaries.
Design statistically rigorous A/B tests and interpret experiment results. Use when asked to design an experiment, run an A/B test, calculate sample size, interpret test results, or assess whether an experiment was successful. Produces a complete experiment design with hypothesis, sample size, run time, success criteria, and risk flags — or a results interpretation with ship/iterate/kill recommendation.
Synthesises user signals from multiple research sources into a unified, weighted insight brief. Use when you have data from interviews, support tickets, NPS verbatims, app reviews, or sales calls and need to reconcile contradictions, surface the underlying need behind requests, or answer 'what are users really telling us'. Produces ranked insights with confidence ratings, source weighting rationale, divergent signal analysis by user segment, and a research gap identification section.
Structure a product data analysis, metric deep-dive, funnel analysis, or cohort study. Use when asked to analyse product metrics, investigate a drop in conversion, explain a data change to stakeholders, or find the root cause of a metric movement. Produces a structured analysis with question, root cause, confidence level, and recommended action.
Interpret product metrics against goals and surface actionable signals. Use when asked to analyse product health, review key metrics, investigate a performance issue, produce a health report, or assess product-market fit signals. Produces a structured health report with RAG status, trend analysis, root cause hypotheses, and prioritised actions.
Structure a retention analysis, churn investigation, or engagement deep-dive for any product team. Use when asked to analyse user retention, investigate churn, measure DAU/MAU, or build a retention improvement plan. Produces a retention snapshot with root cause hypotheses, aha-moment correlation, and prioritised interventions.