菜单
Use when building UI that ships to users, when reviewing for WCAG AA compliance, when adding keyboard navigation, when ensuring screen reader support, when auditing color contrast, or when preparing a UI surface for an EU or government customer.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Use when implementing features or fixing bugs test-first, when user mentions "red-green-refactor", when test discipline is required for a specific task, when incremental-implementation needs TDD enforcement, or when a behavior change needs a failing test before any code is written.
Use when .forge/prd.md exists and the system needs a structural design before task breakdown, when modules will be implemented in parallel and need interface contracts to prevent integration failures, or when non-obvious technical decisions need to be recorded for future reference.
Use when .forge/prd.md and .forge/architecture.md exist and the work needs to be decomposed before implementation, when sizing tasks for a sprint, when mapping dependencies between modules, or when a critical path needs to be identified before parallel work begins.
Use when user wants to write a spec, create a PRD, or plan a new feature before implementation begins, when .forge/idea-brief.md exists and is ready to formalize, when requirements need to be captured before architecture or planning, or when a feature's scope and acceptance criteria need to be documented.
Use when creating a new forge-skill, editing an existing skill, when planning to contribute to forge-skills, when a session has produced a one-off prompt that should be promoted to a skill, or when verifying a skill works before deployment.
Use when checking if .forge/ artifacts are stale after a change to requirements, architecture, or any upstream artifact. Use before running /build, /review, or /ship to confirm the artifact chain is consistent. Use when the user says "is anything out of date" or "what needs to be regenerated".
| name | accessibility |
| description | Use when building UI that ships to users, when reviewing for WCAG AA compliance, when adding keyboard navigation, when ensuring screen reader support, when auditing color contrast, or when preparing a UI surface for an EU or government customer. |
Establish WCAG AA as the baseline floor for every UI surface — before it ships. Output is .forge/accessibility.md — the semantic-HTML rules, the ARIA usage policy, keyboard navigation requirements, focus management rules, contrast policy, reduced-motion respect, and the screen-reader testing checklist. Pairs with design-system (which defines the visual tokens that meet contrast) and interaction-patterns (which defines the keyboard and focus contract).
| Thought | Reality |
|---|---|
| "Accessibility is a nice-to-have" | It's a legal requirement in most markets (ADA in US, EAA in EU, AODA in Canada) and a usability requirement everywhere. |
| "We'll add it later" | Retrofitting a11y costs 10x building it in. Every component pattern picked without a11y becomes a refactor. |
| "Our users don't need it" | You don't know that — assistive tech use is often invisible. ~20% of users have a disability in some form. |
| "ARIA fixes everything" | ARIA overuse is worse than no ARIA. Native semantic HTML always beats <div role="button">. |
| "Just make the visible thing look right" | Screen readers see structure, not pixels. A visually-correct page can be unusable with VoiceOver. |
| "Color is enough to signal state" | Colorblind users can't see red-vs-green; every meaningful color needs a text or icon backup. |
<div onClick={...}> instead of <button> (not keyboard accessible by default)<button role="button"> is a smell)outline: none on a focusable element with no replacement focus-visible styleEsc<input> without a <label> (or aria-label for icon-only)prefers-reduced-motion<h1> followed by <h3> with no <h2>)alt (or alt="" for non-decorative images)In .forge/accessibility.md, declare the conformance target (AA at minimum for most products; AAA only where regulatory). Document which assistive technologies are tested against:
The rule: prefer native elements over ARIA every time.
| Use | Not |
|---|---|
<button> | <div role="button"> |
<a href> | <div onClick={navigate}> |
<input type="checkbox"> | <div role="checkbox"> |
<dialog> or <div role="dialog"> with focus trap and labelling | <div className="modal"> |
<nav>, <main>, <aside>, <header>, <footer> | <div> everywhere |
<ul>/<li> for lists | A pile of <div>s |
Run a structural audit: every interactive element is a native interactive element, or has a documented reason it isn't.
The rules for ARIA:
aria-label lies to screen readers.aria-live), to label icon-only buttons (aria-label), to associate hint text (aria-describedby), to wire combobox/listbox patterns that have no native equivalent.<button role="button"> is a smell.For every interactive element and every page:
Esc closes any modal, drawer, popover, command paletteEnter and Space both activate buttons; Enter activates linksCross-reference interaction-patterns for the canonical keyboard contract.
Audit every token pairing in design-system — every text/background combination meets AA. Document the contrast ratio next to each token.
prefers-reduced-motionprefers-reduced-motion: reduce is setFor every UI surface before it ships:
role="alert" or live region)aria-busy + aria-live="polite")alt (decorative = empty alt="").forge/accessibility.md written with the conformance target<div onClick> in the codebase (grep-verified)aria-label)outline: none without a focus-visible replacementprefers-reduced-motion is respected (verified in a test or storybook)