A Table That Does Not Fit

Where the tables come from

Price lists, specification sheets, opening hours, service comparisons, size charts, and delivery schedules.

Almost all of them were designed for paper or for a wide screen, where a reader can see every column at once and scan across a row without losing their place.

A phone screen offers roughly a fifth of that width, and the assumption the table was built on no longer holds.

What happens next is usually one of three failures, and none of them is chosen deliberately.

The three failures

• The table shrinks until the text is too small to read.
• The page scrolls sideways, so every page on the site does.
• Columns wrap into a jumble where rows no longer line up.

The second is the worst, because a table that pushes the page wider affects the whole layout, not just itself, and visitors find themselves able to swipe the entire site left and right.

It is also easy to miss, since it looks correct until somebody scrolls to the section containing the table.

First, ask whether it is a table

A surprising proportion of tables on business sites are not tabular data at all.

A table is for information where the relationship between rows and columns matters: where you genuinely need to compare the third column of one row against the third column of another.

Two columns of label and value are a list wearing a table's clothes. So is a table used purely to place things side by side on a page.

If the data is a set of items each with several attributes, and nobody actually compares across them, it will work far better as stacked blocks with headings, which need no special handling at any screen size.

Where it genuinely is a table

Specification comparisons, price matrices, and schedules where reading across the row is the whole point.

For these, the reliable approach is to let the table scroll horizontally inside its own container, so the page itself stays fixed and only the table moves.

Fix the first column in place if you can, since that is the one carrying the row labels, and a scrolling table without visible labels is unusable after two columns.

Make the scrolling discoverable. A table that can be swiped but shows no sign of it looks like a table that has been cut off, and visitors do not try.

Stacking, and when it works

The other common approach turns each row into its own block on a phone, with the column headings repeated as labels within it.

This reads well and works for tables with few columns and self-contained rows, such as a list of services with a price and a duration.

It works badly for comparison, because the whole point of comparing is seeing two things next to each other, and stacking puts them one after another.

So the choice follows the purpose. Data people read one row at a time stacks well. Data people read across and compare should scroll.

A worked example

An equipment supplier had a comparison table of eleven models across seven specification columns.

On a phone it forced the entire site to scroll sideways, which had been reported by customers as the site being broken.

Stacking it produced eleven long blocks that nobody could compare, which was the reason the table existed.

What worked was splitting it. The four specifications that customers actually chose between stayed in a horizontally scrolling table with the model name fixed in the first column.

The remaining three, which were reference details nobody compared, moved onto the individual product pages.

The table became narrow enough to be usable, the sideways scrolling of the whole site stopped, and the detail was still available where somebody would look for it.

Reduce before you engineer

The most effective fix is usually removing columns rather than making seven of them fit.

Most wide tables contain a mixture of things people compare and things people occasionally check, and only the first group needs to be side by side.

Ask which columns a customer uses to make the decision. Keep those. Move the rest to a detail page, a downloadable sheet, or a section below.

This is a content decision rather than a technical one, it costs nothing, and it produces a better table on every screen size rather than a clever version of a bad one.

Prices deserve particular care

Price tables are the ones customers most want on a phone and the ones most often mishandled.

Somebody standing in a car park checking what something costs will not persevere with a table that requires zooming and sideways scrolling.

Where prices are simple, a plain stacked list of item and price is better than any table.

Where they genuinely vary by two dimensions, such as size and finish, keep the axes as short as possible and consider whether a starting price plus an explanation of what moves it would serve most visitors better than the full matrix.

Do not use an image

Worth stating plainly, because it is the shortcut people reach for when a table will not cooperate.

A screenshot of a table solves the layout problem and creates several worse ones: it cannot be read by a screen reader, it cannot be searched or indexed as text, it cannot be copied, and it becomes illegible when scaled down to fit a phone.

The same applies to a table exported as a document and linked for download, which asks a phone user to leave the site and open a file to find a price.

If a table is difficult, the answer is fewer columns, not a picture of the difficulty.

The counter-case

Some tables should stay wide, and forcing them into a phone-friendly shape does the reader no favours.

Technical reference material used by professionals at a desk, full specification schedules, and detailed compatibility matrices are legitimately complex, and their readers expect and want the complete grid.

In those cases the honest answer is a table that scrolls horizontally, plus a downloadable version for anybody who needs to work with it properly, and no attempt to pretend it is a phone experience.

The distinction is who reads it. Material aimed at a customer deciding something should work on a phone. Material aimed at a specifier working through a schedule can assume a larger screen, provided the phone version is honest about that rather than broken.

The approach

1. Check whether it is genuinely tabular data.
2. Restructure into stacked blocks if it is not.
3. Cut columns to the ones people compare.
4. Move the rest to a detail page.
5. Let the table scroll inside its own container.
6. Fix the first column and make the scrolling visible.
7. Never use an image of a table.

Step three does more than the other six and requires no development at all.

Print thinking applied to web pages is covered in a print brochure is not a web page.

Frequently asked questions

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.