UI and frontend · inspect by default

/ui-accessibility

Inspect semantics, keyboard access, focus, contrast, and announcements

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 ui-accessibility from the just-vibe skill picker, then send the same brief.

Version 0.11.0 also supports /jv ui-accessibility, /just-vibe ui-accessibility and /jv:ui-accessibility in Claude. See shortcut setup and context examples.

Example · inspect
/just-vibe:ui-accessibility Audit modal focus, keyboard dismissal, and error announcement behavior.
edge · apply
/just-vibe:ui-accessibility Fix modal focus return and server validation announcements without relying on color.
blocked · inspect
/just-vibe:ui-accessibility Audit semantics without a screen reader; explicitly leave screen-reader behavior unverified.

What the agent does

  1. 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.
  2. 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.
  3. 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.
  4. 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
Target screens/flows, existing design conventions, and runnable UI or supplied references. Visual claims require actual renders; accessibility claims distinguish automated, keyboard, and assistive-technology evidence.

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.

Keep exploring