Audit UI for Accessibility Issues
Static WCAG 2.2 AA accessibility audit skill for StyleSeed components, checking contrast, touch targets, and semantic HTML.
Why it matters
Ensure your UI meets WCAG 2.2 AA standards by auditing components and pages for accessibility regressions, focusing on mobile patterns. Receive prioritized issues and actionable fixes.
Outcomes
What it gets done
Identify and group accessibility issues by severity.
Provide safe, autofixable code suggestions.
Flag items requiring manual review or product judgment.
Assess overall accessibility risk level.
Install
Add it to your toolbox
Run in your project directory:
curl -fsSL https://spark.entire.vc/get/ag-ui-a11y | bash Overview
UI Accessibility Audit
A static WCAG 2.2 AA accessibility audit skill for StyleSeed components, checking contrast, touch targets, keyboard navigation, and semantic HTML, then applying auto-fixes and flagging the rest for review. Use it on StyleSeed components before shipping; it's a static audit only, so pair it with real screen-reader testing, and use /ss-review or /ss-audit instead for broader design-system or UX heuristic checks.
What it does
Accessibility Audit is a StyleSeed-convention skill that audits a component or page for WCAG 2.2 AA accessibility issues and fixes them. It checks all four WCAG principles: Perceivable (color contrast at 4.5:1 for normal text or 3:1 for large/bold text, 3:1 for non-text UI controls, alt text on images and aria-label on meaningful icons, and not conveying information by color alone), Operable (minimum 44x44px touch targets - flagging the common h-9/36px violation in favor of h-11, full keyboard navigation with logical tab order and visible focus-visible:ring-2 focus states, and animations respecting prefers-reduced-motion), Understandable (visible labels or aria-label on form inputs, form errors associated via aria-describedby, and a correct <html lang> attribute), and Robust (semantic HTML elements like <button>, <nav>, <main>, <header>, Radix UI components for automatic ARIA handling, and proper role attributes on custom interactive elements).
When to use - and when NOT to
Use it to audit a specific component or page (target passed as $ARGUMENTS) for accessibility compliance and apply fixes. Do not use it for general design system compliance review (use /ss-review instead), Nielsen UX heuristics (use /ss-audit), or non-StyleSeed code that lacks data-slot and semantic tokens - it assumes StyleSeed conventions. It is also a static code audit, not runtime testing - it does not simulate a screen reader.
Inputs and outputs
Input is a target component or page. Output is three-part: a list of issues found with severity (Critical/Major/Minor), auto-fixes applied directly where possible, and items flagged for manual review that need human judgment. A design system token reference table specifies minimum contrast per token: --foreground (7:1+, body text), --muted-foreground (4.5:1+, secondary text), --brand (4.5:1+, accent), --destructive (4.5:1+, error), --success (3:1+, large text/icons only), and --warning (4.5:1+) - each verified against the project's actual skin/theme rather than assumed.
Integrations
Built for the StyleSeed design system (bitjaru/styleseed), relying on its semantic color tokens and data-slot conventions, and pairs with Radix UI components for baseline ARIA handling. It is a static analysis tool, not a runtime accessibility test - verify with an actual screen reader or automated a11y testing tool for the parts it can't cover statically.
Who it's for
Frontend developers working in a StyleSeed-based codebase who need a fast, criteria-driven accessibility pass on a component or page before shipping, with clear severity triage between what can be auto-fixed and what needs human review. It's most useful right before a PR review or release, when you want objective, criteria-backed evidence that a component meets baseline accessibility rather than a subjective visual check.
FAQ
Common questions
Discussion
Questions & comments · 0
Sign In Sign in to leave a comment.