Skip to main content

XCITE Center for Teaching and Learning

Accessible Word Document

  • An Accessible Word Processing Document is a file designed so that its content is fully reachable by everyone, including those who use screen readers, braille displays, or keyboard-only navigation.

    While Microsoft Word, Google Docs, and Apple Pages have different interfaces, the process for making them accessible follows the same structural "DNA."

    • Semantic Headings: Use built-in heading styles (Heading 1, Heading 2, etc.) rather than just bolding or enlarging text. This creates a "map" for screen readers.
    • Alternative Text (Alt Text): Every image, chart, or shape must have a text description so users who cannot see the image understand its purpose.
    • Descriptive Hyperlinks: Avoid "Click Here." Instead, link the descriptive text (e.g., UC Riverside Accessibility Guide).
    • High Color Contrast: Ensure text stands out sharply against the background (aim for a contrast ratio of at least 4.5:1).

  • Word is the most powerful tool for accessibility due to its built-in automated checker.

    • Use the Accessibility Checker: Go to the Review tab and select Check Accessibility. It provides a real-time list of errors and instructions on how to fix them.
    • Apply Heading Styles: Use the Styles Pane on the Home tab. Ensure there is only one Heading 1 (the title) and that sub-headers follow a logical nesting order (H2, then H3).
    • Alt Text: Right-click an image > View Alt Text. Describe the content and the function of the image.
    • Lists: Always use the formal bulleted or numbered list tools rather than typing dashes or numbers manually.

     

    Resource Link

  • Google Docs is highly compatible with screen readers but requires manual setup for structure.

    • Heading Styles: Use the "Normal Text" dropdown menu to apply Heading 1-6. This automatically generates an accessible Outline in the left sidebar.
    • Images: Right-click an image > Alt text. Google provides a "Title" and "Description" field; the description is the most important for screen readers.
    • Tables: Keep tables simple. Avoid merged cells. To designate a header row, you must currently use a third-party Add-on (like Grackle Docs) or ensure the first row is visually distinct and logically organized.
    • Accessibility Support: Users should go to Tools > Accessibility settings and check "Turn on screen reader support" to ensure the interface communicates correctly with their software.

     

    Resource Link

     

  • Pages uses a "Canvas" or "Document" approach. It is deeply integrated with Apple’s VoiceOver.

    • Paragraph Styles: Click the Format button (paintbrush icon), select Text, and use the Paragraph Styles menu to assign Headings.
    • Accessibility Descriptions: Select an image, go to the Format sidebar, click the Image tab, and look for the Description box at the bottom.
    • Table Headers: Select the table, go to the Table tab in the Format sidebar, and use the Headers & Footer buttons to define the top row. This is crucial for VoiceOver to read data correctly.
    • Document Body vs. Page Layout: Ensure you are in "Document" mode for long-form text. "Page Layout" mode treats text boxes as floating objects, which can confuse the reading order for screen readers.

     

    Resource Link

     

  • Summary of Core Elements

    Across Microsoft Word, Google Docs, and Apple Pages, accessibility relies on four fundamental pillars:

    • Logical Hierarchy: Using built-in "Heading Styles" (H1, H2, H3) instead of manual formatting (bold/large font) to create a navigable map for assistive technology.
    • Alternative Descriptions: Providing "Alt Text" for every image, chart, or shape so that visual information is translated into speech or braille.
    • Meaningful Navigation: Using descriptive link text (e.g., "[2026 Registration Form]") and true list formatting so users know exactly where they are and where they are going.
    • Structural Integrity: Keeping tables simple (no merged cells) and ensuring high color contrast so that the content remains readable in all conditions.

     

    Key Takeaways

     

    1. The "Enter" Key is Not for Spacing
      • The Problem: Hitting "Enter" repeatedly to move text to the next page creates a series of blank lines that a screen reader announces as "blank... blank... blank."
      • The Fix: Use Page Breaks or Paragraph Spacing settings to create white space
    2. "Click Here" is a Dead End
      • The Problem: Screen reader users often scan a list of links. Hearing "click here, click here, click here" provides zero context.
      • The Fix: Make the link text describe the destination (e.g., "[View the Accessibility Guidelines]").
    3. Styles are Mandatory, Not Optional
      • The Problem: Manual formatting (Bold + Size 16) looks like a heading but doesn't function as one in the document's code.
      • The Fix: Always apply Heading 1 for the title and Heading 2+ for sub-sections. This is the only way to generate an accessible Table of Contents.
    4. Avoid the "Merge Cell" Trap
      • The Problem: Merging cells in a table breaks the logical grid. A screen reader may skip data or get stuck in a loop.
      • The Fix: Keep tables simple. If a table is too complex, break it into two smaller, simpler tables.
    5. Color is Never a Solo Act
      • The Problem: Using color alone (e.g., "Required fields are in red") excludes users who are colorblind or blind.
      • The Fix: Always use a secondary cue, such as text (e.g., "Required fields are red and marked with an asterisk*").

     

    Platform-Specific Resource Links

    Platform Official Resource Link Best Feature
    MS Word Make your Word documents accessible: Real-Time Accessibility Checker
    Google Docs Make your document more accessible: Accessibility Settings menu
    Apple Pages Create accessible documents in Pages: Hierarchy and Style Pane

← Back to Accessibility Guidance

Let us help you with your search