General · inspect by default
/a11y
Inspect semantics, keyboard access, focus, contrast, and announcements
This is an alias of ui-accessibility and inherits its full workflow.
Use for accessibility audit or requested remediation; a11y is the same canonical workflow.
Make it your own.
In Claude Code, use the slash command and add your context. In Codex, select a11y from the just-vibe skill picker, then send the same brief.
Version 0.11.0 also supports /jv a11y, /just-vibe a11y and /jv:a11y in Claude. See shortcut setup and context examples.
/just-vibe:a11y Audit modal focus, keyboard dismissal, and error announcement behavior./just-vibe:a11y Fix modal focus return and server validation announcements without relying on color./just-vibe:a11y Audit semantics without a screen reader; explicitly leave screen-reader behavior unverified.What the agent does
- Choose the actual task/route and interaction states: initial, loading, empty, error, open/closed and recovery where relevant. Inspect semantics, accessible names, relationships and contrast alongside the visible design, then the WCAG 2.2 AA additions for the stated target: focus not obscured by sticky content, 24 by 24 CSS pixel targets, single-pointer alternatives to dragging, authentication without a cognitive test, consistent help placement and no redundant re-entry.
- Execute the keyboard path and record focus at each transition. For dialogs test entry, containment where appropriate, escape/close and return to the initiating control; if that control disappears, define a sensible surviving destination.
- Exercise form errors and dynamic updates using the relevant interaction method. Check programmatic error association and announcements without relying on color or duplicate noisy live regions.
- Use automated scanning as one evidence source, then verify corrected barriers with the actual keyboard or assistive technology tested. State browser/device/AT and uncovered states; an automated pass is not a blanket conformance claim.
Inputs
- component/flow and target accessibility concerns.
- conformance target (default WCAG 2.2 AA when unspecified; state it).
Optional context: scope, references, constraints, successCriteria, environment, mode, budget.
Scope
- Reads
- Semantic roles, labels, focus sequence and focus not obscured, keyboard interactions, pointer target size and dragging alternatives, contrast, reflow and text spacing, accessible authentication, consistent help, redundant entry, and announcements.
- Writes
- Inspect/plan: inspect or propose; save requested artifacts only. Apply: edit the requested local implementation and perform relevant bounded checks while preserving unrelated work. Live data changes, remote actions and paid jobs require their resolved target and existing session authorization.
- Mode
- Inspect; component/flow and target accessibility concerns. Apply for requested remediation.
- Prerequisites
- Resolve the user brief and inspect the relevant project or supplied evidence. External capabilities are optional unless the selected action actually needs them.
Expected output
- Barrier and affected task/state, exact reproduction, correction, actual browser/input/AT evidence and remaining coverage gaps.
How the work is checked
- Modal focus returns to its trigger; errors are programmatically associated and usable without color alone.
When to stop or clarify
- Do not claim screen-reader verification without running it. Automated scans alone cannot establish full conformance.
Handling missing context
- Infer
- Inspect the target flow, existing components/tokens, actual renders or supplied references and current responsive behavior.
- Assume
- Reuse established visual conventions and preserve keyboard behavior; label unrendered changes as visually unverified.
- Ask
- Ask about an unresolved interaction or visual direction only when plausible choices materially differ; do not make a missing screenshot block source inspection.
Technical guidance
- Evidence
- Inspect native semantics, accessible name/description, focus sequence, contrast and live updates.
- Method
- Use native controls first; apply matching APG interaction patterns for custom widgets and test behavior as well as attributes.
- Pitfall
- Passing an automated checker does not prove keyboard or screen-reader usability; positive tabindex creates fragile ordering.
- Check
- Complete the main flow using only keyboard, inspect focus visibility/return and announced errors, and report assistive-tech coverage actually exercised.
Situational decisions
When automated scans pass but focus or announcements fail: Report the manual barrier and keep automated coverage separate from conformance claims.
The coding agent follows this workflow using its available tools. Installation does not grant service access or guarantee an outcome. Read the compatibility notes.