Accessibility in UX writing

Write inclusive content that works for all users, including those using assistive technology

Accessible UX writing ensures everyone—including people using screen readers, experiencing cognitive differences, or facing situational limitations—can understand and use your product.

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:

1. Element type (button, link, heading, form field)
2. Label or text content
3. State (required, selected, expanded)

Write for screen readers

1. Label all interactive elements

   Every button, link, and field needs descriptive text.

   • Good: “Submit application” (button)
   • Avoid: “Submit” (ambiguous without context)
2. 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.

3. Write explicit error messages

   Errors must be programmatically associated with fields.

   • Good: “Error: Email must include @”
   • Avoid: Red text without “Error:” prefix
4. Use ARIA labels when needed

   When visual context isn’t available in text, add ARIA labels.

   <button aria-label="Close dialog">×</button>
   

   Without the aria-label, screen readers would just say “Button, times.”

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% comprehension

Ideal for critical information

14 words

90% comprehension

Good for most UX text

25+ words

Comprehension drops

Avoid for important content

Break dense text into chunks

Before

“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

After

“Create a strong password (8+ characters)”

“Use a mix of letters, numbers, and symbols”

Why it’s better:

• Two short lines (6 and 8 words)
• Scannable
• Easy to parse

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

Target: 7th-8th grade reading level

Tools: Hemingway Editor, Readable.com

Example:

• Good: “We’ll send you a confirmation email”
• Avoid: “A confirmation will be dispatched to your email address”

Professional tools

Target: 9th-10th grade reading level

Example:

• Good: “Set up automated workflows”
• Avoid: “Configure autonomous procedural automations”

Technical products

Target: 10th-11th grade (only when necessary)

Example:

• Good: “Deploy to production environment”
• Still prefer: “Deploy to production” (simpler)

Define technical terms

When you must use technical terms, define them on first use:

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

Color blindness affects about 8% of men and 0.5% of women. Always pair color with text or icons.

Error indicators

Bad: Red text

Good: Red text + error icon + “Error:” prefix

❌ Error: Email must include @

Status indicators

Bad: Green dot for online, red dot for offline

Good: Green dot + “Online” or red dot + “Offline”

Required fields

Bad: Red asterisk only

Good: Red asterisk + “required” label or legend

Provide text alternatives

Icons

Always pair icons with text labels or use aria-label.

Good: 🔍 Search

Avoid: 🔍 (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

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

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

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

Bad: Placeholder text only (“Enter your email”)

Good: Visible label “Email address” + optional placeholder “[e-mail]”

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

Example:

• 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

Example: Session timeout warning

• 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

1. Use a screen reader

   Test your content with:

   • NVDA (Windows, free)
   • JAWS (Windows, paid)
   • VoiceOver (Mac/iOS, built-in)
   • TalkBack (Android, built-in)
2. Check reading level

   Use tools to verify plain language:

   • Hemingway Editor
   • Readable.com
   • Microsoft Word (Review → Readability Statistics)
3. Remove color

   View your interface in grayscale to ensure color isn’t the only indicator.

4. Test with users

   Include people with disabilities in user testing whenever possible.

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