Prepare website tables readers can understand and navigate.

1. Confirm the information needs a table

Write the reader’s question before building a grid. “Which option includes this feature?” may benefit from a comparison table; a sequence of instructions usually works better as steps. Keep each row about the same kind of item and each column about one defined attribute.

Define the scope and date for information that changes. For example, do not place a monthly allowance beside a per-project limit under a column simply called “Limit.” If a value is unknown, write “Not confirmed” instead of a dash that readers might interpret as zero or unavailable.

2. Give the table a useful caption

W3C explains that a caption helps readers identify and find a table, including people navigating tables with a screen reader. Use a short, specific description of the content. The HTML caption belongs to the table; a visually nearby heading does not necessarily provide that association.

For a complicated arrangement, add a concise explanation of how the data is organized. W3C distinguishes that structural summary from the caption and advises against repeating the same information in both. Often the better editorial decision is to split an overloaded table into two simpler comparisons.

Sources: [1]

3. Mark headers by meaning, not just appearance

A bold first row is not enough to communicate every relationship in the markup. W3C’s guidance for tables with row and column headers uses header cells and a direction: scope="col" for a column header and scope="row" for a row header.

Ask the builder to preserve those relationships in the actual HTML, not only in a screenshot. Complex merged headers need more careful associations than this introductory example. If a reader must repeatedly guess which heading applies to a value, simplify the design before adding more styling.

Sources: [2]

4. Review the values and their context

ATN suggests a content pass separate from visual styling. Read across one row, then down one column, and see whether the same question is answered each time.

Use complete words for an important state instead of relying only on color or a symbol. If a note changes the interpretation of a value, make it available where someone encounters that value.

5. Check the rendered table on desktop and mobile

Review long names, wrapped text, headings, and any scrolling area at narrow widths. Confirm that values remain associated with their labels when the layout changes. If columns are hidden on mobile, check whether the reader has lost a critical distinction rather than assuming the shorter table is equivalent.

Include keyboard and assistive-technology checks in the implementation review, especially if sorting, filtering, or a scrollable region is introduced. Record the device, browser, task, and observed issue. A clean screenshot does not establish accessibility, and this checklist is a starting point rather than a complete conformance assessment.