A price table that makes sense when read aloud

Tables for data, never for layout

A table is the right tool when you have rows and columns of related facts. Opening hours. A price list. A comparison of three service levels.

Using one to push a photo next to a paragraph is a habit left over from very old web design. Speech announces it as a table and starts reading coordinates, and on a phone it refuses to reflow.

Header cells are the whole trick

In a proper table the top row and often the first column are marked as headers rather than as ordinary cells. That single distinction is what lets a reader hear Saturday, opening time, nine, instead of just nine.

Without it, a screen reader has a grid of values and no idea what any of them mean. The sighted reader gets the same information from position. The listener gets nothing.

The distinction is invisible in a browser, which is why it survives so long. A bold top row looks identical to a real header row, and only the software reading the page aloud can tell the difference.

Say what the table is

Give every table a caption or a heading immediately above it. Standard call out rates, or hours by location. It costs one line and it orients everybody.

It also helps on a long page where somebody has jumped straight to the table from a heading list and has no idea what preceded it.

Keep the shape simple

Merged cells, stacked header rows and tables nested inside other tables are where accessibility and phone layouts both fall apart.

If your table needs two header rows, it is usually two tables. Splitting it is nearly always better than explaining it, and the split version reads better on a small screen as well.

A good rule: if you cannot read a row aloud as a sentence, the table is doing too much. Standard call out, forty dollars, weekdays works. A row spanning three merged headers does not.

Sorting, filtering and other moving parts

A table that can be sorted by clicking a column heading needs those headings to be real buttons, and it needs to announce the new order once it changes. Otherwise the content silently rearranges itself.

Filters have the same problem. A reader who cannot see the grid has no idea that four rows just disappeared unless something says so.

On most business sites none of this is needed. A short table that simply sits there is easier to build, easier to read and impossible to break.

On a phone

A wide table on a narrow screen either shrinks the text until it is unreadable or forces the whole page to scroll sideways. Both are bad, and sideways scroll is the worse of the two.

The usual answers are to let the table scroll inside its own box, or to restack each row as a small block with its labels repeated. Either is fine. Squeezing eight columns onto a phone is not.

This is the single most common cause of a page that scrolls sideways, which is a real usability failure and is covered from the layout side in text resizing and zoom.

When not to use a table at all

Two numbers and a note is a sentence. Three services with a price each is a short list. Reach for a table when the grid is genuinely doing work.

Pages here are written from a conversation about your business, and pricing usually comes out clearer as plain text with the figure beside each item. Every page passes a check that runs before anything publishes, validated against Google Search Essentials and modern web standards.

• Two or three figures with a note — that is a sentence
• A short price list — a list reads better and fits a phone
• Opening hours — a list, unless you have several locations to compare
• A single row of anything
• Layout, always
• Anything you would otherwise save as a picture

A quick way to test one

Turn on the screen reader you already own and move through the table cell by cell. You should hear the row and column labels repeated with each value.

If you hear bare numbers, the header cells are not real, whatever the styling looks like. That is the single most common fault and usually a small fix.

The in-app assistant flags tables with no header row before anything publishes, which catches the common case. Reading one aloud catches the rest.

None of this is legal advice. It is the difference between a price list a listener can follow and a run of numbers with nothing attached to them.

If you inherited the table from a spreadsheet export, check it first. Exported tables frequently carry blank spacer rows and merged title cells that make the structure unreadable even when it looks fine.