Ui Components
Audit Radix-based UI for WCAG keyboard, focus, ARIA, and screen-reader behavior before you ship accessible dialogs and menus.
Overview
UI Components is an agent skill most often used in Ship (also Build) that walks a Radix-focused WCAG audit checklist for keyboard, focus, ARIA, and screen-reader compliance.
Install
npx skills add https://github.com/yonatangross/orchestkit --skill ui-componentsWhat is this skill?
- Keyboard navigation checklist: Tab order, Escape, Enter/Space, arrows, Home/End
- Focus management rules for dialogs: trap, return focus, initial focus, 3:1 contrast
- ARIA expectations aligned with Radix primitives (expanded, controls, selected, checked)
- Screen reader announcement checks for dialogs, menus, and form errors
- Dedicated Dialog and AlertDialog sections requiring Title and Description
- Five major checklist sections: Keyboard Navigation, Focus Management, ARIA Attributes, Screen Reader Announcements, Dial
- Dialog section requires accessible name via Dialog.Title and description via Dialog.Description
Adoption & trust: 690 installs on skills.sh; 183 GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
You shipped or are about to ship Radix dialogs and menus without a consistent way to verify accessibility behaviors.
Who is it for?
Indie SaaS teams using Radix primitives who need a fast manual audit template in the agent loop.
Skip if: Greenfield UI generation, non-Radix design systems, or teams that only want automated Lighthouse scores with no component-level review.
When should I use this skill?
User needs to verify WCAG compliance for Radix-based interactive components (dialogs, menus, tabs, form controls).
What do I get? / Deliverables
You get a completed checklist pass with explicit pass/fail areas for keyboard, focus, ARIA, and announcements before merge or release.
- Completed accessibility checklist with noted gaps
- Prioritized fixes for keyboard, focus, and ARIA issues
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Accessibility verification is a quality gate most builders run immediately before release, even though the same checklist applies while polishing UI in Build. The skill is a structured review checklist—not component generation—so the canonical shelf is Ship → review.
Where it fits
Walk the checklist on a new AlertDialog before merging the onboarding flow.
Run keyboard and focus sections on a release candidate with nested menus.
Re-audit a popover regression reported by a screen reader user.
How it compares
A checker-style accessibility ritual for Radix—not a component library generator or Figma handoff skill.
Common Questions / FAQ
Who is ui-components for?
Solo and small-team frontend builders shipping accessible overlays and forms on Radix who want an agent-guided WCAG checklist.
When should I use ui-components?
In Build while finishing frontend primitives; in Ship during code review before launch; in Operate when fixing reported a11y regressions on dialogs and menus.
Is ui-components safe to install?
It is documentation-only checklist guidance with no implied shell or network calls—still review the Security Audits panel on this Prism page like any third-party skill.
SKILL.md
READMESKILL.md - Ui Components
# Radix Accessibility Audit Checklist Verify WCAG compliance for Radix-based components. ## Keyboard Navigation - [ ] All interactive elements reachable via Tab - [ ] Tab order follows visual layout - [ ] Focus visible on all interactive elements - [ ] Escape closes overlays (dialogs, menus, popovers) - [ ] Enter/Space activates buttons and triggers - [ ] Arrow keys navigate menus, tabs, radio groups - [ ] Home/End jump to first/last items in lists ## Focus Management - [ ] Focus trapped within dialogs when open - [ ] Focus returns to trigger on close - [ ] Initial focus on logical element (first input or primary action) - [ ] No focus loss when elements are removed - [ ] Focus visible indicator meets 3:1 contrast ## ARIA Attributes (Auto-provided by Radix) - [ ] `role` appropriate for component type - [ ] `aria-expanded` on triggers for expandable content - [ ] `aria-controls` links trigger to content - [ ] `aria-haspopup` on menu triggers - [ ] `aria-selected` on selected tabs/items - [ ] `aria-checked` on checkboxes/radios - [ ] `aria-disabled` on disabled elements ## Screen Reader Announcements - [ ] Dialog title announced on open - [ ] Dialog description announced on open - [ ] Menu items announced with role - [ ] State changes announced (expanded/collapsed) - [ ] Error messages associated with inputs ## Dialogs (Dialog, AlertDialog) - [ ] Has accessible name via `Dialog.Title` - [ ] Has description via `Dialog.Description` - [ ] AlertDialog requires explicit action (no click-outside close) - [ ] Focus trapped within dialog - [ ] Escape closes dialog (or prevented with reason) ## Menus (DropdownMenu, ContextMenu) - [ ] Trigger has `aria-haspopup="menu"` - [ ] Items navigable via arrow keys - [ ] Type-ahead focuses matching items - [ ] Submenus accessible via arrow keys - [ ] Disabled items skipped in navigation ## Tooltips - [ ] Wrapped in `Tooltip.Provider` for delay sharing - [ ] Appears on hover AND focus - [ ] Dismissible via Escape - [ ] Does not block interaction with trigger - [ ] Content is text-only (use Popover for interactive) ## Forms (Select, Checkbox, RadioGroup, Switch) - [ ] Associated with label - [ ] Required state indicated - [ ] Error messages programmatically associated - [ ] Disabled state communicated - [ ] Custom controls have appropriate ARIA roles ## Testing Tools ```bash # Install axe-core for automated testing npm install -D @axe-core/react # Or use browser extensions: # - axe DevTools # - WAVE # - Accessibility Insights ``` ## Manual Testing 1. **Keyboard-only**: Unplug mouse, navigate entire flow 2. **Screen reader**: Test with VoiceOver (Mac), NVDA (Windows), or Orca (Linux) 3. **Zoom**: Test at 200% and 400% zoom levels 4. **High contrast**: Test with OS high contrast mode 5. **Reduced motion**: Test with `prefers-reduced-motion: reduce` # shadcn/ui Setup Checklist Complete setup and configuration checklist. ## Initial Setup - [ ] Initialize shadcn/ui: `npx shadcn@latest init` - [ ] Select style (New York or Default) - [ ] Select base color - [ ] Configure CSS variables: Yes - [ ] Configure `components.json` generated ## File Structure Verification - [ ] `components.json` created at root - [ ] `lib/utils.ts` created with `cn()` function - [ ] `components/ui/` directory created - [ ] CSS variables added to `globals.css` or `app.css` - [ ] Dark mode configured via CSS (Tailwind v4 CSS-first approach) ## Dependencies Installed - [ ] `class-variance-authority` for variants - [ ] `clsx` for conditional classes - [ ] `tailwind-merge` for class merging - [ ] `radix-ui` unified package (or individual `@radix-ui/react-*`) - [ ] `lucide-react` for icons (optional) ## Tailwind Configuration (v4 CSS-First) ```css /* app.css or globals.css */ @import "tailwindcss"; /* Dark mode via CSS variables - no tailwind.config.js needed */ /* Tailwind v4 auto-detects content files */ ``` - [ ] `@import "tailwindcss"` in CSS entry file - [ ] CSS variables define theme tokens - [ ]