Accessible UX writing ensures everyone—including people using screen readers, experiencing cognitive differences, or facing situational limitations—can understand and use your product.Documentation Index
Fetch the complete documentation index at: https://content-designer-ux-writing-skill-26.mintlify.app/llms.txt
Use this file to discover all available pages before exploring further.
Core principles (WCAG for writers)
The Web Content Accessibility Guidelines (WCAG) define four principles that apply to UX writing:Perceivable
Users must be able to perceive the information.For writers:
- Don’t rely on color alone
- Provide text for all interactive elements
- Write descriptive labels
Operable
Users must be able to operate the interface.For writers:
- Write clear button labels
- Use descriptive link text
- Provide skip navigation
Understandable
Users must understand the information.For writers:
- Use plain language
- Keep sentences short
- Define technical terms
Robust
Content works with assistive tech.For writers:
- Label form fields properly
- Structure with clear headings
- Associate errors with fields
Screen reader optimization
How screen readers work
Screen readers announce content linearly, reading:- Element type (button, link, heading, form field)
- Label or text content
- State (required, selected, expanded)
Write for screen readers
Label all interactive elements
Every button, link, and field needs descriptive text.
- Good: “Submit application” (button)
- Avoid: “Submit” (ambiguous without context)
Make links descriptive
Links should make sense out of context.
- Good: “Read our privacy policy”
- Avoid: “Click here for more information”
Screen reader users often navigate by pulling up a list of all links. “Click here” repeated 10 times is useless.
Write explicit error messages
Errors must be programmatically associated with fields.
- Good: “Error: Email must include @”
- Avoid: Red text without “Error:” prefix
Cognitive accessibility
People process information differently. Writing for cognitive accessibility helps everyone.Sentence length targets
Research shows comprehension drops with sentence length:8 words
100% comprehensionIdeal for critical information
14 words
90% comprehensionGood for most UX text
25+ words
Comprehension dropsAvoid for important content
Break dense text into chunks
- Before
- After
“Password must contain at least 8 characters including uppercase letters, lowercase letters, numbers and special characters.”Problems:
- 17 words in one sentence
- Dense list hard to scan
- Difficult to remember
Use clear headings
Headings help users scan and navigate:Use descriptive headings (not “Overview” for everything)
Follow a logical hierarchy (H1 → H2 → H3)
Make headings specific (“Password requirements” not “Requirements”)
Don’t skip heading levels (H1 → H3 skips H2)
Plain language
Reading level guidelines
- General audience
- Professional tools
- Technical products
Target: 7th-8th grade reading levelTools: Hemingway Editor, Readable.comExample:
- Good: “We’ll send you a confirmation email”
- Avoid: “A confirmation will be dispatched to your email address”
Define technical terms
When you must use technical terms, define them on first use:Example: API documentation
Example: API documentation
“Use a webhook (automated message sent when an event occurs) to receive real-time updates.”First mention includes brief definition in parentheses.
Avoid idioms and metaphors
Idioms don’t translate well and confuse non-native speakers:| Avoid | Use instead |
|---|---|
| ”Let’s touch base next week" | "Let’s check in next week" |
| "It’s a piece of cake" | "It’s easy" |
| "We’re in the same boat" | "We’re in the same situation" |
| "Hit the ground running" | "Start immediately” |
Multi-modal communication
Don’t rely on a single sense to convey information.Don’t rely on color alone
- Error indicators
- Status indicators
- Required fields
Bad: Red textGood: Red text + error icon + “Error:” prefix
Provide text alternatives
Icons
Always pair icons with text labels or use aria-label.Good: 🔍 SearchAvoid: 🔍 (icon only)
Images
Write descriptive alt text for meaningful images.Good: “Bar chart showing 40% increase in sales”Avoid: “Chart” or “Image”
Accessible patterns
Buttons
Context in label
Context in label
Bad: “Delete” (delete what?)Good: “Delete account”Why: Screen readers read the button label out of context. “Delete” alone doesn’t say what’s being deleted.
Links
Descriptive link text
Descriptive link text
Bad: “Click here to read our privacy policy”Good: “Read our privacy policy”Why: “Click here” is meaningless when screen reader lists all links. The link text should describe the destination.
Error messages
Error prefix and association
Error prefix and association
Bad: Red text saying “Invalid”Good: “Error: Email must include @” (programmatically associated with email field)Why:
- “Error:” prefix alerts screen readers
- Specific message explains the problem
- Association ensures screen reader announces error with field label
Form labels
Visible, permanent labels
Visible, permanent labels
Bad: Placeholder text only (“Enter your email”)Good: Visible label “Email address” + optional placeholder “name@example.com”Why: Placeholders disappear when typing and aren’t reliably read by screen readers.
High-stress contexts
Accessibility becomes critical in stressful situations:Error recovery
When users are frustrated, clarity is essential:- Use the shortest possible sentences
- Lead with the solution, not the problem
- Avoid technical language
- Good: “Connection lost. Check your internet and refresh.”
- Avoid: “ERR_NETWORK_TIMEOUT: The server failed to respond within the allocated time frame.”
Time pressure
When users need to act quickly:- Front-load critical information
- Use strong visual hierarchy
- Provide clear next actions
- Good: “Session expiring in 2 minutes. Stay logged in?”
- Avoid: “Your session will expire soon due to inactivity. If you would like to remain logged in, please click the button below.”
Testing for accessibility
Use a screen reader
Test your content with:
- NVDA (Windows, free)
- JAWS (Windows, paid)
- VoiceOver (Mac/iOS, built-in)
- TalkBack (Android, built-in)
Check reading level
Use tools to verify plain language:
- Hemingway Editor
- Readable.com
- Microsoft Word (Review → Readability Statistics)
Quick accessibility checklist
Every interactive element has descriptive text
Links describe destination (no “click here”)
Errors include “Error:” prefix
Form fields have visible labels (not just placeholders)
Color is paired with text or icons
Critical content under 14 words per sentence
Reading level appropriate for audience (7th-10th grade)
Technical terms defined on first use
Headings follow logical hierarchy
Icons have text labels or aria-labels
Related resources
Buttons and links
Write accessible buttons and links
Error messages
Create accessible error messages
Form fields
Write accessible form labels