How do I create accessible tables in my course materials?
This wiki guide explains how to structure and format tables so they are accessible to all learners, including those using screen readers and other assistive technologies.
Best Practice Tips
- If you are using a table to position text or images side by side on a page, replace it with column formatting, text boxes, or a Canvas layout instead. Layout tables cannot be made fully accessible.
- Simpler is always better. If the same data can be presented as a short bulleted list, that is almost always the more accessible choice.
- Do not use the Tab key, Enter key, or spacebar to manually align or space out table content.
- Test your table by reading it left to right, top to bottom, one cell at a time. If it still makes sense in that order, it will likely work well for screen reader users.
Core Practices for Accessible Tables
Use tables for data only (NOT for layout).
A data table organizes information that has a logical relationship between rows and columns (e.g., a course schedule, a grading rubric, a comparison of treatment options). A layout table uses the table grid purely to position content visually on a page with no true row/column relationship between cells.
Layout tables are not accessible. If you need to place two blocks of text side by side, use the column or layout tools built into your application (e.g., Word’s column feature, a Canvas two-column layout, or a slide’s placeholder boxes in PowerPoint).
Always designate a header row and column headers (where needed).
Every data table must have at least one header row. The header row contains the column labels that give meaning to every cell below them. In most applications, you designate a header row not just by bolding the text, but by using the application’s built-in table header option; this embeds semantic markup that screen readers can detect.
If your table also has row headers (e.g., a table where the first column lists categories and each row is a separate record), designate the first column as a header column as well. If a cell in a column or row acts as a label for the cells around it, it should be a header.
Keep tables simple; avoid merged and split cells.
Merged cells (where two or more cells are combined into one) and split cells (where one cell is divided) destroy the consistent grid structure that screen readers rely on. A screen reader navigating a table with merged cells may skip cells, repeat cells, or announce incorrect header associations.
If you feel you need to merge cells to make your table readable, this is a sign the table may be too complex. Consider one of the following alternatives instead:
- Break the table into two or more smaller, simpler tables, each with its own clear header row.
- Use a descriptive caption or introductory sentence above the table to provide context that you were trying to convey through the merged structure.
- Move complex multi-level categories into a prose paragraph or nested list instead.
Add a descriptive table caption or title.
A table caption (or title) is a short label that describes what the table contains. Screen readers announce the caption before reading the table, allowing users to decide whether to navigate into it. Without a caption, a screen reader user landing on a table has no advance context.
Table captions should be:
- Brief and descriptive (e.g., “Spring 2027 Course Schedule” or “Comparison of Diagnostic Criteria for Glaucoma”).
- Added using the application’s built-in caption feature, not typed as a paragraph above the table.
- In Microsoft Word: click inside the table, go to References > Insert Caption, and choose “Table” as the label.
- In Canvas: add a caption via the table properties in the Rich Content Editor (see instructions below).
Keep cell content concise and organized.
Each cell should contain a single, clear piece of information. Avoid placing long paragraphs, multiple bullet lists, or nested tables inside a single cell. Long cell content is difficult for screen reader users to parse because the reader announces the column and row header before every cell—a process that becomes tedious and confusing when cells hold multiple blocks of text.
If a data point requires extended explanation, consider linking to a separate page or adding a footnote below the table.
Ensure sufficient reading order.
Tables are read left to right and top to bottom, one cell at a time. Before finalizing your table, read through every cell in that order and confirm the information still makes logical sense. If the sequence feels confusing or ambiguous without the visual layout, reorganize the table or supplement it with a brief introductory sentence.
Do not use color as the sole way to convey table data.
Color-coding rows or cells (e.g., green for passing, red for failing) is not accessible on its own. Always pair color with a text label or symbol. For example: “Pass (green)” and “Fail (red)” in the header, or use a dedicated column for status text rather than relying on fill color alone.
For further guidance on color usage, see How do I use accessible color contrast in my course materials?
Creating Accessible Tables in Common Tools
Microsoft Word
- Insert a table using Insert > Table. Do not draw a freehand table or paste an image of a table.
- Click inside the first row. In the Table Design tab, check the “Header Row” checkbox. This designates the row semantically, not just visually.
- With the header row selected, go to the Layout tab (Table Tools) > Properties > Row tab, and check “Repeat as header row at the top of each page.” This ensures header context is preserved across page breaks.
- Avoid using the Merge Cells or Split Cells options.
- Right-click the table > Table Properties > Alt Text tab > add a brief description of the table’s content and purpose.
- Run Review > Check Accessibility to catch any remaining issues before saving or exporting to PDF.
Microsoft PowerPoint
- Insert a table using Insert > Table. Do not paste a screenshot of a table.
- In the Table Design tab, check “Header Row.”
- Keep slide tables small and simple. Complex multi-row data tables are better presented in Word or as a Canvas page.
- Run Review > Check Accessibility before saving.
Google Docs
- Insert a table using Insert > Table and select your dimensions.
- Google Docs does not yet support native semantic header row designation. To maximize accessibility:
- Bold the header row text and use a distinct background fill to visually differentiate it.
- Introduce the table with a clearly labeled heading or sentence above it (e.g., “Table 1: Course Schedule for Spring 2027”).
- Keep the table as simple as possible and avoid merged cells.
- Strongly consider converting important data tables to an accessible HTML table in Canvas for the best screen reader support.
Google Slides
- Insert > Table. Do not use text boxes arranged in a grid pattern to simulate a table.
- Apply the same best practices as Google Docs: bold headers, clear labels, and simple structure.
- As with PowerPoint, complex tables in slides should be avoided. Direct students to a Canvas page or document for detailed tabular data.
Canvas (Rich Content Editor)
- In the Rich Content Editor, click the Table icon in the toolbar and select your dimensions.
- Once the table is inserted, click inside any header cell and then click the Table icon > Cell > Cell Properties. Change the “Cell type” from “Cell” to “Header cell.” Repeat for each cell in your header row.
- To add a caption: click inside the table, click the Table icon > Table Properties, and enter your caption text in the Caption field.
- To designate row scope or column scope on header cells (for tables with both row and column headers), access Cell Properties and set the “Scope” attribute to “Row” or “Column” as appropriate.
- After editing, run the Accessibility Checker (the icon at the bottom of the RCE, next to word count) to scan for missing headers or captions.
- Use UDOIT to perform a broader course-wide scan for table accessibility issues.
Handling Complex Tables
If your table requires merged cells, nested rows, multi-level headers, or more than approximately six or seven columns, it is likely too complex to be made fully accessible as a single table. Consider these alternatives:
- Split the table: Divide one complex table into two or three simpler tables, each covering a focused subset of the data.
- Use a definition list or prose: Some “tables” containing category-value pairs (e.g., a list of terms and their definitions) are better formatted as a two-column list or a series of headings and paragraphs.
- Provide a text summary: Place a paragraph above or below the table that summarizes its key findings or relationships for users who cannot navigate the table structure.
- Convert to a Canvas page: Tabular data built natively in HTML with Canvas’s Rich Content Editor allows for more precise control over table scope attributes than most desktop applications (see How do I insert a table using the Rich Content Editor?).
Accessible Tables Self-Check Questions
- Is this table used for data, not for visual layout or spacing?
- Does the table have a designated header row (not just bold text)?
- Does the table have a descriptive caption or title?
- Are there any merged or split cells? If so, can they be eliminated?
- Is each cell’s content concise and organized?
- Does the table still make sense when read cell by cell, left to right?
- Is color paired with a text label or symbol rather than used alone?
- Did the Accessibility Checker or UDOIT scan return no table-related issues?
Accessibility Checks
- NECO TLC | How do I build accessible course materials?
- WebAIM: Creating Accessible Tables
- W3C: Tables Tutorial
- Section508.gov: Data Tables Accessibility
- Canvas: How do I use the Accessibility Checker in the Rich Content Editor?
Need Extra Support?
We are here to partner with you as you enhance your courses. If you run into technical issues or want a collaborative consultation on designing custom interactive modules, please reach out to our team:
- Email: tlc@neco.edu
- Send us a request: Request Support