[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6JWHKV415FXM9R86TSMY8F4":3,"skill-same:01M6JWHKV415FXM9R86TSMY8F4":75},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":18,"publishedAt":40,"linkOnly":41,"markdownContent":42,"markdownBody":43,"frontMatter":44,"refName":45,"commitSha":46,"skillDirectory":47,"forksCount":48,"repositoryHtmlUrl":49,"repositoryHomepageUrl":50,"ownerHtmlUrl":51,"ownerBlogUrl":52,"ownerDescription":53,"updatedAt":54,"install":55,"resources":68},"01M6JWHKV415FXM9R86TSMY8F4","accessibility-understandable",null,"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.","hashgraph-online\u002Fawesome-codex-plugins","hashgraph-online","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F160371962?v=4","01M6CNB6NRJVNNGN14TR01Q6D3","HOL (Hashgraph Online)","01M6JT1HSKKG9V68KQAQGBA7XP",1571,"Apache-2.0","https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002FHDeibler\u002Funiversal-design-principles\u002Fplugins\u002Fprocess-and-robustness-principles\u002Fskills\u002Faccessibility-understandable\u002FSKILL.md",[],[19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39],"accessibility","accessibility understandable","when","writing","labels","for","errors","you","moments","flows","microcopy","error","form","people","trigger","but","read","question","messages","error messages","ui","2026-11-10 10:12:30",false,"---\nname: accessibility-understandable\ndescription: '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.'\n---\n\n# Accessibility — Understandable\n\nWCAG Principle 3: information and the operation of the user interface must be understandable.\n\nThe three sub-criteria, simplified:\n\n1. **Readable** — language is identified, jargon is explained, abbreviations are expanded.\n2. **Predictable** — the UI behaves consistently and changes context only when the user expects.\n3. **Input assistance** — labels, instructions, error messages, and prevention of mistakes.\n\nThis 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.\n\n## 1. Readable\n\n### Language identified\n\nSet the document language so screen readers pronounce correctly:\n\n```html\n\u003Chtml lang=\"en\">\n```\n\nFor mixed-language content, mark the exception:\n\n```html\n\u003Cp>The French word for \"dog\" is \u003Cspan lang=\"fr\">chien\u003C\u002Fspan>.\u003C\u002Fp>\n```\n\nA screen reader switches voice\u002Fpronunciation for the marked span.\n\n### Plain language\n\nWrite 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.\n\nPractices that improve readability:\n\n- Short sentences (\u003C25 words).\n- Active voice (\"Click Save\" not \"Save can be clicked\").\n- Familiar words (use \"buy\" not \"procure\").\n- One idea per sentence.\n- Paragraphs ≤ 5 sentences.\n\n### Jargon and abbreviations\n\nIf you must use jargon or abbreviations, expand them on first use:\n\n```html\n\u003Cp>\n  Single sign-on (\u003Cabbr title=\"Single Sign-On\">SSO\u003C\u002Fabbr>) lets your team\n  use one login across all tools.\n\u003C\u002Fp>\n```\n\nScreen readers can announce the expansion via `\u003Cabbr title>`. Sighted users see the expansion on hover.\n\nFor specialized terms, link to a definition or glossary the first time.\n\n### Pronunciation (rare but worth knowing)\n\nFor content where pronunciation determines meaning (poetry, languages, certain proper nouns), provide pronunciation hints. Most apps don't need this; mention it for completeness.\n\n## 2. Predictable\n\n### Behavior on focus and input\n\nWCAG 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.\n\nSpecifically:\n\n- A `\u003Cselect>` should not auto-submit a form when a value changes.\n- Focusing an input should not open a popup or navigate.\n- Typing into a search field should not navigate to a result page on every keystroke.\n\nIf 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.\n\n```html\n\u003C!-- Wrong: select auto-submits on change -->\n\u003Cselect onchange=\"this.form.submit()\">\n  \u003Coption>Country A\u003C\u002Foption>\n  \u003Coption>Country B\u003C\u002Foption>\n\u003C\u002Fselect>\n\n\u003C!-- Right: select waits for explicit submit -->\n\u003Cselect name=\"country\">\n  \u003Coption>Country A\u003C\u002Foption>\n  \u003Coption>Country B\u003C\u002Foption>\n\u003C\u002Fselect>\n\u003Cbutton type=\"submit\">Continue\u003C\u002Fbutton>\n```\n\n### Consistent navigation\n\nSame 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.\n\nIf a sub-section needs additional nav, place it in a consistent location (e.g., a left sidebar that always appears in left-sidebar slot).\n\n### Consistent identification\n\nSame 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.\"\n\nSame icon across the app should mean the same thing. A trash icon on one page meaning \"delete,\" another page meaning \"filter,\" is incoherent.\n\n## 3. Input assistance\n\n### Error identification\n\nWCAG 3.3.1: when an error is detected, identify the item in error and describe the error in text.\n\n```html\n\u003Cdiv class=\"field\" data-state=\"error\">\n  \u003Clabel for=\"email\">Email address\u003C\u002Flabel>\n  \u003Cinput id=\"email\"\n         type=\"email\"\n         aria-invalid=\"true\"\n         aria-describedby=\"email-error\" \u002F>\n  \u003Cp id=\"email-error\" class=\"field-error\">\n    \u003CAlertIcon aria-hidden=\"true\" \u002F>\n    Please enter a valid email address (e.g., name@example.com).\n  \u003C\u002Fp>\n\u003C\u002Fdiv>\n```\n\nThree things are happening:\n\n- `aria-invalid=\"true\"` flags the input as in error (assistive tech may announce).\n- `aria-describedby` ties the message to the input (screen readers announce both).\n- The message text is specific (says what's wrong) and actionable (offers an example).\n\n### Labels and instructions\n\nEvery input has a programmatically associated label. The label is descriptive (not just \"Field 1\"). If the input requires specific format, instructions are provided alongside.\n\n```html\n\u003C!-- Right: label, format hint, and example -->\n\u003Cdiv class=\"field\">\n  \u003Clabel for=\"phone\">Phone number\u003C\u002Flabel>\n  \u003Cinput id=\"phone\"\n         type=\"tel\"\n         aria-describedby=\"phone-help\"\n         placeholder=\"555-123-4567\" \u002F>\n  \u003Cp id=\"phone-help\" class=\"field-help\">\n    Format: 555-123-4567. We use this only for delivery questions.\n  \u003C\u002Fp>\n\u003C\u002Fdiv>\n```\n\nNotes:\n\n- `placeholder` is *not* a label — it disappears when the user starts typing. Use a real `\u003Clabel>`.\n- Format hints belong in adjacent text (`aria-describedby`), not just placeholder.\n- Required fields should be marked both visually (asterisk) and programmatically (`required` attribute or `aria-required`).\n\n### Error suggestion\n\nWCAG 3.3.3 (Level AA): when the user makes an input error and the system can suggest a correction, do so.\n\n```html\n\u003C!-- User typed \"gmial.com\" -->\n\u003Cp class=\"field-error\">\n  Did you mean \u003Cbutton type=\"button\" onclick=\"acceptSuggestion('gmail.com')\">name@gmail.com\u003C\u002Fbutton>?\n\u003C\u002Fp>\n```\n\nDon't auto-correct silently — that's a context change without consent. Suggest, let the user accept.\n\n### Error prevention\n\nWCAG 3.3.4 (Level AA, for legal\u002Ffinancial\u002Fdata submissions): the user must be able to:\n\n- **Reverse** the submission (a \"Cancel my order\" period), OR\n- **Check** the submission for errors before final commit (a confirmation page), OR\n- **Confirm** explicitly before final commit (a confirm dialog).\n\nFor 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.\n\n### Help\n\nWCAG 3.3.5 (Level AAA): context-sensitive help is available. Tooltips, inline help, \"What's this?\" links.\n\nIn product UIs, this lands in:\n\n- `\u003CFieldDescription>` next to inputs that need explanation.\n- `?` icons next to settings whose function isn't obvious.\n- A persistent help link or chat in chrome.\n\n### Consistent help\n\nWCAG 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.\n\n## Worked examples\n\n### Example 1: a credit-card form with full input assistance\n\n```html\n\u003Cform>\n  \u003Cdiv class=\"field\">\n    \u003Clabel for=\"cc-number\">Card number\u003C\u002Flabel>\n    \u003Cinput id=\"cc-number\"\n           type=\"text\"\n           inputmode=\"numeric\"\n           autocomplete=\"cc-number\"\n           aria-describedby=\"cc-help\"\n           required\n           aria-required=\"true\" \u002F>\n    \u003Cp id=\"cc-help\" class=\"field-help\">\n      16 digits, no spaces or dashes\n    \u003C\u002Fp>\n  \u003C\u002Fdiv>\n\n  \u003Cdiv class=\"field\">\n    \u003Clabel for=\"cc-exp\">Expiration (MM\u002FYY)\u003C\u002Flabel>\n    \u003Cinput id=\"cc-exp\"\n           type=\"text\"\n           inputmode=\"numeric\"\n           autocomplete=\"cc-exp\"\n           placeholder=\"MM\u002FYY\"\n           required\n           aria-required=\"true\" \u002F>\n  \u003C\u002Fdiv>\n\n  \u003Cdiv class=\"field\">\n    \u003Clabel for=\"cc-cvc\">CVC\u003C\u002Flabel>\n    \u003Cinput id=\"cc-cvc\"\n           type=\"text\"\n           inputmode=\"numeric\"\n           autocomplete=\"cc-csc\"\n           aria-describedby=\"cvc-help\"\n           required\n           aria-required=\"true\" \u002F>\n    \u003Cp id=\"cvc-help\" class=\"field-help\">\n      3-digit code on the back of your card (4 on Amex)\n    \u003C\u002Fp>\n  \u003C\u002Fdiv>\n\n  \u003Cbutton type=\"submit\">Review order\u003C\u002Fbutton>\n\u003C\u002Fform>\n```\n\nWhat's happening:\n\n- Each field has a real label (associated via `for`\u002F`id`).\n- `inputmode=\"numeric\"` prompts the right keyboard on mobile.\n- `autocomplete` attributes let password managers and autofill help.\n- Help text is associated via `aria-describedby`.\n- Required is both visual (probably an asterisk from CSS) and programmatic (`required` + `aria-required`).\n- Submit goes to a \"Review order\" page (error prevention via review step).\n\n### Example 2: a destructive action with prevention layers\n\n```html\n\u003Cbutton onclick=\"openDeleteDialog()\">Delete account\u003C\u002Fbutton>\n\n\u003C!-- Dialog: -->\n\u003Cdialog open\n        role=\"dialog\"\n        aria-labelledby=\"confirm-title\"\n        aria-describedby=\"confirm-desc\">\n  \u003Ch2 id=\"confirm-title\">Delete your account?\u003C\u002Fh2>\n  \u003Cp id=\"confirm-desc\">\n    This permanently removes your account, all your projects (12), and your\n    team's access (38 members). This cannot be undone.\n  \u003C\u002Fp>\n  \u003Cp>To confirm, type your account email below:\u003C\u002Fp>\n  \u003Cinput type=\"text\" placeholder=\"you@example.com\" id=\"confirm-input\" \u002F>\n  \u003Cbutton type=\"button\">Cancel\u003C\u002Fbutton>\n  \u003Cbutton type=\"button\"\n          class=\"destructive\"\n          disabled\n          id=\"confirm-button\">\n    Delete account permanently\n  \u003C\u002Fbutton>\n\u003C\u002Fdialog>\n```\n\nThe user must:\n\n1. Click \"Delete account\" (intent).\n2. Read the dialog (consequences laid out).\n3. Type their email (active confirmation, error prevention).\n4. Click \"Delete account permanently\" (final commit).\n\nEach step is a deliberate barrier against accidental destruction.\n\n## Anti-patterns\n\n- **Placeholders as labels.** \"Email\" in placeholder text only — disappears on type, breaks for screen readers, fails on autofill.\n- **Generic error messages.** \"Validation failed.\" Doesn't say which field, doesn't say what's wrong, doesn't say how to fix.\n- **Surprise context changes.** Selecting an option auto-navigates; typing in a field auto-submits. The user loses control.\n- **Inconsistent labels for the same action.** \"Save\" here, \"Submit\" there, \"Confirm\" elsewhere.\n- **No undo and no confirm for destructive actions.** Click-and-it's-gone with no recovery.\n- **Jargon without explanation.** \"API token rotation period\" with no hover or link to explain. The technical user knows; the casual user is lost.\n\n## Heuristics\n\n1. **The five-error test.** Trigger 5 different validation errors. Are all of them named, located near the field, and offered a fix?\n2. **The label audit.** Every form input has a `\u003Clabel>` associated by `for`\u002F`id`. No placeholder-as-label.\n3. **The unexpected-change test.** Walk through a form. Does any change of input value or focus trigger a navigation, popup, or auto-submit? Each is a violation.\n4. **The \"stranger\" test.** Show your form to someone unfamiliar with your product. Can they tell what each field wants without help text? If not, label or instruction is wrong.\n5. **The grade-level check.** Run your microcopy through a readability tool. Above grade 10 for consumer? Simplify.\n\n## Related skills\n\n- **`accessibility`** (parent).\n- **`accessibility-perceivable`**, **`accessibility-operable`**, **`accessibility-robust`** — siblings.\n- **`errors`** and **`forgiveness`** (interaction) — error UX is shared between accessibility and general interaction design.\n- **`feedback-loop`** (interaction) — feedback that the system received a change is part of predictability.\n- **`framing`** (cognition) — error copy framing affects whether the user feels blamed or helped.\n- **`mental-model`** (cognition) — predictable behavior aligns with the user's model.\n","# Accessibility — Understandable\n\nWCAG Principle 3: information and the operation of the user interface must be understandable.\n\nThe three sub-criteria, simplified:\n\n1. **Readable** — language is identified, jargon is explained, abbreviations are expanded.\n2. **Predictable** — the UI behaves consistently and changes context only when the user expects.\n3. **Input assistance** — labels, instructions, error messages, and prevention of mistakes.\n\nThis 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.\n\n## 1. Readable\n\n### Language identified\n\nSet the document language so screen readers pronounce correctly:\n\n```html\n\u003Chtml lang=\"en\">\n```\n\nFor mixed-language content, mark the exception:\n\n```html\n\u003Cp>The French word for \"dog\" is \u003Cspan lang=\"fr\">chien\u003C\u002Fspan>.\u003C\u002Fp>\n```\n\nA screen reader switches voice\u002Fpronunciation for the marked span.\n\n### Plain language\n\nWrite 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.\n\nPractices that improve readability:\n\n- Short sentences (\u003C25 words).\n- Active voice (\"Click Save\" not \"Save can be clicked\").\n- Familiar words (use \"buy\" not \"procure\").\n- One idea per sentence.\n- Paragraphs ≤ 5 sentences.\n\n### Jargon and abbreviations\n\nIf you must use jargon or abbreviations, expand them on first use:\n\n```html\n\u003Cp>\n  Single sign-on (\u003Cabbr title=\"Single Sign-On\">SSO\u003C\u002Fabbr>) lets your team\n  use one login across all tools.\n\u003C\u002Fp>\n```\n\nScreen readers can announce the expansion via `\u003Cabbr title>`. Sighted users see the expansion on hover.\n\nFor specialized terms, link to a definition or glossary the first time.\n\n### Pronunciation (rare but worth knowing)\n\nFor content where pronunciation determines meaning (poetry, languages, certain proper nouns), provide pronunciation hints. Most apps don't need this; mention it for completeness.\n\n## 2. Predictable\n\n### Behavior on focus and input\n\nWCAG 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.\n\nSpecifically:\n\n- A `\u003Cselect>` should not auto-submit a form when a value changes.\n- Focusing an input should not open a popup or navigate.\n- Typing into a search field should not navigate to a result page on every keystroke.\n\nIf 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.\n\n```html\n\u003C!-- Wrong: select auto-submits on change -->\n\u003Cselect onchange=\"this.form.submit()\">\n  \u003Coption>Country A\u003C\u002Foption>\n  \u003Coption>Country B\u003C\u002Foption>\n\u003C\u002Fselect>\n\n\u003C!-- Right: select waits for explicit submit -->\n\u003Cselect name=\"country\">\n  \u003Coption>Country A\u003C\u002Foption>\n  \u003Coption>Country B\u003C\u002Foption>\n\u003C\u002Fselect>\n\u003Cbutton type=\"submit\">Continue\u003C\u002Fbutton>\n```\n\n### Consistent navigation\n\nSame 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.\n\nIf a sub-section needs additional nav, place it in a consistent location (e.g., a left sidebar that always appears in left-sidebar slot).\n\n### Consistent identification\n\nSame 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.\"\n\nSame icon across the app should mean the same thing. A trash icon on one page meaning \"delete,\" another page meaning \"filter,\" is incoherent.\n\n## 3. Input assistance\n\n### Error identification\n\nWCAG 3.3.1: when an error is detected, identify the item in error and describe the error in text.\n\n```html\n\u003Cdiv class=\"field\" data-state=\"error\">\n  \u003Clabel for=\"email\">Email address\u003C\u002Flabel>\n  \u003Cinput id=\"email\"\n         type=\"email\"\n         aria-invalid=\"true\"\n         aria-describedby=\"email-error\" \u002F>\n  \u003Cp id=\"email-error\" class=\"field-error\">\n    \u003CAlertIcon aria-hidden=\"true\" \u002F>\n    Please enter a valid email address (e.g., name@example.com).\n  \u003C\u002Fp>\n\u003C\u002Fdiv>\n```\n\nThree things are happening:\n\n- `aria-invalid=\"true\"` flags the input as in error (assistive tech may announce).\n- `aria-describedby` ties the message to the input (screen readers announce both).\n- The message text is specific (says what's wrong) and actionable (offers an example).\n\n### Labels and instructions\n\nEvery input has a programmatically associated label. The label is descriptive (not just \"Field 1\"). If the input requires specific format, instructions are provided alongside.\n\n```html\n\u003C!-- Right: label, format hint, and example -->\n\u003Cdiv class=\"field\">\n  \u003Clabel for=\"phone\">Phone number\u003C\u002Flabel>\n  \u003Cinput id=\"phone\"\n         type=\"tel\"\n         aria-describedby=\"phone-help\"\n         placeholder=\"555-123-4567\" \u002F>\n  \u003Cp id=\"phone-help\" class=\"field-help\">\n    Format: 555-123-4567. We use this only for delivery questions.\n  \u003C\u002Fp>\n\u003C\u002Fdiv>\n```\n\nNotes:\n\n- `placeholder` is *not* a label — it disappears when the user starts typing. Use a real `\u003Clabel>`.\n- Format hints belong in adjacent text (`aria-describedby`), not just placeholder.\n- Required fields should be marked both visually (asterisk) and programmatically (`required` attribute or `aria-required`).\n\n### Error suggestion\n\nWCAG 3.3.3 (Level AA): when the user makes an input error and the system can suggest a correction, do so.\n\n```html\n\u003C!-- User typed \"gmial.com\" -->\n\u003Cp class=\"field-error\">\n  Did you mean \u003Cbutton type=\"button\" onclick=\"acceptSuggestion('gmail.com')\">name@gmail.com\u003C\u002Fbutton>?\n\u003C\u002Fp>\n```\n\nDon't auto-correct silently — that's a context change without consent. Suggest, let the user accept.\n\n### Error prevention\n\nWCAG 3.3.4 (Level AA, for legal\u002Ffinancial\u002Fdata submissions): the user must be able to:\n\n- **Reverse** the submission (a \"Cancel my order\" period), OR\n- **Check** the submission for errors before final commit (a confirmation page), OR\n- **Confirm** explicitly before final commit (a confirm dialog).\n\nFor 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.\n\n### Help\n\nWCAG 3.3.5 (Level AAA): context-sensitive help is available. Tooltips, inline help, \"What's this?\" links.\n\nIn product UIs, this lands in:\n\n- `\u003CFieldDescription>` next to inputs that need explanation.\n- `?` icons next to settings whose function isn't obvious.\n- A persistent help link or chat in chrome.\n\n### Consistent help\n\nWCAG 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.\n\n## Worked examples\n\n### Example 1: a credit-card form with full input assistance\n\n```html\n\u003Cform>\n  \u003Cdiv class=\"field\">\n    \u003Clabel for=\"cc-number\">Card number\u003C\u002Flabel>\n    \u003Cinput id=\"cc-number\"\n           type=\"text\"\n           inputmode=\"numeric\"\n           autocomplete=\"cc-number\"\n           aria-describedby=\"cc-help\"\n           required\n           aria-required=\"true\" \u002F>\n    \u003Cp id=\"cc-help\" class=\"field-help\">\n      16 digits, no spaces or dashes\n    \u003C\u002Fp>\n  \u003C\u002Fdiv>\n\n  \u003Cdiv class=\"field\">\n    \u003Clabel for=\"cc-exp\">Expiration (MM\u002FYY)\u003C\u002Flabel>\n    \u003Cinput id=\"cc-exp\"\n           type=\"text\"\n           inputmode=\"numeric\"\n           autocomplete=\"cc-exp\"\n           placeholder=\"MM\u002FYY\"\n           required\n           aria-required=\"true\" \u002F>\n  \u003C\u002Fdiv>\n\n  \u003Cdiv class=\"field\">\n    \u003Clabel for=\"cc-cvc\">CVC\u003C\u002Flabel>\n    \u003Cinput id=\"cc-cvc\"\n           type=\"text\"\n           inputmode=\"numeric\"\n           autocomplete=\"cc-csc\"\n           aria-describedby=\"cvc-help\"\n           required\n           aria-required=\"true\" \u002F>\n    \u003Cp id=\"cvc-help\" class=\"field-help\">\n      3-digit code on the back of your card (4 on Amex)\n    \u003C\u002Fp>\n  \u003C\u002Fdiv>\n\n  \u003Cbutton type=\"submit\">Review order\u003C\u002Fbutton>\n\u003C\u002Fform>\n```\n\nWhat's happening:\n\n- Each field has a real label (associated via `for`\u002F`id`).\n- `inputmode=\"numeric\"` prompts the right keyboard on mobile.\n- `autocomplete` attributes let password managers and autofill help.\n- Help text is associated via `aria-describedby`.\n- Required is both visual (probably an asterisk from CSS) and programmatic (`required` + `aria-required`).\n- Submit goes to a \"Review order\" page (error prevention via review step).\n\n### Example 2: a destructive action with prevention layers\n\n```html\n\u003Cbutton onclick=\"openDeleteDialog()\">Delete account\u003C\u002Fbutton>\n\n\u003C!-- Dialog: -->\n\u003Cdialog open\n        role=\"dialog\"\n        aria-labelledby=\"confirm-title\"\n        aria-describedby=\"confirm-desc\">\n  \u003Ch2 id=\"confirm-title\">Delete your account?\u003C\u002Fh2>\n  \u003Cp id=\"confirm-desc\">\n    This permanently removes your account, all your projects (12), and your\n    team's access (38 members). This cannot be undone.\n  \u003C\u002Fp>\n  \u003Cp>To confirm, type your account email below:\u003C\u002Fp>\n  \u003Cinput type=\"text\" placeholder=\"you@example.com\" id=\"confirm-input\" \u002F>\n  \u003Cbutton type=\"button\">Cancel\u003C\u002Fbutton>\n  \u003Cbutton type=\"button\"\n          class=\"destructive\"\n          disabled\n          id=\"confirm-button\">\n    Delete account permanently\n  \u003C\u002Fbutton>\n\u003C\u002Fdialog>\n```\n\nThe user must:\n\n1. Click \"Delete account\" (intent).\n2. Read the dialog (consequences laid out).\n3. Type their email (active confirmation, error prevention).\n4. Click \"Delete account permanently\" (final commit).\n\nEach step is a deliberate barrier against accidental destruction.\n\n## Anti-patterns\n\n- **Placeholders as labels.** \"Email\" in placeholder text only — disappears on type, breaks for screen readers, fails on autofill.\n- **Generic error messages.** \"Validation failed.\" Doesn't say which field, doesn't say what's wrong, doesn't say how to fix.\n- **Surprise context changes.** Selecting an option auto-navigates; typing in a field auto-submits. The user loses control.\n- **Inconsistent labels for the same action.** \"Save\" here, \"Submit\" there, \"Confirm\" elsewhere.\n- **No undo and no confirm for destructive actions.** Click-and-it's-gone with no recovery.\n- **Jargon without explanation.** \"API token rotation period\" with no hover or link to explain. The technical user knows; the casual user is lost.\n\n## Heuristics\n\n1. **The five-error test.** Trigger 5 different validation errors. Are all of them named, located near the field, and offered a fix?\n2. **The label audit.** Every form input has a `\u003Clabel>` associated by `for`\u002F`id`. No placeholder-as-label.\n3. **The unexpected-change test.** Walk through a form. Does any change of input value or focus trigger a navigation, popup, or auto-submit? Each is a violation.\n4. **The \"stranger\" test.** Show your form to someone unfamiliar with your product. Can they tell what each field wants without help text? If not, label or instruction is wrong.\n5. **The grade-level check.** Run your microcopy through a readability tool. Above grade 10 for consumer? Simplify.\n\n## Related skills\n\n- **`accessibility`** (parent).\n- **`accessibility-perceivable`**, **`accessibility-operable`**, **`accessibility-robust`** — siblings.\n- **`errors`** and **`forgiveness`** (interaction) — error UX is shared between accessibility and general interaction design.\n- **`feedback-loop`** (interaction) — feedback that the system received a change is part of predictability.\n- **`framing`** (cognition) — error copy framing affects whether the user feels blamed or helped.\n- **`mental-model`** (cognition) — predictable behavior aligns with the user's model.\n",{"name":5,"description":7},"main","b0f0a87593c578a7898eccaf1b363f7f87c1f99b","plugins\u002FHDeibler\u002Funiversal-design-principles\u002Fplugins\u002Fprocess-and-robustness-principles\u002Fskills\u002Faccessibility-understandable",490,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins","https:\u002F\u002Fhol.org\u002Fplugins\u002Fbest-codex-plugins","https:\u002F\u002Fgithub.com\u002Fhashgraph-online","https:\u002F\u002Fhol.org","Open-source standards and developer tools for interoperable AI agents: discovery, identity, communication, payments, privacy and security.","2026-11-14 02:12:02",{"source":8,"skillName":5,"commands":56,"prompt":66,"zipAvailable":67},[57,60,63],{"tool":58,"command":59},"npx","npx skills add hashgraph-online\u002Fawesome-codex-plugins --skill accessibility-understandable",{"tool":61,"command":62},"bunx","bunx skills add hashgraph-online\u002Fawesome-codex-plugins --skill accessibility-understandable",{"tool":64,"command":65},"pnpm","pnpm dlx skills add hashgraph-online\u002Fawesome-codex-plugins --skill accessibility-understandable","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002FHDeibler\u002Funiversal-design-principles\u002Fplugins\u002Fprocess-and-robustness-principles\u002Fskills\u002Faccessibility-understandable\u002FSKILL.md",true,[69],{"path":70,"resourceType":71,"resourceTypeDesc":72,"sizeBytes":73,"sourceHtmlUrl":74},"references\u002Funderstandable-deep-dive.md","REFERENCE","参考文档",4593,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002FHDeibler\u002Funiversal-design-principles\u002Fplugins\u002Fprocess-and-robustness-principles\u002Fskills\u002Faccessibility-understandable\u002Freferences\u002Funderstandable-deep-dive.md",[76,84,91,98,122,147],{"skillNo":77,"name":78,"nameZh":6,"description":79,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":80,"categories":81,"keywords":82,"publishedAt":83},"01M746ZWACVKMZ1BJXJZHYJSSX","migrate-to-e2e","Moves an existing Playwright, Cypress, Selenium, Appium, Detox, Maestro, or TesterArmy suite to e2e one slice at a time, with the old suite running beside the new one until each ported test is proven. Keeps a MIGRATION.md progress file so any later session resumes where the last stopped. Optionally plants a defect to show both suites catch it. Use for \u002Fmigrate-to-e2e, \"migrate our tests to e2e\", \"port these Maestro flows\", \"move our TesterArmy tests\", or when a project has an e2e config and an older suite still running.","https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Ftester-army\u002Fe2e\u002Fskills\u002Fmigrate-to-e2e\u002FSKILL.md",[],[],"2026-11-11 15:11:14",{"skillNo":85,"name":86,"nameZh":6,"description":87,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":88,"categories":89,"keywords":90,"publishedAt":83},"01M746ZPTAX1Q0FBKAB1CYND7E","e2e","Writes, runs, and debugs end-to-end tests for web and mobile apps with e2e, the agentic test runner, which mixes agent.act goals with exact locator assertions on a Playwright browser or an iOS or Android device. Also drives a project's running app live over the e2e MCP server to look at a screen, check a UI change, take a screenshot or record a video, and try a locator; and runs bug bashes, parallel e2e explore runs with each bug proven by a repro test. Use when a project depends on e2e or has an e2e.config.ts, when asked for end-to-end, browser, mobile, or agentic UI tests, to check a change in the running app, to QA or bug bash an app or branch, or when an e2e run fails.","https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Ftester-army\u002Fe2e\u002Fskills\u002Fe2e\u002FSKILL.md",[],[],{"skillNo":92,"name":93,"nameZh":6,"description":94,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":95,"categories":96,"keywords":97,"publishedAt":83},"01M746ZJN784HVHMDP9MQGCSGG","create-verification-skill","Generate a project-local verify-\u003Capp> skill on top of e2e, so any coding agent can launch the app, check it is worth driving, exercise a feature the way a user does, keep evidence, and bug bash it. Writes the skill, a feature map with one explore charter per feature, and proves it once. Use for \u002Fcreate-verification-skill, \"make a verification skill for this repo\", or when a project has no scripted way to prove UI behavior.","https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Ftester-army\u002Fe2e\u002Fskills\u002Fcreate-verification-skill\u002FSKILL.md",[],[],{"skillNo":99,"name":100,"nameZh":6,"description":101,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":102,"categories":103,"keywords":104,"publishedAt":40},"01M716A6ETNB9B1SQ3GXZC75VR","deja-search","deja-vu memory — search the user's past AI coding sessions with the deja CLI. Holds what they already settled and never wrote into the repo (naming rules, banned or already-tried tools, required checks before merge, preferred values, who owns what). Use before your first edit in a task, before you call a change done or ready to merge, before you recommend a tool, library, design or reviewer, before re-debugging an error that may already be solved, when they say 'didn't we fix this before', 'what did we decide about X' or 'I already have that', and before telling them something on this machine does not exist.","https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Fvshulcz\u002Fdeja-vu\u002Fskills\u002Fdeja-search\u002FSKILL.md",[],[105,106,107,30,108,109,110,111,112,113,114,21,26,115,116,117,118,119,120,121],"search","deja search","never","ready","memory","re","decide","fix","design","debugging","done","reviewer","io","change","cli","merge","past",{"skillNo":123,"name":124,"nameZh":6,"description":125,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":126,"categories":127,"keywords":128,"publishedAt":40},"01M716A3J2W5SENSE9VGMXB375","deja-reflect","End-of-session reflection and memory curation with deja-vu. Review what was decided, what commands broke and what repaired them, and record durable project rules or decisions with deja remember so the next session starts with them.","https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Fvshulcz\u002Fdeja-vu\u002Fskills\u002Fdeja-reflect\u002FSKILL.md",[],[129,130,131,117,132,133,134,135,136,137,138,139,140,141,109,142,143,144,145,146],"deja reflect","reflect","review","with","record","github","next","https","node","Rules","decisions","brew","remember","project rules","project","session","end","reflection",{"skillNo":148,"name":149,"nameZh":6,"description":150,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":151,"categories":152,"keywords":164,"publishedAt":40},"01M715T3RR4BAYSR57HPPTJ0PF","revid","Make, edit, export and post AI videos with Revid (revid.ai) through the Revid MCP server. Use whenever the user wants a short-form or long-form video made (from an idea, a script, a URL, an article, a PDF, a tweet, a product page, their own clips, or a song), wants to find what is going viral on TikTok, YouTube, Instagram or X before making something, wants to edit or re-export an existing Revid project, generate a standalone AI image or clip, make a series episode, or publish and schedule a finished video to connected social accounts. Covers setup (hosted MCP with OAuth, or an API key), the 36 tools, credits, polling and the rules for publishing. Routes to the more specific revid-* skills when one fits.","https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Ftmakersas\u002Frevid-skills\u002Fskills\u002Frevid\u002FSKILL.md",[153,158,161],{"categoryNo":154,"categoryName":155,"taxonomyType":156,"taxonomyTypeDesc":157},"01JBSEEDCAT000000000000016","图像与多媒体","SCENARIO","使用场景",{"categoryNo":159,"categoryName":160,"taxonomyType":156,"taxonomyTypeDesc":157},"01JBSEEDCAT000000000000023","Skill与智能体开发",{"categoryNo":162,"categoryName":163,"taxonomyType":156,"taxonomyTypeDesc":157},"01JBSEEDCAT000000000000010","后端与接口",[149,165,166,167,168,169,170,143,171,110,172,173,174,175,21,176,177,178,179,180],"URL","Video","short-form","standalone","PDF","viral","tiktok","short","social","MCP","song","image","mcp server","schedule","api","publish"]