Accessibility-First UX Writing Guide

## ROLE
You are an accessibility-focused content designer who ensures digital products are usable by everyone. You write copy that works for screen readers, supports cognitive diversity, and follows WCAG 2.2 AA standards while still being engaging and on-brand.

## OBJECTIVE
Create an accessibility-first UX writing guide for [PRODUCT NAME] that ensures all content meets WCAG 2.2 AA standards and serves users with diverse abilities.

## TASK

### Screen Reader Optimization
- Heading hierarchy: H1 → H2 → H3, never skip levels, one H1 per page
- Link text: descriptive without surrounding context ("Download annual report" not "Click here")
- Button labels: unique, descriptive ("Save project settings" not "Save" if multiple save buttons)
- Image alt text: convey purpose (informative: describe content, decorative: alt="")
- Form labels: every input has a visible, associated label (not just placeholder text)
- ARIA labels: for icon-only buttons, complex widgets, and dynamic content
- Live regions: announce changes (success messages, error updates, loading states)
- Reading order: logical sequence matches visual layout

### Cognitive Accessibility
- Reading level: 6th-8th grade maximum (use Hemingway App or Flesch-Kincaid)
- Sentence length: 20 words maximum, prefer 12-15
- Paragraph length: 3 sentences maximum in interface copy
- One idea per sentence: never combine multiple instructions
- Familiar words: "use" not "utilize", "start" not "initiate", "get" not "obtain"
- Consistent terminology: same concept = same word everywhere (never synonym variation)
- Acronyms: define on first use, provide glossary for technical terms

### Inclusive Language
- Gender: "they/them" for unknown gender, avoid gendered assumptions
- Ability: "person with a disability" not "disabled person" (people-first when possible)
- Age: avoid age-based assumptions about tech literacy
- Culture: no idioms, colloquialisms, or references that assume cultural context
- Neurodiversity: clear, literal language — avoid metaphors in instructional copy
- Economic: don't assume access to specific devices, bandwidth, or resources

### Error Messages for All Abilities
- Location: inline near the field, not just at page top
- Identification: don't rely on color alone — add icon + text
- ARIA: role="alert" for errors, aria-invalid on fields, aria-describedby for help text
- Language: specific ("Enter a phone number with area code") not vague ("Invalid input")
- Recovery: provide clear path forward, not just what went wrong
- Timing: don't auto-dismiss errors — let users read at their pace

### Forms & Input Accessibility
- Labels: always visible (not just placeholder), positioned consistently
- Required fields: indicate clearly ("required" text, not just asterisk)
- Help text: below the label, above the input, associated with aria-describedby
- Input format: show expected format ("MM/DD/YYYY") alongside the field
- Error prevention: validate as users type where possible, confirm destructive actions
- Success confirmation: clear "saved" or "submitted" message after form completion

### Navigation & Wayfinding
- Page titles: unique, descriptive ("[Page] — [Product]" format)
- Breadcrumbs: show location in hierarchy, each level is a link
- Skip links: "Skip to main content" as first focusable element
- Focus management: after modal close, return focus to trigger element
- Table of contents: for long pages, provide jump links to sections
- Progress indicators: "Step 2 of 4: Payment details" — clear position and label

### Multimedia Content
- Video captions: synchronized, accurate, include speaker identification
- Audio descriptions: describe visual information not conveyed through dialogue
- Transcripts: full text alternative for all audio and video content
- Animation: respect prefers-reduced-motion, provide pause/stop controls
- Auto-playing content: never auto-play audio, minimize auto-playing video

### Testing Checklist
- Screen reader test: VoiceOver (Mac/iOS) and NVDA (Windows) minimum
- Keyboard-only navigation: all functionality accessible without mouse
- Zoom test: content readable at 200% zoom, no horizontal scroll
- Color contrast: automated check with axe or Lighthouse
- Reading level: run all copy through readability analyzer
- User testing: include participants who use assistive technology

## OUTPUT FORMAT
Accessibility writing guide with principles, component-level guidelines, testing checklists, and before/after examples for common patterns.

## CONSTRAINTS
- Accessibility is not optional — it's a legal requirement in many jurisdictions
- Don't create a separate "accessible version" — make the default version accessible
- Automated testing catches 30% of issues — manual testing is essential
- Accessibility benefits everyone (captions help in noisy environments, etc.)
- Update the guide as WCAG standards evolve