> ## Documentation Index
> Fetch the complete documentation index at: https://content-designer-ux-writing-skill-26.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

# 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:

<CardGroup cols={2}>
  <Card title="Perceivable" icon="eye">
    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
  </Card>

  <Card title="Operable" icon="hand-pointer">
    Users must be able to operate the interface.

    **For writers**:

    * Write clear button labels
    * Use descriptive link text
    * Provide skip navigation
  </Card>

  <Card title="Understandable" icon="book">
    Users must understand the information.

    **For writers**:

    * Use plain language
    * Keep sentences short
    * Define technical terms
  </Card>

  <Card title="Robust" icon="gears">
    Content works with assistive tech.

    **For writers**:

    * Label form fields properly
    * Structure with clear headings
    * Associate errors with fields
  </Card>
</CardGroup>

## 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

<Steps>
  <Step title="Label all interactive elements">
    Every button, link, and field needs descriptive text.

    * **Good**: "Submit application" (button)
    * **Avoid**: "Submit" (ambiguous without context)
  </Step>

  <Step title="Make links descriptive">
    Links should make sense out of context.

    * **Good**: "Read our privacy policy"
    * **Avoid**: "Click here for more information"

    <Note>
      Screen reader users often navigate by pulling up a list of all links. "Click here" repeated 10 times is useless.
    </Note>
  </Step>

  <Step title="Write explicit error messages">
    Errors must be programmatically associated with fields.

    * **Good**: "Error: Email must include @"
    * **Avoid**: Red text without "Error:" prefix
  </Step>

  <Step title="Use ARIA labels when needed">
    When visual context isn't available in text, add ARIA labels.

    ```html theme={null}
    <button aria-label="Close dialog">×</button>
    ```

    Without the aria-label, screen readers would just say "Button, times."
  </Step>
</Steps>

## Cognitive accessibility

People process information differently. Writing for cognitive accessibility helps everyone.

### Sentence length targets

Research shows comprehension drops with sentence length:

<CardGroup cols={3}>
  <Card title="8 words" icon="star">
    **100% comprehension**

    Ideal for critical information
  </Card>

  <Card title="14 words" icon="check">
    **90% comprehension**

    Good for most UX text
  </Card>

  <Card title="25+ words" icon="triangle-exclamation">
    **Comprehension drops**

    Avoid for important content
  </Card>
</CardGroup>

### Break dense text into chunks

<Tabs>
  <Tab title="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
  </Tab>

  <Tab title="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
  </Tab>
</Tabs>

### Use clear headings

Headings help users scan and navigate:

<Check>Use descriptive headings (not "Overview" for everything)</Check>
<Check>Follow a logical hierarchy (H1 → H2 → H3)</Check>
<Check>Make headings specific ("Password requirements" not "Requirements")</Check>
<Check>Don't skip heading levels (H1 → H3 skips H2)</Check>

## Plain language

### Reading level guidelines

<Tabs>
  <Tab title="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"
  </Tab>

  <Tab title="Professional tools">
    **Target**: 9th-10th grade reading level

    **Example**:

    * **Good**: "Set up automated workflows"
    * **Avoid**: "Configure autonomous procedural automations"
  </Tab>

  <Tab title="Technical products">
    **Target**: 10th-11th grade (only when necessary)

    **Example**:

    * **Good**: "Deploy to production environment"
    * **Still prefer**: "Deploy to production" (simpler)
  </Tab>
</Tabs>

### Define technical terms

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

<Accordion title="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.
</Accordion>

### 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

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

<Tabs>
  <Tab title="Error indicators">
    **Bad**: Red text

    **Good**: Red text + error icon + "Error:" prefix

    ```
    ❌ Error: Email must include @
    ```
  </Tab>

  <Tab title="Status indicators">
    **Bad**: Green dot for online, red dot for offline

    **Good**: Green dot + "Online" or red dot + "Offline"
  </Tab>

  <Tab title="Required fields">
    **Bad**: Red asterisk only

    **Good**: Red asterisk + "required" label or legend
  </Tab>
</Tabs>

### Provide text alternatives

<CardGroup cols={2}>
  <Card title="Icons" icon="icons">
    Always pair icons with text labels or use aria-label.

    **Good**: 🔍 Search

    **Avoid**: 🔍 (icon only)
  </Card>

  <Card title="Images" icon="image">
    Write descriptive alt text for meaningful images.

    **Good**: "Bar chart showing 40% increase in sales"

    **Avoid**: "Chart" or "Image"
  </Card>
</CardGroup>

## Accessible patterns

### Buttons

<Accordion title="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.
</Accordion>

### Links

<Accordion title="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.
</Accordion>

### Error messages

<Accordion title="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
</Accordion>

### Form labels

<Accordion title="Visible, permanent labels">
  **Bad**: Placeholder text only ("Enter your email")

  **Good**: Visible label "Email address" + optional placeholder "[name@example.com](mailto:name@example.com)"

  **Why**: Placeholders disappear when typing and aren't reliably read by screen readers.
</Accordion>

## 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

<Steps>
  <Step title="Use a screen reader">
    Test your content with:

    * NVDA (Windows, free)
    * JAWS (Windows, paid)
    * VoiceOver (Mac/iOS, built-in)
    * TalkBack (Android, built-in)
  </Step>

  <Step title="Check reading level">
    Use tools to verify plain language:

    * Hemingway Editor
    * Readable.com
    * Microsoft Word (Review → Readability Statistics)
  </Step>

  <Step title="Remove color">
    View your interface in grayscale to ensure color isn't the only indicator.
  </Step>

  <Step title="Test with users">
    Include people with disabilities in user testing whenever possible.
  </Step>
</Steps>

## Quick accessibility checklist

<Check>Every interactive element has descriptive text</Check>
<Check>Links describe destination (no "click here")</Check>
<Check>Errors include "Error:" prefix</Check>
<Check>Form fields have visible labels (not just placeholders)</Check>
<Check>Color is paired with text or icons</Check>
<Check>Critical content under 14 words per sentence</Check>
<Check>Reading level appropriate for audience (7th-10th grade)</Check>
<Check>Technical terms defined on first use</Check>
<Check>Headings follow logical hierarchy</Check>
<Check>Icons have text labels or aria-labels</Check>

## Related resources

<CardGroup cols={3}>
  <Card title="Buttons and links" icon="hand-pointer" href="/guides/buttons-and-links">
    Write accessible buttons and links
  </Card>

  <Card title="Error messages" icon="triangle-exclamation" href="/guides/error-messages">
    Create accessible error messages
  </Card>

  <Card title="Form fields" icon="input-text" href="/guides/form-fields">
    Write accessible form labels
  </Card>
</CardGroup>