Help us improve
Share bugs, ideas, or general feedback.
Guides WCAG 2.2 AA compliance for web UIs: keyboard navigation, focus management, ARIA attributes, color contrast, screen readers, and SPA-specific fixes like route focus and announcements.
npx claudepluginhub oborchers/fractional-cto --plugin saas-design-principlesHow this skill is triggered — by the user, by Claude, or both
Slash command
/saas-design-principles:accessibilityThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
WCAG 2.2 Level AA is the target — not because it is aspirational, but because it is law. The ADA Title II final rule requires WCAG 2.1 AA compliance for government-facing software. The European Accessibility Act applies to any SaaS accessible to EU citizens. Over 4,000 accessibility lawsuits were filed in 2023 alone.
Audits and implements frontend accessibility for WCAG 2.2 AA compliance, ARIA roles/attributes, keyboard navigation, focus management, screen readers, and automated testing.
Implements WCAG 2.1/2.2 compliance, ARIA patterns, keyboard navigation, focus management, and accessibility testing for web components.
Web accessibility discipline: semantic HTML first, ARIA only when needed, keyboard access always. Invoke whenever task involves any interaction with accessible web content -- writing, reviewing, refactoring, or debugging HTML/CSS/JS for WCAG compliance, ARIA usage, keyboard navigation, focus management, screen reader support, or accessible component patterns.
Share bugs, ideas, or general feedback.
WCAG 2.2 Level AA is the target — not because it is aspirational, but because it is law. The ADA Title II final rule requires WCAG 2.1 AA compliance for government-facing software. The European Accessibility Act applies to any SaaS accessible to EU citizens. Over 4,000 accessibility lawsuits were filed in 2023 alone.
Every interactive element must be operable by keyboard alone:
| Key | Action |
|---|---|
| Tab | Navigate between elements |
| Enter/Space | Activate element |
| Escape | Close modals, popovers, dropdowns — always |
| Arrow keys | Navigate within composite widgets |
Focus must always be visible. Many CSS resets strip :focus styles — this is a critical accessibility violation. Ensure every focusable element has a visible focus indicator.
Single-page applications break three browser behaviors that most teams miss entirely. Traditional page loads reset focus, announce the new page title, and reset scroll position. SPAs break all three.
Mandatory SPA fixes:
tabindex="-1" on the element receiving programmatic focus<title> tag on every navigationWhen uncertain where to place focus after navigation, move it to the top of the page — it is always correct.
Do not build modals, dialogs, or dropdown menus from scratch. The edge cases are vast and the failure modes are invisible to sighted developers.
Use libraries like Radix UI (the foundation of shadcn/ui) that handle ARIA attributes, focus management, and keyboard navigation internally.
Automated testing catches roughly 30% of accessibility issues. Manual testing catches the rest.
Manual testing methods:
Working implementations in examples/:
examples/spa-route-change-focus.md — Title update, focus management, and ARIA announcements for React Router, Vue Router, and SvelteKitexamples/keyboard-navigation-composite.md — Roving tabindex pattern for tab panels, with comparison to Radix UI primitivesWhen reviewing or building for accessibility:
:focus styles<title> tag updates on every navigationalt="" for decorative images)