Reviewed October 29, 2026

Product Comparison Tables a Screen Reader Can Actually Use

A comparison table is a visual argument. Columns are products, rows are attributes, and the eye travels sideways to find the winner of each row. Strip the visuals away and that argument survives only if the markup carries it: proper header cells, scope attributes that tie each value to its product and its attribute, and no layout tricks like merged cells that read as nonsense in a linear stream. Most store comparison tables fail here not because the team chose badly, but because a page builder generated a grid of divs that looks like a table and reads like a shuffled list.

Build a real table, then style it

Start with table markup: a caption naming what is being compared, th elements for the product names across the top and for the attribute names down the side, each with the correct scope of col or row. That structure is what lets a screen reader announce a cell as, in effect, battery life, mid range model, ten hours, instead of a bare ten hours floating in a list. Check and cross icons need text equivalents; a check mark announced as an image filename or as nothing tells a blind shopper that one product has a feature and leaves them to guess which. Use a visually hidden yes or no, or an explicit included and not included, inside those cells. Responsive design that collapses the table into stacked cards on mobile must preserve the same associations in the reading order.

Write the row labels as questions shoppers actually ask

Attribute rows labeled with internal spec names, IP rating or mAh, force every shopper to decode your catalogue language while comparing. Row headers that pair the plain question with the spec serve everyone: battery life in hours, water resistance for swimming, weight on the wrist. A screen reader user hears the row header repeated for each cell, so a clear header pays off three or four times per row. Keep units inside the cell values and consistent down a column; a column that mixes hours, days, and a dash for the third product cannot be compared in any medium. Where a value does not apply, write not applicable in text rather than leaving a silent empty cell that reads as missing data.

Give the verdict in words, before or after the table

Even a perfect table is work to read linearly. A short text summary that states the practical outcome, which model lasts longest, which is cheapest, which suits a named use, gives screen reader users the shortcut sighted users get from scanning bolded winners. Stores resist summaries because they feel like duplication; they are not, they are the accessible version of visual emphasis. If the table highlights a recommended product with color or a badge, that recommendation must exist in text in the summary and in the column header, not only as a colored banner. The rule generalizes: anything your design communicates by position, color, or emphasis needs a text path to the same conclusion, or a segment of your customers is shopping without the argument your page is making.

Test the table the way it will be heard

Navigate the table cell by cell with a screen reader or an accessibility checker that exposes header associations, and confirm each value is announced with its product and attribute. Then read the page with the table linearized, the way a small screen or a text only view presents it, and check the order still makes sense. Finally, try the common builder failure: export or view the table on mobile and verify the stacked version does not detach values from their labels. Comparison tables sit on high intent pages and often feed buying guides and AI answers as well; clean structure is what gets your comparison quoted correctly outside your own site, too.

Frequently asked questions

Do comparison tables have to use real table markup?

For data that is genuinely a grid of products by attributes, yes, table markup is what makes the relationships available to assistive technology. A grid of styled divs can be patched with roles, but it is fragile and usually loses header association. If the layout is not really tabular, a set of clearly headed product sections with the same attribute order may serve everyone better than a forced table. The test is whether a value makes sense when heard with its product and attribute names attached.

How should check marks and crosses be handled for screen readers?

Give each icon a text equivalent inside the cell: included, not included, or the specific value it stands for. An icon font character or an image without alt text may be announced as a meaningless symbol name or skipped entirely, which reverses the comparison for a blind shopper. Keep the visual icon if you like it, but hide it from assistive technology and provide a visually hidden text label, or use real text in the cell styled to look minimal. Consistency matters: use the same words in every row.

What if our page builder cannot produce scoped headers?

Then the builder is the constraint to fix, because manual workarounds per table do not survive staff changes. Options include switching that block to a hand coded table, using a builder component that emits proper th and scope, or replacing the table with structured product sections. Do not ship a comparison that only works visually on a high value page and call it a temporary limitation; comparison pages are exactly where an excluded shopper was about to spend money.

Should we include a text summary if the table is accessible?

Yes. A well structured table is navigable, but a summary gives the conclusion directly: the longest battery, the lowest price, the pick for a named use. Sighted shoppers get that conclusion from visual emphasis in a glance, so the summary equalizes the experience rather than duplicating it. Keep it short, keep it accurate to the table values, and update it whenever prices or models change, since a stale summary that contradicts the table is worse than none.