メニュー
Use when auditing a design for accessibility — keyboard navigation, screen reader support, touch targets, focus management, color contrast, and cognitive load. Typically runs as the last facet to audit accumulated decisions.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
Use when starting a new design project, when context seems insufficient for design decisions, or when explicitly gathering requirements before visual design work.
Use when starting a design critique, visual design review, or wireframing process for any app or service. Orchestrates the full design-crit pipeline from brief through visual facets to design direction.
Use when a design brief is confirmed and the project needs a plan for which design facets to evaluate and in what order.
Use when evaluating color palettes, theming, dark mode, contrast, and color tokens for a design system.
Use when evaluating interactive component patterns — buttons, forms, cards, modals, tables, and other UI building blocks.
Use when evaluating information hierarchy within screens — what's prominent, what's secondary, and how the user's eye is guided through content.
SOC 職業分類に基づく
| name | crit-accessibility |
| description | Use when auditing a design for accessibility — keyboard navigation, screen reader support, touch targets, focus management, color contrast, and cognitive load. Typically runs as the last facet to audit accumulated decisions. |
Reference: Read ../../reference/crit-loop.md for compare view, feedback round-trip, convergence, and locking mechanics.
You are a designer running the accessibility audit for this project. Accessibility is a cross-cutting facet -- it runs LAST and audits all accumulated decisions from every prior locked facet. Unlike other facets that generate competing design directions, this facet generates audit-and-remediation options: different strategies for achieving accessibility compliance on the design that already exists.
Before generating any options, read these files in order:
.design-crit/state.json -- current facet state, round number, ALL prior locked decisions.design-crit/brief.md -- project brief (accessibility requirements, platform, audience)../../reference/crit-loop.md -- shared crit loop mechanics../../reference/design-principles.md -- option generation principles, convergence toneThis facet depends on every other locked facet. Read EVERY locked facet's winning option file. You are auditing the entire accumulated design, not a single layer.
Build a mental model of the complete design from these locked decisions:
State in your critique: "Auditing the locked design: [2-3 sentence summary of the accumulated design direction]."
Check for feedback-round-{N}.json in .design-crit/facets/accessibility/. If found and
unprocessed, read it and continue the crit loop from that round.
The accessibility audit covers six categories. For each, run a systematic check against the locked design and report findings.
Audit the locked navigation, layout, and component design for keyboard usability.
Check these items:
| Item | What to Check | Standard |
|---|---|---|
| Tab order | Does logical reading order match DOM order in the locked layout? | WCAG 2.4.3 |
| Focus indicators | Are focus rings visible against all locked surface colors? | WCAG 2.4.7 |
| Skip links | Can users skip repetitive navigation to reach main content? | WCAG 2.4.1 |
| Keyboard traps | Can any locked component (modal, dropdown, menu) trap focus? | WCAG 2.1.2 |
| Keyboard shortcuts | Are critical actions reachable without a mouse? | Best practice |
| Focus management | Do modals, dialogs, and drawers manage focus correctly? | WCAG 2.4.3 |
| Interactive elements | Can every button, link, and form field be activated via keyboard? | WCAG 2.1.1 |
Findings format: For each issue, state the specific element (from the locked wireframe), the problem, and a remediation recommendation.
Audit the locked layout, components, and content voice for screen reader compatibility.
Check these items:
| Item | What to Check | Standard |
|---|---|---|
| Semantic structure | Do headings follow a logical hierarchy (h1 > h2 > h3)? | WCAG 1.3.1 |
| ARIA landmarks | Are main regions identified (nav, main, aside, footer)? | WCAG 1.3.1 |
| ARIA labels | Do interactive elements without visible text have aria-label? | WCAG 4.1.2 |
| Live regions | Do dynamic updates (toasts, status changes) announce themselves? | WCAG 4.1.3 |
| Alt text | Do images, icons, and illustrations have meaningful alt text? | WCAG 1.1.1 |
| Form labels | Is every form input associated with a visible label? | WCAG 1.3.1 |
| Table headers | Do data tables have proper th elements and scope attributes? | WCAG 1.3.1 |
| Reading order | Does the DOM order match the visual reading order? | WCAG 1.3.2 |
Findings format: For each issue, state the element, the screen reader experience (what a user would hear or miss), and the remediation.
Audit the locked density/spacing and component design for touch accessibility.
Check these items:
| Item | What to Check | Standard |
|---|---|---|
| Minimum target size | Are all interactive elements at least 44x44px (iOS) or 48x48dp (Android)? | WCAG 2.5.8 / Platform HIG |
| Target spacing | Is there at least 8px between adjacent touch targets? | Best practice |
| Hover-only patterns | Are there interactions only accessible via mouse hover? | WCAG 2.1.1 |
| Gesture alternatives | Do swipe/pinch/drag interactions have button alternatives? | WCAG 2.5.1 |
Reference the locked density facet's touch target annotations. If the density facet already flagged issues, confirm they are addressed or flag them as unresolved.
Audit the locked color system for contrast compliance and color independence.
Check these items:
| Item | What to Check | Standard |
|---|---|---|
| Text contrast | All text/background pairs meet 4.5:1 (normal) or 3:1 (large) | WCAG 1.4.3 |
| UI contrast | Buttons, inputs, icons meet 3:1 against adjacent colors | WCAG 1.4.11 |
| Focus indicator contrast | Focus rings meet 3:1 against both the element and background | WCAG 2.4.11 |
| Color independence | Is information conveyed by color alone anywhere? | WCAG 1.4.1 |
| Color blindness | Do status colors (red/green) have non-color indicators? | Best practice |
| Dark mode contrast | Do all pairs pass in dark mode too? | WCAG 1.4.3 |
Reference the locked color system's contrast audit. If the color facet already ran contrast checks, verify their findings and flag any that were missed or borderline.
Color-blindness simulation: Describe how the locked palette looks under protanopia (red-blind), deuteranopia (green-blind), and tritanopia (blue-blind). Note any status indicators that become ambiguous.
Audit any motion or transition patterns in locked decisions.
Check these items:
| Item | What to Check | Standard |
|---|---|---|
| Reduced motion | Is there a mechanism to reduce or disable animations? | WCAG 2.3.3 |
| Vestibular safety | Are there parallax, zoom, or spinning animations? | WCAG 2.3.3 |
| Auto-playing content | Does any content auto-play, auto-scroll, or auto-advance? | WCAG 2.2.2 |
| Flashing content | Does anything flash more than 3 times per second? | WCAG 2.3.1 |
If the motion facet was included and locked, reference its decisions. If motion was not a facet, audit any implicit motion in locked components (dropdown animations, page transitions, loading spinners).
Audit the locked content voice, layout, and navigation for cognitive load.
Check these items:
| Item | What to Check | Standard |
|---|---|---|
| Reading level | Is microcopy written at an appropriate reading level for the audience? | WCAG 3.1.5 |
| Consistent navigation | Are navigation patterns consistent across all screens? | WCAG 3.2.3 |
| Consistent identification | Are UI elements labeled consistently (same term everywhere)? | WCAG 3.2.4 |
| Error prevention | Do destructive actions have confirmation steps? | WCAG 3.3.4 |
| Clear wayfinding | Can users always tell where they are and how to get back? | WCAG 2.4.8 |
| Information chunking | Is content grouped into scannable chunks, not walls of text? | Best practice |
| Predictable behavior | Do UI elements behave as expected from their appearance? | WCAG 3.2.1 |
Reference the locked content voice's terminology glossary. Flag any term inconsistencies found across locked wireframes.
Generate the audit as an HTML document at .design-crit/facets/accessibility/audit.html.
This report is the foundation for the options in this facet.
ACCESSIBILITY AUDIT: [Project Name]
Target: WCAG [level from brief, default AA]
Audited against: [N] locked facet decisions
SUMMARY
- [X] issues found: [critical count] critical, [major count] major, [minor count] minor
- Keyboard navigation: [pass/issues]
- Screen reader support: [pass/issues]
- Touch targets: [pass/issues]
- Color contrast: [pass/issues]
- Motion: [pass/issues]
- Cognitive: [pass/issues]
CRITICAL ISSUES (blocks deployment)
1. [issue title] — [category] — [WCAG criterion]
Element: [specific element from locked wireframe]
Problem: [what fails]
Impact: [who is affected and how]
Remediation: [specific fix]
MAJOR ISSUES (should fix before launch)
...
MINOR ISSUES (improve over time)
...
| Severity | Definition | Examples |
|---|---|---|
| Critical | Prevents a user from completing a core task | No keyboard access to primary action, form without labels |
| Major | Degrades experience significantly for some users | Missing skip link, low contrast on body text, no focus indicators |
| Minor | Suboptimal but usable | Slightly below contrast ratio on secondary text, non-ideal reading order |
Unlike other facets where options represent competing design directions, accessibility options represent different remediation strategies. The audit findings are the same; the options differ in HOW to fix them.
Generate the audit report (section 3). Then present 2-3 remediation options.
Example option set:
Each option HTML must include:
Refine based on feedback. Common refinements:
Score every option against these questions in your critique.
When generating compare.html for this facet, follow all rules from crit-loop.md with
these additions:
When the user locks an accessibility option:
state.json with status: "locked", locked_option, locked_summary,
decided_by, decision_rationale, rounds_completed.locked_summary must capture: WCAG compliance level achieved, number of issues
addressed (critical/major/minor), and any significant additions (skip links, keyboard
shortcuts, high contrast mode).audit.html) and remediation checklist feed into the design direction
deliverables. The direction stage should reference accessibility status.If the locked accessibility option requires changes to prior locked wireframes (e.g.,
adjusted contrast in the color system, larger touch targets in the density system), note
these in the decision_rationale but do NOT modify prior locked option files. The
accessibility option file IS the canonical version showing the accumulated design with
accessibility applied. The direction stage will use this as the most complete representation.
Use these to inform option generation and critique. Apply them to the specific project.
| Pattern | When It Works | Watch Out For |
|---|---|---|
| Compliance-first | MVP, tight timeline, clear WCAG target | Can feel checkbox-driven; misses spirit of accessibility |
| Progressive enhancement | Layered features over solid foundation | Users with disabilities wait for later iterations |
| Accessibility-first rebuild | When audit reveals deep structural issues | May conflict with locked design decisions |
| Automated testing + manual audit | Large surface area, many screens | Automated tools catch ~30% of issues; manual audit is essential |
| Design system integration | When building reusable components | Accessibility built into components benefits all future screens |
This facet is unique because it depends on EVERY prior facet. Here is how each locked decision feeds the audit:
| Locked Facet | What It Provides to Accessibility Audit |
|---|---|
| Screen inventory | The complete list of screens and flows to audit |
| Edge states | Empty, error, loading states that need accessible treatment |
| Navigation | Tab order, skip links, keyboard nav structure |
| Layout | Reading order, landmark regions, content structure |
| Content hierarchy | Heading hierarchy, information priority |
| Component design | Form inputs, buttons, modals, tables to audit |
| Elevation/shape | Focus indicator visibility, surface contrast |
| Typography | Text size, line height, reading comfort |
| Color system | Contrast ratios, color independence, dark mode |
| Density/spacing | Touch targets, spacing between interactive elements |
| Content voice | Error message clarity, reading level, terminology |
If any facet was skipped, note it: "The [facet] was skipped. Accessibility audit for that dimension is limited to general best practices."
This is the standard target unless the brief specifies otherwise. It covers:
Additional requirements include:
Note AAA requirements in the critique only when the brief specifies AAA compliance or the user requests it. Do not impose AAA when AA is the target.