Skill: Accessibility & UX/UI Design

When to Use

⚠️ REQUIRED: Load Sub-Files Before Implementation

read_file

• WCAG 2.2 AA Requirements — perceivable, operable, understandable, robust criteria with implementation guidance; contrast ratios
• React Accessibility Patterns — semantic HTML, focus management, skip links, live regions, form a11y, dialogs, data tables, reduced motion; shadcn/ui + Radix notes
• UX Patterns — loading/empty/error states, form design, navigation, toasts; typography, spacing, and dark mode design tokens
• Visual Design Patterns — page composition recipes (dashboard, list, detail, form), visual hierarchy, spacing rhythm, color usage (60-30-10 rule), surface elevation, typography rules, border/divider guidance, interactive states, common visual mistakes
• Component Recipes — component-level styling specifications (KPI cards, data cards, form fields, table headers/rows, badges, dialogs, navigation items, page headers, empty states, skeletons, toasts, toolbars) with exact token values, states, and makeStyles examples
• Responsive Design — breakpoints, enterprise app responsive patterns (mobile / tablet / desktop)
• Accessibility Testing — automated testing (axe-core, eslint-plugin-jsx-a11y, Lighthouse), manual checklist, Playwright pattern, top 10 failures

For Fluent UI V9 component accessibility (built-in ARIA, focus management via Tabster, high-contrast theme support), see code-apps/fluent-ui.md.

Anti-Patterns

• Using

  <div>

  or

  <span>

  as interactive elements (buttons, links) — not keyboard accessible, not announced by screen readers. Use semantic

  <button>

  and

  <a>

  elements instead.
• Adding

  role="button"

  to a

  <div>

  instead of using

  <button>

  — you then need to manually handle Enter, Space, focus, and disabled states. Native elements get these for free.
• Color as the only indicator of state (error = red, success = green) — invisible to colorblind users. Always pair color with icons, text, or patterns. All color-coded states must have a visible legend. Users will guess meanings based on common conventions (yellow = warning/draft, red = error). If your color means something domain-specific (e.g., yellow = non-billable), make it explicit with a legend or label — don't rely on color alone.
• Missing skip-to-main-content link — keyboard users must tab through the entire navigation on every page. Add a visually-hidden skip link as the first focusable element.
• Placeholder text as the only label — disappears on input, not reliably announced by screen readers. Always use a visible

  <label>

  element.
• Auto-playing animations without respecting

  prefers-reduced-motion

  — causes motion sickness for vestibular disorder users. Wrap all animations in a media query check.
• Generic link text ("Click here", "Read more") — meaningless out of context for screen reader users who navigate by links. Use descriptive text: "View project details".
• Missing

  aria-live

  regions for dynamic content — screen readers miss toast notifications, status updates, and inline validation messages. Use

  aria-live="polite"

  for status,

  aria-live="assertive"

  for errors.

Related Skills

• code-apps

  — Accessibility patterns in Code Apps (React components, shadcn/ui)

• canvas-apps

  — Accessible Canvas App design

• pcf

  — PCF control accessibility requirements

• testing

  — Accessibility testing with axe-core and Playwright