From process-and-robustness-principles
Use this skill on every design task that produces a user-facing surface. Trigger on every screen, component, prototype, or design review — accessibility isn't a phase, it's a property each surface either has or doesn't. Trigger when the user mentions accessibility, a11y, WCAG, screen readers, keyboard navigation, contrast, motion sensitivity, ARIA, color blindness, "section 508," "EAA," or compliance. Also trigger when the user is *not* asking about accessibility — because most of the highest-impact accessibility decisions are made silently when no one was asking. Routes to sub-aspect skills for the four WCAG sub-principles: perceivable, operable, understandable, robust.
How this skill is triggered — by the user, by Claude, or both
Slash command
/process-and-robustness-principles:accessibilityThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
Accessibility is the property of a design that lets it be used by the widest plausible range of people, including people with permanent, temporary, and situational impairments. It is not "compliance polish"; it is structural. A design that is bolted on top of an inaccessible foundation will always be partially accessible at best, and the cost to retrofit climbs quickly.
Accessibility is the property of a design that lets it be used by the widest plausible range of people, including people with permanent, temporary, and situational impairments. It is not "compliance polish"; it is structural. A design that is bolted on top of an inaccessible foundation will always be partially accessible at best, and the cost to retrofit climbs quickly.
A design is accessible to the extent that people can perceive its content, operate its controls, understand what it tells them, and rely on it across the assistive technologies they use. The four verbs — perceive, operate, understand, robust — are not arbitrary; they are the four sub-principles of the Web Content Accessibility Guidelines (WCAG), and they cover the full surface area of what can fail when a person who isn't a designer's idealized user encounters a design.
The takeaway: accessibility is a four-decade discipline with established principles, measurable criteria, and increasingly serious legal teeth.
The business case is often presented as either ethical ("it's the right thing to do") or compliance ("we'll get sued"). Both are real. But the deeper case is that accessibility is good design that's been measured against the hardest cases.
The user with a screen reader is the user who needs your label-input pairing to be programmatically associated. Every user benefits when it is. The user with low vision is the user who needs your contrast ratio to clear 4.5:1. Every user benefits when contrast is good. The user with a motor impairment is the user who needs your hit targets to be 44×44. Every user — including users on a phone in motion, in glare, with a cracked screen, or one-handed — benefits.
Accessibility raises the floor for everyone. The disabled user is the canary; if the design works for them, it works under the broader range of conditions everyone occasionally faces.
The numbers in any modern audience:
There is no surface on which accessibility doesn't apply. The relative weight of different criteria varies (a marketing landing page is mostly Perceivable + Operable; a complex form is mostly Operable + Understandable), but no surface is exempt.
WCAG organizes accessibility into four categories. Each gets its own sub-aspect skill in this plugin; this section is the overview.
Users must be able to perceive the content via at least one of their senses. The system must not present information in a way that requires a sense the user doesn't have access to.
Decisions in scope:
Users must be able to operate the controls — including users who don't use a mouse or finger. Keyboards, switch devices, voice control, eye-tracking, and screen-reader gestures all need to work.
Decisions in scope:
Tab, Enter, Space, Esc, and arrow keys as appropriate.prefers-reduced-motion; provide pause/stop for any auto-moving content.Content and behavior should be predictable and recoverable. Error messages explain what went wrong and what to do. Labels describe what they label. Navigation is consistent across pages.
Decisions in scope:
<html lang="en">) so screen readers pronounce correctly.<select> shouldn't auto-submit a form without warning).aria-describedby.The markup should work with current and future assistive technologies. Use semantic HTML where possible; use ARIA correctly when you need to extend semantics; never invent UI primitives that strip the accessibility from the underlying elements.
Decisions in scope:
<button>, <a>, <nav>, <main>, <form>, <label>. Use them for what they're for.aria-label, aria-labelledby, aria-describedby, role, aria-expanded, aria-current. Wrong ARIA is often worse than no ARIA.aria-live="polite" (or assertive) for dynamic content that screen readers should announce (toasts, validation, search results).Run through this for every screen:
PERCEIVABLE
[ ] Every image has alt text (or alt="" if decorative).
[ ] Every icon-only button has aria-label.
[ ] Color contrast ≥ 4.5:1 for body text, ≥ 3:1 for large/UI elements.
[ ] Color is never the only signal for status, required fields, or meaning.
[ ] Layout survives 200% browser zoom without horizontal scroll.
[ ] Page has a single <h1>; heading levels are nested (h1 → h2 → h3), not skipped.
OPERABLE
[ ] Every interactive element is keyboard-reachable via Tab.
[ ] Visible focus ring on every focusable element (don't outline:none without a replacement).
[ ] Esc closes any open overlay (Dialog, Sheet, Popover, Combobox).
[ ] Focus is trapped inside open modals; focus returns to the trigger when closed.
[ ] Skip-to-main link present, visible on focus.
[ ] Touch targets ≥ 44×44 (or ≥ 24×24 with adequate spacing).
[ ] prefers-reduced-motion is respected (no critical motion).
UNDERSTANDABLE
[ ] Every input has a programmatically associated <label> (or aria-label / aria-labelledby).
[ ] Errors are inline, named, and offer a fix.
[ ] Form behavior doesn't change context unexpectedly on input change.
[ ] Required fields are marked with both a visual indicator and aria-required.
[ ] <html lang> is set.
ROBUST
[ ] Use <button>, <a>, <input>, etc. for what they're for.
[ ] If you need a custom interactive element, give it the right role, tabindex, and keyboard handlers.
[ ] Live regions (aria-live) used for dynamic announcements (toast, validation, search).
[ ] Screen-reader test with NVDA / VoiceOver / TalkBack on critical flows.
Anti-pattern:
<div onclick="search()" style="cursor: pointer;">
<SearchIcon />
</div>
Not focusable, no role, no label, not a button. Screen readers say nothing useful; keyboard users can't reach it.
Right:
<button onclick="search()" aria-label="Search">
<SearchIcon aria-hidden="true" />
</button>
Native <button> (focusable, keyboard-operable, has button role). aria-label provides the accessible name. The icon is aria-hidden because the label already describes the action.
Anti-pattern:
<input type="email" />
<!-- after submit -->
<p style="color: red;">Invalid</p>
The error isn't programmatically associated with the input. Screen readers announce the input without the error; sighted users with low vision may not see "Invalid" if it's small or low-contrast.
Right:
<div class="field">
<label for="email">Email</label>
<input
id="email"
type="email"
aria-invalid="true"
aria-describedby="email-error"
/>
<p id="email-error" class="field-error">
Please enter a valid email address (e.g., [email protected]).
</p>
</div>
aria-invalid flags the input as in error; aria-describedby ties the message to the input so screen readers announce both together. The message text is specific and offers a fix.
Anti-pattern:
<div class="modal">
<h2>Confirm</h2>
<button>OK</button>
</div>
No role, no labelling, no focus management. Keyboard users can tab out into background content; screen readers don't know it's a dialog.
Right:
<div
role="dialog"
aria-modal="true"
aria-labelledby="dialog-title"
aria-describedby="dialog-description"
>
<h2 id="dialog-title">Discard changes?</h2>
<p id="dialog-description">Your unsaved edits will be lost.</p>
<button>Discard</button>
<button>Cancel</button>
</div>
Plus JavaScript that:
Esc.Most accessible UI libraries (Radix UI, React Aria, headless component sets, shadcn) handle this automatically. If you build modals from scratch, you must do all of it yourself — this is why the strong recommendation is don't.
.toast { transition: transform 200ms ease-out; }
@media (prefers-reduced-motion: reduce) {
.toast { transition: none; }
}
Or, more globally:
@media (prefers-reduced-motion: reduce) {
*, *::before, *::after {
animation-duration: 0.01ms !important;
animation-iteration-count: 1 !important;
transition-duration: 0.01ms !important;
scroll-behavior: auto !important;
}
}
Users with vestibular disorders, migraine triggers, or motion sensitivity have already told the OS they don't want motion. Honor it.
Anti-pattern:
<span style="background: red; padding: 2px 6px;"></span>
<span style="background: green; padding: 2px 6px;"></span>
Color is the only signal. Useless to color-blind users and to anyone in a screenshot or print.
Right:
<span class="badge badge-destructive">
<AlertIcon aria-hidden="true" /> Overdue
</span>
<span class="badge badge-success">
<CheckIcon aria-hidden="true" /> Paid
</span>
Color, icon, and text together. Each user reads the channel that works for them.
:focus { outline: none; } removes the only visual indicator keyboard users have. If you must restyle the focus ring, replace it with a custom one (:focus-visible { outline: 2px solid var(--ring); outline-offset: 2px; }), don't remove it.<div onclick> that "looks like a button" but isn't one. Use <button>. If you absolutely must use a div, add role="button", tabindex="0", and keyboard handlers — and you'll have rebuilt 80% of what <button> already does.role="button" on something that's already a <button>. aria-label on a <label> element. Conflicting aria-labelledby. Wrong ARIA is worse than no ARIA — it can mislead screen readers actively.aria-required. Color-blind users perceive nothing.aria-* attributes can over-narrate the UI to screen reader users. Use the minimum needed; rely on semantic HTML when possible.color (perception) — color decisions are accessibility decisions; build for both.legibility and readability (perception) — typography choices that aid screen-reading also aid sighted users with low vision and cognitive impairments.fitts-law (interaction) — target size for motor accessibility.affordance (interaction) — affordance + ARIA = accessible affordance.feedback-loop (interaction) — feedback loops must be perceivable in any modality.error and forgiveness (interaction) — accessible error recovery means errors are announceable and recoverable by all users.accessibility-perceivable — alt text, color/contrast, captions, text scaling.accessibility-operable — keyboard, focus management, motion, target size.accessibility-understandable — labels, error copy, predictable behavior.accessibility-robust — semantic HTML, ARIA, screen-reader compatibility.Accessibility, more than any other principle in this plugin set, is one where doing it well is invisible and doing it badly is sometimes invisible too — until a real user encounters it and quietly leaves. The job of the accessibility-aware designer is to test the things you can't see yourself failing on, and to build the structural habits that make accessibility the default rather than the exception. The investment is repaid every day, by users you may never meet.
npx claudepluginhub hdeibler/universal-design-principles --plugin process-and-robustness-principlesProvides UI/UX resources: 50+ styles, color palettes, font pairings, guidelines, charts for web/mobile across React, Next.js, Vue, Svelte, Tailwind, React Native, Flutter. Aids planning, building, reviewing interfaces.
Fetches up-to-date documentation from Context7 for libraries and frameworks like React, Next.js, Prisma. Use for setup questions, API references, and code examples.