Because reading a table is hard work and most tables do nothing to make it easier. A person has to hold a row and a column in their head at the same time while their eyes travel sideways. Lose the row for a second and they have to start over. Good table design is almost entirely about preventing that.
We see this most on pricing pages, comparison pages, and specification tables. The data is correct. The layout makes it unreadable.
What follows is what actually helps, drawn from Nielsen Norman Group's usability work, the W3C's accessibility guidance, and what we have found holds up on real client sites.
Losing your place. Nielsen Norman Group puts it plainly in an article by Page Laubheimer: "the visual design needs to enable users to keep their place as they move their eyes across the table." Every other table problem is downstream of that one.
Long rows are the main culprit. The wider the table, the further the eye travels, and the more likely it lands on the wrong line coming back.
Dense typography makes it worse. Rows packed tightly together give the eye nothing to lock onto, so the horizontal journey becomes guesswork.
Inconsistent formatting inside a column is the third problem. When one cell says 1200 and the next says 1,200.00 the reader stops comparing and starts decoding.
Right align numbers, left align text, and align headers with the content beneath them. This is our standard on every build. Right aligned numbers stack their digits into columns, so thousands sit above thousands and the reader can compare magnitudes without reading a single figure.
Use tabular figures where your typeface offers them. Many fonts ship proportional numerals by default, which means a 1 is narrower than a 7, and your carefully aligned column wobbles. The CSS font-variant-numeric property with the tabular-nums value fixes it in one line.
Keep decimal places consistent down a column, even when it means trailing zeros. A column reading 4.5, 4.50, and 4.500 is three different numbers to the eye and one number to the data.
Check for tabular figures before you commit to a typeface. It is a two minute test in the browser and it is far cheaper than discovering the problem after every price on the site is set in that font.
Something, but rarely all of it. Nielsen Norman Group lists the options together: "borders, zebra striping, and hover-triggered highlighting of a record can all help." The mistake is treating that as a list to implement rather than a set to choose from.
Our default is a single horizontal rule between rows and nothing else. It gives the eye a track to follow without adding the visual noise of a full grid.
Zebra striping earns its place when rows are tall or when the table has more than about six columns. Below that it usually adds pattern without adding clarity.
Hover highlighting is the cheapest win on desktop and does nothing on touch, so never rely on it as your only wayfinding. It should be a bonus on top of a table that already works.
It either scrolls sideways or it breaks. WCAG 2.2 actually anticipates this. Success Criterion 1.4.10 Reflow, at Level AA, asks for content to be presentable without two-dimensional scrolling at "a width equivalent to 320 CSS pixels," and it carves out an explicit exception for content that needs a two-dimensional layout.
Data tables are named in that exception. The criterion's notes list "data tables (not individual cells)" among the examples, which means a table is allowed to scroll horizontally when the data genuinely requires it.
That exception is permission, not encouragement. A table that scrolls sideways is still hard to use, so the right move is usually to reduce columns for small screens rather than to ship the desktop table sideways.
Whatever you do, keep the horizontal scroll inside the table itself. A page body that scrolls sideways feels broken in a way a scrolling table does not. Our post on responsive breakpoints covers where to make those decisions.
Because without it a screen reader reads a grid of unrelated words. The W3C Web Accessibility Initiative is direct: "header cells must be marked up with th, and data cells with td to make tables accessible." That is the whole foundation, and plenty of sites skip it by building tables out of divs.
The payoff is context. The W3C explains that "people using screen readers can have the row and column headers read aloud as they navigate through the table. Screen readers speak one cell at a time and reference the associated header cells, so the reader doesn't lose context."
For anything beyond a simple grid you need to be explicit. The W3C notes that "for more complex tables, explicit associations may be needed using scope, id, and headers attributes."
There is a second benefit people forget. Proper markup lets the data be re-rendered other ways, which the W3C mentions directly: some people use custom stylesheets to display header cells more prominently. Our WCAG accessibility guide covers where tables sit in a wider audit.
It gives the table a name that assistive technology can announce. MDN Web Docs describes the caption element as "specifying the caption (or title) of a table, providing the table an accessible name or accessible description." One line of HTML replaces a lot of guessing.
Placement is strict. MDN states that "if included, the caption element must be the first child of its parent table element." Put it anywhere else and it stops working.
The benefit is not limited to screen reader users. MDN notes that a title is "helpful for users who are quickly scanning the page," and lets people "determine the table's relevance quickly without the need to have a screen reader read the contents of many cells just to find out what the table is about."
We treat this as non negotiable now. If a table is worth building, it is worth naming.
More than about seven and you are asking for trouble on desktop, more than three or four on a phone. The real test is not a number though. It is whether the reader can see the row label and the value they care about at the same time without scrolling.
When you exceed that, the fix is usually editorial rather than technical. Half the columns in most business tables exist because the data was available, not because anyone needs them side by side.
Freezing helps when you genuinely cannot cut. Nielsen Norman Group recommends that you "freeze header rows and header columns (if the table is larger than the screen)," which keeps the labels visible while the values move.
Splitting is the other option. Two focused tables almost always read better than one exhaustive one, and they give you two chances at a clear caption.
Use a table when the reader needs to compare values across two dimensions. Use something else when they do not. A feature list is not a table. A set of pricing tiers with four items each is usually better as cards, because nobody is comparing row by row.
The question we ask is whether anyone will read across. If every visitor picks one column and ignores the rest, a table is the wrong shape for the content.
Comparison pages are the interesting exception, because reading across is exactly the point. Our post on comparison page design covers how to structure those so the table earns its complexity.
And never use a table for layout. That habit died twenty years ago for good reasons, and it still turns up in email templates that get pasted into websites.
Right align your numbers, add a caption, and check that your header cells are real th elements. Those three changes take under an hour on most sites, and together they fix readability, accessibility, and the scanning problem that makes people give up.
Then open the table on a phone. If the page scrolls sideways rather than the table, fix that next, because it makes the whole page feel broken.
After that, cut a column. There is almost always one that nobody has ever needed, and removing it does more for readability than any amount of styling.
If you have a pricing or comparison table that is not converting and you suspect the layout is the reason, we are happy to take a look and tell you what we would change. You can find us at phoenix.studio, and we usually reply within a couple of days.
Tell us where you want to go. We'll tell you how we'd get you there.