Tables

Use the built-in tools. Avoid using paragraphs with symbols (like symbols, numbers, or dashes) or adding spaces to line text up to create the appearance of a table.

Avoid merging cells or using complex layouts unless absolutely necessary. Simple tables are easier to navigate and understand.

Stick to tables for actual data, not for visual design.

Table header cells function very differently from headings. Headings separate sections of the page. Table header cells identify row or column headers.

Where plausible, use a list instead of a table. Tabular data can be formatted into lists. The data is accessed the same way. The list would start based on the header row or column that works best. These help when tables are too wide for the screen.

Table headers are the labels at the top of columns or the beginning of rows. They help assistive technologies explain what each cell means. For example, a screen reader navigating a table:

• without table headers may come to a data cell and say, "$10"
• with a table header for the column called "Price" may come to a data cell and say, "Price, $10"
• with table headers for the row "Chicken" and column "Price", may come to a data cell and say, "Chicken, Price, $10"

Note that defining the "scope" assists in this process. It tells assistive technology whether a header applies to a row or a column.

Table captions provide context for the table's purpose. These are required when a table conveys information that needs explanation. This used to be done in the "table summary", but users noted that the summary was typically text around the table anyway.

A semantically defined table caption will be read by a screen reader before it describes the structure of a table. For example, it may say something like, "Table: List of foods and their classifications."

That is different from a heading which might read aloud, "Heading 2. List of foods and their classifications." The user will not know a table is coming up, just that the data is coming up.

You are correct. Merging cells can make tables difficult or impossible to read for people who use screen readers. But blank cells can also cause confusion depending on how different screen readers handle them.

Here is what we found when testing how screen readers read blank cells or cells that contain a dash:

• JAWS (Windows)
  • Blank cells: Reads the word "blank"
  • Dash: Reads the word "dash"
  • Moves to the next cell without skipping
• NVDA (Windows)
  • Blank or dash: Does not read anything
  • Moves to the next cell without skipping
• VoiceOver (iPhone and iPad)
  • Blank cells: Skips the cell entirely
  • Dash: Reads the word "hyphen" and moves to the next cell

What does this mean? Some screen readers skip blank cells entirely. This can make it seem like information is missing or cause confusion for users. Using a consistent symbol such as a dash helps ensure that every cell is acknowledged, which improves clarity and accessibility for everyone.

Recommendations:

• Do not merge cells. Merged cells break the structure of the table and make it harder for screen readers to interpret.
• Use a consistent placeholder in cells that are meant to be empty. A simple dash is a good choice because most screen readers will read it aloud.
• Avoid using symbols like "zero" (o) or "N slash A" (N/A) unless they have a specific meaning in your context.
• If you use a symbol like a dash, include a note or legend that explains what it means.

Tables are designed to show data in rows and columns. When used correctly, people using screen readers can move through the table just like someone looking at it visually. But when a table is used only to position content, it loses that structure. This can make the information confusing or hard to follow.

Screen readers read tables in a specific way. They announce headers and let users move from cell to cell. If the table is just being used to arrange content, the reading order may not make sense. It might jump around or read things out of order, which can be frustrating.

Imagine a paragraph of text that uses spaces and symbols to look like a table. It might look fine visually, but it is very hard to understand with a screen reader. Layout tables can behave the same way. They often read top to bottom, left to right, in a way that does not match how the content is meant to be understood.

Tables used for layout often do not resize properly on phones or tablets. Users may have to scroll both up and down and side to side to read the content. This makes it easy to lose track of where they are. Lists and other built-in layout tools work much better on small screens.