oborchers/accessibility
saas-design-principles/skills/accessibility/SKILL.md
This skill should be used when the user is building or reviewing accessibility (a11y), WCAG 2.2 AA compliance, keyboard navigation, focus management, screen reader support, ARIA attributes, color contrast, or SPA accessibility. Covers legal requirements, accessible component primitives, and the unique focus challenges of single-page applications.
$ install --global
skillsauthnpx skillsauth add oborchers/fractional-cto accessibilityInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
Security Scan Results
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
3
Scanners Passed
9
Scanners in report
Clean
TrivyContainer and dependency vulnerability scanner
95%
Clean
SemgrepStatic code analysis for vulnerabilities
95%
Clean
mcp-scan (Snyk)Model Context Protocol security validation
95%
Skipped
Snyk (dep)Open source security scanning
50%
Skipped
Socket.devSupply chain security analysis
50%
Skipped
VirusTotalMulti-engine malware detection
50%
Skipped
CrowdStrikeAdvanced threat intelligence
50%
Skipped
OSV-ScannerOpen Source Vulnerability database check
50%
Skipped
OWASP Dep-Check
50%
Last scanned: May 13, 2026, 6:50 AM141.5s3 files scanned
SKILL.md
- name:
- accessibility
- description:
- This skill should be used when the user is building or reviewing accessibility (a11y), WCAG 2.2 AA compliance, keyboard navigation, focus management, screen reader support, ARIA attributes, color contrast, or SPA accessibility. Covers legal requirements, accessible component primitives, and the unique focus challenges of single-page applications.
- version:
- 1.0.0
Accessibility Is Not a Feature — It Is a Legal Requirement
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.
Minimum Standards
Color Contrast
- 4.5:1 for normal text
- 3:1 for large text (18pt+ or 14pt bold)
Keyboard Operability
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.
SPA Accessibility
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:
- Move focus on route change — use
tabindex="-1"on the element receiving programmatic focus - Update the
<title>tag on every navigation - Announce route changes via ARIA live regions
- Restore focus on back-button navigation
When uncertain where to place focus after navigation, move it to the top of the page — it is always correct.
Use Accessible Component Primitives
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.
Testing
Automated testing catches roughly 30% of accessibility issues. Manual testing catches the rest.
Manual testing methods:
- Screen readers: NVDA (Windows), VoiceOver (macOS/iOS)
- Keyboard-only navigation (unplug the mouse)
- High-contrast mode
- Zoom to 200%
Examples
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 primitives
Review Checklist
When reviewing or building for accessibility:
- [ ] Color contrast meets 4.5:1 for normal text, 3:1 for large text
- [ ] Every interactive element is keyboard-operable
- [ ] Tab, Enter/Space, Escape, and Arrow keys behave correctly
- [ ] Focus is always visible on every focusable element
- [ ] CSS resets have not stripped
:focusstyles - [ ] Route changes move focus appropriately
- [ ]
<title>tag updates on every navigation - [ ] Route changes announced via ARIA live regions
- [ ] Back-button navigation restores focus
- [ ] Modals, dialogs, and dropdowns use accessible primitives (not custom-built)
- [ ] Manual testing performed with screen reader and keyboard-only
- [ ] Images have meaningful alt text (or
alt=""for decorative images) - [ ] Form inputs have associated labels
Related Skills
oborchers/using-planning-tools
tools
VerifiedTrustedCommunity
This skill should be used when the user invokes any /plan-* command from the planning-tools plugin (/plan-context, /plan-master, /plan-open-questions, /plan-verify, /plan-tick, /plan-progress, /plan-delete), asks how Claude Code's plan files work, asks where plans are stored, asks to author or audit a multi-phase master planning document, asks how to walk through a plan's Open Questions interactively, asks how to write progress entries, or mentions ~/.claude/plans/ or .claude/planning-tools.local.md. Provides the index of planning-tools commands, the master-plan workflow lifecycle, the v0.3.0+ list-shape mandate (phases and questions as headings + bulleted scope items, never tables), the v0.3.2+ plain-bullet shape (no `- [ ]` checkboxes — heading emoji is the sole tick signal), the progress-entry methodology, and the mechanics of Claude Code's plan-mode file storage.
15SKILL.mdUpdated May 13, 2026
oborchers/plan-verification-checklist
testing
VerifiedTrustedCommunity
This skill should be used by the plan-verifier agent and the /plan-verify command to audit a drafted master plan against a fixed checklist. Covers universal-core completeness, the v0.3.0+ no-tables-for-phases-or-questions rule, trigger-based section-coverage gaps, phase actionability (heading + per-phase TL;DR + bulleted scope + exit criteria), the v0.3.1+ per-phase TL;DR requirement, the v0.3.2+ plain-bullet scope shape (legacy `- [ ]`/`- [x]` accepted silently), the v0.3.3+ context-block shape (plan-level `**TL;DR:**` + bulleted metadata, legacy `>` blockquote accepted silently), integer phase numbering enforcement, dependency traceability, citation resolution, callout/evidence convention compliance, Open Questions placement, and the one-PR-per-master-plan rule. Single-owner of the audit checklist.
15SKILL.mdUpdated May 13, 2026
oborchers/master-plan-methodology
tools
VerifiedTrustedCommunity
This skill should be used when authoring, reviewing, or modifying a multi-phase master planning document via the planning-tools plugin (especially the /plan-master and /plan-verify commands). Codifies the universal core sections, trigger-based optional sections, integer-only phase numbering, Open Questions placement, one-PR-per-plan rule, status conventions, evidence attribution, callouts, cross-reference formats, the v0.3.0 list-shape mandate (phases and questions are heading + bulleted list, never markdown tables), the v0.3.1 per-phase TL;DR requirement (1–3 sentence what/why summary under each phase heading for glance-ability), the v0.3.2 plain-bullet scope shape (`- <action>` items, no `- [ ]` checkboxes — the phase status emoji is the sole tick signal), and the v0.3.3 context-block shape (a plan-level `**TL;DR:**` + a bulleted metadata list instead of a `>` blockquote; legacy blockquote blocks accepted silently). Project-agnostic — no ticket-prefix or plan-type taxonomy.
15SKILL.mdUpdated May 13, 2026
oborchers/whitespace-density
testing
VerifiedTrustedCommunity
This skill should be used when the user is adjusting spacing, padding, margins, content density, section gaps, vertical rhythm, or separation between elements. Also applies when reviewing whether a design feels cramped or too sparse, choosing between borders and whitespace for separation, or defining a spacing system. Covers the 4px/8px spacing system, macro vs micro whitespace, content density spectrum, separation techniques (whitespace > background shifts > borders), and vertical rhythm.
12SKILL.mdUpdated May 22, 2026