Build accessible data tables

Choose a table for data

A table is appropriate when people need to compare values across rows and columns, such as project milestones by campus or meeting dates by location. It is not a layout tool. If the content is a sequence of instructions, use headings and lists instead. Before building the table, decide what each row and column represents, write a short caption that names the subject, and identify the units and reporting period.

Mark a simple table’s structure

In WordPress, use the Table block’s caption and header-section options when they match the data. Make the first row or column a true header, not just bold text. Keep labels concise and consistent, include units in the heading or caption, and do not communicate meaning only through color. Check that the table remains understandable when viewed at high zoom and on a narrow screen.

For simple row and column relationships, the underlying HTML should expose a caption, header cells, and data cells. A person using a screen reader should be able to move through a cell and understand which row and column headings apply. If the page builder cannot produce that structure, provide the data in another accessible form and request a developer review.

When custom HTML is involved and rows and columns both act as headers, use scope="col" for column headers and scope="row" for row headers. A developer should verify the rendered markup, especially if the editor or a table component transforms the table.

Check the source before publishing. Remove blank spacer rows, repeated heading rows, unexplained abbreviations, and decorative symbols that carry no data. Put notes about rounding, missing values, or a preliminary status directly before or after the table. If a value is unavailable, use a consistent text value such as “Not reported” and explain it, rather than leaving an empty cell that could be mistaken for zero.

Read the table aloud by following one row from its first heading through its values. If the relationship is difficult to explain in a sentence, simplify the table or add a short introduction. Do not assume borders, alternating colors, or centered numbers are enough to tell someone which value belongs to which category.

Hand off complex and responsive tables

Ask the developer to review tables with grouped headers, merged cells, multiple header levels, sortable controls, or horizontal scrolling. Complex relationships may need explicit header associations in the rendered HTML. The responsive design should preserve the relationship between each value and its headings; shrinking text until it becomes unreadable is not a solution. For a large report, consider a concise HTML summary plus an accessible document or data download that has been reviewed separately.