How can I make a document's tables understandable to screen-reader users?

Start by making the table’s structure straightforward. For a data table, give each column a clear heading so readers can understand what its cells contain. Microsoft recommends simple data tables with specified column headers, and advises avoiding split, merged, or nested cells and entirely blank rows or columns. Complex cell structures can make it harder for screen readers to track their position in a table. [S1]

For example, a straightforward table might have columns named “Task,” “Owner,” and “Due date,” with one task per row. A cell reading “Draft agenda” then appears under an understandable heading, rather than relying on its visual position alone. This is a layout example, not a promise about how a particular screen reader will announce the table.

If a table needs extensive merging or a layout within a layout, consider whether you can reorganize it into simpler tables, or use text with headings and lists instead. Keep the information and relationships clear; do not remove important content just to make a table look simpler.

Make sure your data table has meaningful column headings that describe the information below them. In the example, “Due date” tells readers more than a vague heading such as “Other.”

Then run Word’s Accessibility Checker and review any table issues it identifies. Microsoft recommends using this checker to find table issues. [S1] Treat it as a review aid, not proof that every reader can use the table: the cited guidance does not establish that the checker catches every problem or replaces other accessibility review.

No. Check the Word document, export the PDF, and inspect the PDF you intend to distribute as a separate deliverable. Microsoft’s guidance does not establish that a PDF export retains the table structure, and advises inspecting the resulting PDF separately. [S1]

Use the accessibility inspection options available to you for the PDF, and review the exported document yourself. Check whether the headings and relationships between cells still make sense. If you find a problem, or cannot tell whether the structure carried over, return to the source document, simplify or correct the table, export again, and recheck that PDF. The cited guidance does not specify a particular PDF tool or establish that passing any one inspection guarantees screen-reader usability.

Use this checklist for each table and each file format you plan to share:

1. Ask what the table is for. Keep it focused on related data rather than using it just to position page content.
2. Read each column heading in context. Replace vague labels with headings that explain what the column contains.
3. Look for split, merged, or nested cells and completely blank rows or columns. Simplify the structure where practical while preserving necessary information. Microsoft advises avoiding these structures in Word data tables. [S1]
4. Run Word’s Accessibility Checker and review table-related findings. [S1]
5. If you will share a PDF, export it and inspect that PDF separately. Do not assume Word’s check confirms that the export retained the table structure. [S1]
6. Record unresolved concerns for a qualified reviewer, especially if the table is complex or important information may be difficult to navigate.

Copyable review note: Table: [name or page] | Column headings clear: [yes/no] | Complex or blank structure reviewed: [yes/no] | Word checker reviewed: [yes/no/not applicable] | PDF inspected: [yes/no/not applicable] | Remaining concern: [describe]

This checklist supports a careful review; it cannot certify accessibility or predict how every assistive-technology setup will present a document.