A screen reader announces a table cell by cell, and without proper header markup the listener hears values with no idea what they refer to. Marking headers correctly fixes that, and it is the same markup that lets a table adapt on a narrow screen rather than forcing a horizontal scroll.
Why a table is harder than it looks
Visually a table works because the eye can move up to a column heading and left to a row label without thinking. That spatial relationship carries the meaning.
Read aloud, that relationship disappears. The listener hears a sequence of cells: 450, 12, yes, 890, 18, no. Without headers announced alongside each value, none of it means anything.
Proper markup restores it, so the listener hears the column and row name with each cell. That is the whole of the accessibility requirement for most business tables, and it is a markup change rather than a design one.
What proper markup means
- Header cells marked as headers, using the header element rather than an ordinary cell styled to look bold.
- A scope attribute saying whether each header applies to its column or its row, which resolves ambiguity in tables with both.
- A caption, which names the table so a listener knows what they are entering before the cells begin.
- A header row inside the appropriate section element, which also lets the header repeat when a long table is printed.
That is four things, all invisible visually, and together they turn an unusable table into a navigable one.
Tables used for layout
Worth addressing because it still appears on older sites.
Using a table to position elements on a page, rather than to present data, causes assistive software to announce a data structure that does not exist. The listener is told they have entered a table with four columns when they have arrived at a page layout.
Modern layout methods handle this properly and any table remaining on a site should be there because it holds tabular data. Where an old site uses them for layout, that is a rebuild consideration rather than an emergency, and it is worth knowing why it matters.
The mobile problem
A table with five columns does not fit a phone screen, and the common outcomes are all poor: text shrunk to illegibility, a horizontal scroll people do not notice, or content cut off entirely.
Three approaches work, in rough order of preference for a small business site.
Reduce the columns
The simplest and most often correct. Many business tables carry columns nobody reads. Three columns fit a phone; six do not, regardless of technique.
Restack each row as a block
On narrow screens each row becomes its own small block, with the header repeated beside each value. This preserves all the data and is readable, and it works because the header text is available in the markup.
A contained horizontal scroll
Acceptable where the table genuinely needs its columns, provided the scrollable area is visibly indicated so people know to swipe. An unmarked scroll region is content nobody finds.
Where a table is the wrong choice
Two common cases on business sites.
A comparison of two or three things with a handful of attributes is frequently clearer as short blocks of text than as a grid, particularly on a phone where the grid will be cramped.
A single column of items is a list rather than a table, and marking it as a table adds structure that conveys nothing.
The test is whether the data has genuine rows and columns that relate to each other. If reading down a column and across a row both mean something, it is a table. If only one direction has meaning, it is a list.
Small practical points
- Do not merge cells unless necessary, since merged cells complicate the relationships assistive software is trying to convey.
- Keep one table per topic rather than combining several into one with blank separator rows.
- Avoid empty cells where possible, since a listener cannot tell an empty cell from a missing one. A dash or the word none is clearer.
- Do not rely on colour alone to convey a value, since that fails both for screen readers and for anyone who cannot distinguish the colours.
- Left-align text and right-align numbers, which is a readability convention that helps everyone.
Where this comes up on a business site
Pricing tables, service comparisons, specification lists, and opening hours are the usual ones.
Opening hours in particular are worth getting right, since they are frequently the specific thing a visitor came to find, and a table of hours that reads as an unlabelled sequence of times is a poor experience at exactly the wrong moment.
None of this requires a rebuild. It is markup applied once, usually in a template, and it belongs to the same set of small changes that make a site work for everyone, as covered in why accessibility is a business issue.
Frequently asked questions
Why do tables need special markup?
A screen reader announces cells one at a time, so without header markup the listener hears values with no idea what they refer to. Proper headers announce the column and row name with each cell.
What markup does an accessible table need?
Header cells marked as headers rather than styled bold, a scope attribute saying whether each applies to its column or row, a caption naming the table, and the header row in the correct section element.
How should tables work on a phone?
Reduce the columns where possible, since three fit and six do not. Otherwise restack each row as a block with the header repeated, or use a visibly indicated horizontal scroll.
Is it acceptable to use tables for page layout?
No. Assistive software announces a data structure that does not exist, telling the listener they have entered a table when they have arrived at a layout.
When is a table the wrong choice?
When only one direction has meaning. A single column of items is a list, and a comparison of two or three things is often clearer as short text blocks, particularly on a phone.
What should I avoid inside a table?
Merged cells where possible, empty cells with no dash or explanation, colour as the only way of conveying a value, and combining several topics into one table with blank separator rows.
West Coast Media Solutions Inc. provides web design, web development, hosting, digital marketing, and business consulting to organisations across Canada, drawing on more than twenty-five years in the field.
Pricing or hours tables that break on a phone?
We fix the markup so they read correctly aloud and adapt properly on a narrow screen, usually in the template rather than page by page.
Start a Conversation