Table Structure Guide

Questions answered by this guide

• ?Why can't a screen reader read my table correctly?
• ?How do I mark header cells in a table?
• ?Does a screenshot of a table work for a screen reader?
• ?How do I fix table accessibility in Storyline?
• ?How do I fix table accessibility in Rise?
• ?Which WCAG criterion covers table structure?

What you'll learn

• A screen reader can't tell a header from a data cell just by how it looks
• Marking the header row is what lets a screen reader announce context for each cell
• A table pasted in as an image can never be read as structured data, no matter what alt text it has

What's inside

Instructional designers building data tables in Storyline or Rise

1. 01The concept
2. 02A worked example
3. 03How to fix it in Storyline
4. 04How to fix it in Rise
5. 05When a table isn't the right choice

Why it matters

A sighted learner scans a table and instantly sees which column heading applies to which cell. A screen reader can't do that from visual position alone, it needs the header row (or column) explicitly marked as headers, not just cells that happen to look bold or sit at the top. Without that, a screen reader reads the raw values in order, "Q1, Q2, Q3, 12000, 15000, 9000," with no indication of what any of those numbers actually represent. This is WCAG success criterion 1.3.1 (Info and Relationships, Level A): information and relationships conveyed visually, like which header goes with which cell, must also be conveyed programmatically, not just through appearance.

When you'll encounter this

• You're adding a table to compare numbers, dates, or categories across rows and columns.
• A table was pasted in from a spreadsheet or another document as a flat image instead of a real table object.
• You're reviewing a course someone else built and a table's header row looks bold, but you're not sure it's actually marked as one.
• A11yCheck flags a table structure issue on a scan report.

Examples

Best practices

• Confirm the top row (or leftmost column, if that's where your labels are) is genuinely set as a header row, not just styled to look like one.
• Give every header cell real, descriptive text. "Q1 Revenue" reads better aloud than a blank or placeholder header.
• If a table exists only as a screenshot or pasted image, rebuild it as an actual table object. An image of a table can't be read as structured data no matter what alt text you add.
• Keep tables as simple as you reasonably can. Merged cells and deeply nested headers are hard for a screen reader to describe clearly even when correctly marked up.
• If a table only needs to convey one or two facts, consider whether a sentence would actually communicate it more clearly than a table at all.

Common mistakes

• A table pasted in as an image or screenshot, with no real table structure behind it at all.
• A header row that's bold and centered to look like a heading, but isn't actually marked as one.
• Overly complex tables with merged cells that are hard to describe in a linear, read-aloud order.
• Blank or placeholder header cells left in place after the table's real content was filled in.

Practical checklist

• The header row (or column) is genuinely marked as a header, not just styled to look like one.
• Every header cell has real, descriptive text.
• No table exists only as a screenshot or pasted image.
• Merged cells and nested headers are avoided or kept minimal.
• Test it yourself: turn on a screen reader and listen to the table read aloud. If you can't follow what each number means by ear alone, a learner won't either.

Frequently asked questions

Summary

A data table needs its header row (or column) explicitly marked as a header, not just styled to look like one, so a screen reader can announce which column or row each cell belongs to. This is WCAG 1.3.1. An image of a table can never meet this, it has to be rebuilt as a real table object or block.