Start with the comparison people need to make
Tables work best when readers need to compare values across rows and columns. Imagine a community organization listing room-hire options: each row names a room, while columns show capacity, available equipment and hourly price. A visitor can scan across one row to assess a room or down the price column to compare costs. If the information is simply a sequence of steps or short descriptions, a list may be easier to read.
Before building a table, decide which columns are essential to that comparison. Put identifying information, such as the room name, first. Use short, specific headings: “Capacity” is clearer than “Details” when the cells contain numbers of people. Give units in the heading where possible, such as “Hourly price (£),” rather than making readers infer them from scattered cells. If a table needs a long explanation before anyone can understand it, consider dividing the information into smaller tables.
Give every value a clear context
Build a data table with actual table elements, not text spaced into columns. Use header cells for column headings and, when helpful, for row names. Mark a simple column header with scope="col" and a row header with scope="row". This structure helps assistive technology associate a value, such as “24,” with both “Capacity” and “Meeting Room.” Keep the reading order logical in the underlying page, not just in the visual design.
A brief caption can tell readers what the table covers, for example, “Room-hire options at the community centre.” Place qualifications near the relevant information. If a price excludes an optional service, explain that in the heading, cell or a clearly connected note rather than relying on colour or an unexplained symbol. Avoid blank cells where the meaning is ambiguous; “Not available” is more useful when that is what the blank would mean.
Simple tables are usually easier for everyone. Merged cells and multiple layers of headings can make relationships harder to follow, especially when a table is read cell by cell. If complex grouping is necessary, check that every data cell has the right header associations and consider whether two simpler tables would communicate the same information better.
Make a deliberate plan for narrow screens
First, reduce avoidable width. Shorten headings without making them vague, allow text to wrap, and remove columns that are not needed for the task. Do not shrink type until it becomes difficult to read. A room-hire table with four concise columns may fit comfortably on many screens; a timetable with ten time slots probably will not.
For a genuinely wide table, horizontal scrolling is often better than squeezing or hiding information. Keep the table inside a scrollable container and make it visually apparent that more columns are available, for example with a short instruction or a visible cut-off at the edge. Check that people using a keyboard can reach and scroll the container; if it needs its own keyboard focus, give that focusable region an accessible name. Avoid adding a tab stop when the table is already usable without one.
Another option is a small-screen layout that presents each row as a labelled group, such as one card per room. If you take this route, repeat the column labels alongside their values so “24” still means “Capacity: 24.” Be careful with CSS that changes how table elements are displayed: a layout that looks like cards does not automatically retain the table relationships people need. Test the resulting experience rather than assuming the visual change is harmless.
Check the table as a real visitor would
Review the table at a narrow phone width and at increased text size. Can you read every cell without text overlapping or being cut off? Can you still identify the row while scrolling across? If you use sticky headings, make sure they do not cover content. Then navigate using only a keyboard, including any horizontal scroll area.
Finally, try the table with a screen reader if you can. Move through headings and cells and listen for whether each value has enough context. Ask someone unfamiliar with the table to answer a practical question, such as “Which room seats at least 20 people and has a projector?” If they must guess what a number means or cannot find a hidden column, revise the structure or presentation. A good responsive table preserves the comparison, not merely the appearance of rows and columns.
