How can wide technical tables stay readable on phones?
A manufacturer’s desktop table compares six models. On a phone, the columns are squeezed and the text becomes smaller, making it difficult to keep each value attached to its model. An alternative turns every row into a card, but comparing models now requires a long vertical journey. Instead of applying one treatment to every table, establish whether people inspect a single record or compare values across several records. The product codes and numbers used here are layout examples, not real specifications.

Write the question the table must answer
In our fictional catalogue, the task is to compare the dimensions of models A and B. A row heading identifies a model; a column heading identifies a property such as width or power. Ask for a layout that supports that task on a phone, rather than merely an attractive grid. Cards may work for reading one model. Comparing the same property across models places greater value on keeping their relationship visible.
Separate header relationships from decoration
The W3C tables tutorial explains relationships between header and data cells in HTML. Bold text and darker backgrounds do not replace that structure. In our example, “Model A” and “Width, mm” jointly explain a value. Ask the developer to check that assistive technologies can convey the relationships. When complicated merged headers are involved, also consider whether the underlying table can be made simpler.
Confine scrolling to the area that needs it
The W3C explanation of reflow discusses data tables that need two-dimensional layout for meaning. This does not justify making the whole page overflow. Our design proposal keeps a wide table inside its own scrolling region while surrounding headings and explanations fit the viewport. Make the continuation of columns discoverable and ensure a keyboard user can reach the necessary content, not just someone swiping a screen.
Keep labels when converting rows to cards
If each row becomes a card, show property names next to their values again. “240” alone is insufficient; preserve the model and unit it belongs to. Avoid maintaining two independent manual copies when both table and card views are offered. Generate them from the same information and check that they agree. Include long product names, missing values and “not applicable” cases in the example instead of testing only short, fully populated cells.
Summarise differences without hiding data
A brief introduction can explain what readers should compare. Do not silently remove columns on mobile; show where full details remain available. If a property is genuinely unnecessary, record that as an editorial decision. Our measurement and number-format guide covers the meaning of numerical values. This article addresses a different question: arranging the same information on a narrow display without breaking its relationships.
Find the same answer at two scales
Ask a participant to find the same property for two models on desktop and phone. Note values read from the wrong row, lost headings and unreachable columns. Separately enlarge the text and check for missing information. Include these tasks in the website handover while recognising that they do not replace a complete accessibility assessment. Showing every column at once in the narrowest screenshot is not the only valid success criterion.
Frequently asked questions
Is horizontal scrolling always a defect?
No. Tables that require two dimensions need specific consideration. Surrounding content, cell readability and operation still require review.
Is smaller text the easiest mobile fix?
It may be quick, but it can undermine reading. Start with the task, header relationships and the choice between scrolling and stacked records.
