Stats
Actions
Tags
From process-and-robustness-principles
Use this skill when the question is whether users can *understand* the UI — predict its behavior, recover from errors, comprehend its labels and copy. Trigger when writing form labels and error messages, when designing flows with surprising state changes, when picking microcopy for the destructive moments, or when reviewing a UI that "works correctly but confuses people." Covers WCAG Principle 3 (Understandable). Sub-aspect of `accessibility`; read that first if you haven't already.
How this skill is triggered — by the user, by Claude, or both
Slash command
/process-and-robustness-principles:accessibility-understandableThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
WCAG Principle 3: information and the operation of the user interface must be understandable.
WCAG Principle 3: information and the operation of the user interface must be understandable.
The three sub-criteria, simplified:
This sub-principle is where accessibility most overlaps with general usability — but the consequences fall hardest on users with cognitive impairments, learning disabilities, low literacy, or unfamiliarity with the language.
Set the document language so screen readers pronounce correctly:
<html lang="en">
For mixed-language content, mark the exception:
<p>The French word for "dog" is <span lang="fr">chien</span>.</p>
A screen reader switches voice/pronunciation for the marked span.
Write at a reading level appropriate to your audience. For consumer products, that's typically grade 8 or below. Tools (Hemingway Editor, Readable, Microsoft Word's readability stats) measure this.
Practices that improve readability:
If you must use jargon or abbreviations, expand them on first use:
<p>
Single sign-on (<abbr title="Single Sign-On">SSO</abbr>) lets your team
use one login across all tools.
</p>
Screen readers can announce the expansion via <abbr title>. Sighted users see the expansion on hover.
For specialized terms, link to a definition or glossary the first time.
For content where pronunciation determines meaning (poetry, languages, certain proper nouns), provide pronunciation hints. Most apps don't need this; mention it for completeness.
WCAG 3.2.1 and 3.2.2: changing the value of an input or moving focus to an element should NOT trigger an unexpected context change.
Specifically:
<select> should not auto-submit a form when a value changes.If a context change is the intended behavior (typeahead search, live filter), make it expected: label the field as "Search (results filter as you type)," show results below the input, don't yank focus.
<!-- Wrong: select auto-submits on change -->
<select onchange="this.form.submit()">
<option>Country A</option>
<option>Country B</option>
</select>
<!-- Right: select waits for explicit submit -->
<select name="country">
<option>Country A</option>
<option>Country B</option>
</select>
<button type="submit">Continue</button>
Same navigation in the same place across pages. The "Help" link in the top-right on page A is in the top-right on page B too. Users (especially those with cognitive impairments or who navigate by spatial memory) rely on this.
If a sub-section needs additional nav, place it in a consistent location (e.g., a left sidebar that always appears in left-sidebar slot).
Same component does the same thing across the app. A button labeled "Save" always saves; doesn't sometimes mean "save and close" and sometimes mean "save and continue." If two different actions are needed, two different labels: "Save" and "Save and continue."
Same icon across the app should mean the same thing. A trash icon on one page meaning "delete," another page meaning "filter," is incoherent.
WCAG 3.3.1: when an error is detected, identify the item in error and describe the error in text.
<div class="field" data-state="error">
<label for="email">Email address</label>
<input id="email"
type="email"
aria-invalid="true"
aria-describedby="email-error" />
<p id="email-error" class="field-error">
<AlertIcon aria-hidden="true" />
Please enter a valid email address (e.g., [email protected]).
</p>
</div>
Three things are happening:
aria-invalid="true" flags the input as in error (assistive tech may announce).aria-describedby ties the message to the input (screen readers announce both).Every input has a programmatically associated label. The label is descriptive (not just "Field 1"). If the input requires specific format, instructions are provided alongside.
<!-- Right: label, format hint, and example -->
<div class="field">
<label for="phone">Phone number</label>
<input id="phone"
type="tel"
aria-describedby="phone-help"
placeholder="555-123-4567" />
<p id="phone-help" class="field-help">
Format: 555-123-4567. We use this only for delivery questions.
</p>
</div>
Notes:
placeholder is not a label — it disappears when the user starts typing. Use a real <label>.aria-describedby), not just placeholder.required attribute or aria-required).WCAG 3.3.3 (Level AA): when the user makes an input error and the system can suggest a correction, do so.
<!-- User typed "gmial.com" -->
<p class="field-error">
Did you mean <button type="button" onclick="acceptSuggestion('gmail.com')">[email protected]</button>?
</p>
Don't auto-correct silently — that's a context change without consent. Suggest, let the user accept.
WCAG 3.3.4 (Level AA, for legal/financial/data submissions): the user must be able to:
For destructive irreversible actions in product UIs (delete account, transfer ownership), this is the strong reason for AlertDialog confirmation, type-to-confirm patterns, and 30-day "soft delete" recovery windows.
WCAG 3.3.5 (Level AAA): context-sensitive help is available. Tooltips, inline help, "What's this?" links.
In product UIs, this lands in:
<FieldDescription> next to inputs that need explanation.? icons next to settings whose function isn't obvious.WCAG 3.2.6 (Level A, 2.2): if help mechanisms are present (contact info, FAQ link, chat widget), they appear in the same location across pages.
<form>
<div class="field">
<label for="cc-number">Card number</label>
<input id="cc-number"
type="text"
inputmode="numeric"
autocomplete="cc-number"
aria-describedby="cc-help"
required
aria-required="true" />
<p id="cc-help" class="field-help">
16 digits, no spaces or dashes
</p>
</div>
<div class="field">
<label for="cc-exp">Expiration (MM/YY)</label>
<input id="cc-exp"
type="text"
inputmode="numeric"
autocomplete="cc-exp"
placeholder="MM/YY"
required
aria-required="true" />
</div>
<div class="field">
<label for="cc-cvc">CVC</label>
<input id="cc-cvc"
type="text"
inputmode="numeric"
autocomplete="cc-csc"
aria-describedby="cvc-help"
required
aria-required="true" />
<p id="cvc-help" class="field-help">
3-digit code on the back of your card (4 on Amex)
</p>
</div>
<button type="submit">Review order</button>
</form>
What's happening:
for/id).inputmode="numeric" prompts the right keyboard on mobile.autocomplete attributes let password managers and autofill help.aria-describedby.required + aria-required).<button onclick="openDeleteDialog()">Delete account</button>
<!-- Dialog: -->
<dialog open
role="dialog"
aria-labelledby="confirm-title"
aria-describedby="confirm-desc">
<h2 id="confirm-title">Delete your account?</h2>
<p id="confirm-desc">
This permanently removes your account, all your projects (12), and your
team's access (38 members). This cannot be undone.
</p>
<p>To confirm, type your account email below:</p>
<input type="text" placeholder="[email protected]" id="confirm-input" />
<button type="button">Cancel</button>
<button type="button"
class="destructive"
disabled
id="confirm-button">
Delete account permanently
</button>
</dialog>
The user must:
Each step is a deliberate barrier against accidental destruction.
<label> associated by for/id. No placeholder-as-label.accessibility (parent).accessibility-perceivable, accessibility-operable, accessibility-robust — siblings.errors and forgiveness (interaction) — error UX is shared between accessibility and general interaction design.feedback-loop (interaction) — feedback that the system received a change is part of predictability.framing (cognition) — error copy framing affects whether the user feels blamed or helped.mental-model (cognition) — predictable behavior aligns with the user's model.Provides 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.
npx claudepluginhub hdeibler/universal-design-principles --plugin process-and-robustness-principles