Usability accessibility review

Skill Xopoko/plug-n-skills/plugins/design-intelligence/skills/usability-accessibility-review

Ready-to-install skills and plugins for Codex, Claude Code, and AI coding agents: practical workflows for app delivery, architecture, research, design, and agent tooling.

Install

npx -y skills add Xopoko/plug-n-skills --skill usability-accessibility-review

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

8 stars8 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

Review screens, flows, specs, or product ideas for usability heuristics, cognitive walkthrough failures, WCAG/APG/COGA accessibility risks, inclusive design, ethical UX, and dark patterns.

SKILL.md

3.9 KB, as published. Nobody here has run it

Usability And Accessibility Review

Use for structured, evidence-tied critique, not taste.

Evidence First

Identify:

surface and task;
user or segment;
available evidence;
what was not inspected;
whether the claim needs live behavior, assistive technology, analytics, or user research.

Do not claim accessibility compliance from screenshots, mocks, or prose. Static review finds risks; compliance requires testable behavior.

With thin evidence, separate observed failures, heuristic risks, standards risks, and validation tasks.

Review Lenses

Use these lenses:

Nielsen: status visibility, real-world language, user control, consistency, error prevention, recognition over recall, flexibility, minimalist relevance, error recovery, help.
Shneiderman: consistency, universal usability, feedback, closure, error prevention/handling, easy reversal, user control, reduced memory load.
Cognitive walkthrough: for primary tasks, can users know the goal, notice the action, understand it, and see progress?
Accessibility floor: WCAG 2.2 as testable baseline; APG/COGA as design guidance.

Accessibility checks:

perceivable content and text alternatives;
keyboard operation and focus order;
visible focus;
accessible names and roles;
target size and pointer alternatives;
contrast and non-color indicators;
predictable navigation and help;
reduced redundant entry;
understandable language and recovery;
motion, timeout, and seizure risks;
cognitive support, memory burden, and clear instructions.

UI-specific accessibility floor:

visible focus and focus appearance for keyboard users;
target size and pointer alternatives for motor accessibility;
keyboard operation and alternatives to dragging or path-based gestures;
reduced redundant entry and copy-forward opportunities when safe;
accessible authentication and recovery without cognitive traps;
clear labels, instructions, error identification, suggestions, and help;
predictable navigation, status changes, timeouts, motion, and interruption control.

Static review can flag these as risks. Only live testing can confirm focus order, semantics, announcements, contrast, target geometry, keyboard behavior, motion behavior, and assistive-technology experience.

Reject or flag ethical UX risks:

fake urgency or scarcity;
hidden costs;
confirmshaming;
confusing consent;
prechecked or bundled consent;
asymmetric opt-out;
cancellation friction;
inaccessible friction;
deceptive emphasis;
engagement loops that harm user agency.

Severity

Use references/scorecards.md. P0/P1 lead; P3 polish must not bury task or accessibility risks.

Output

For prose:

Verdict: short design judgment.
Findings: ordered by severity, with evidence, principle, impact, recommendation, confidence.
Accessibility limits: what was and was not checked.
Validation needed: live tests, users, analytics, or domain evidence.
Next actions: smallest useful sequence.

For reusable output, use design_intelligence.review.v1 from references/contracts.md.

Good Finding Shape

Use:

P1 - Missing feedback after payment submission
Evidence: after tapping Pay, the button disables but no progress, status, or confirmation appears.
Principle: visibility of system status; Shneiderman informative feedback.
Impact: users may retry payment, abandon, or contact support.
Recommendation: show immediate progress, preserve form state, prevent duplicate submit, and provide success/failure recovery.
Confidence: medium; requires live slow-network validation.

Avoid vague findings: "make this cleaner", "improve accessibility", "feels confusing", "use better hierarchy", "add delight."