StrategyOctober 18, 20264 min

Build comparison tables people can read on mobile

Choose between a small table, locally scrollable comparison and stacked summary, then test headers, units and readability on narrow screens.

The cover shows precision etched black metal grid under grazing white light.

Which comparison format fits the task?

Choose the format by the comparison the reader must make. Two short alternatives can sit in a compact table. A wider dataset may need local scrolling. A sequence of independent descriptions may work better as stacked sections. Shrinking every column until labels split into fragments preserves the grid while destroying the decision.

W3C WAI explains that data tables need structural relationships between headers and data cells. Captions identify the subject; complex relationships can require explicit associations. Visual alignment alone does not supply this context to assistive technology. The practical specification below adds editorial and testing choices to that guidance. [W3C WAI: Tables tutorial]

Choose the smallest useful representation
FormatUse whenWhat to test
Compact tableFew short, comparable dimensionsHeader relationships and units stay clear
Locally scrollable tableCross-row comparison requires more widthKeyboard access and every column remain reachable
Stacked summariesReaders evaluate one option at a timeRepeated labels preserve meaning and comparison remains possible

Test the awkward content, not a tidy placeholder

Use a realistic fixture before approving the layout. An illustrative plan comparison might include “Monthly contribution after variable fulfillment costs, USD,” the value “1,248.75,” “Not available,” and a note explaining a conditional inclusion. Short placeholders such as “Plan A” and “123” will miss the content that actually breaks.

Small semantic fixture; styling and keyboard behavior still require testing.
<table>
  <caption>Illustrative plan inputs, USD per month</caption>
  <thead><tr><th scope="col">Plan</th><th scope="col">Included hours</th></tr></thead>
  <tbody><tr><th scope="row">Review only</th><td>4</td></tr></tbody>
</table>

Keep units in the header or caption rather than expecting readers to remember a preceding paragraph. Use words such as “Not available” when the value is missing; a zero would assert a measured absence. If a footnote changes the meaning of a cell, make the reference reachable and the explanation available on touch devices.

How should local scrolling behave?

Keep surrounding prose, headings and controls within the viewport while the comparison scrolls inside its own region. W3C’s reflow guidance discusses a 320 CSS-pixel equivalent width and a limited exception for content requiring two-dimensional layout. That exception does not make unreadable cells or overflowing surrounding paragraphs acceptable. [W3C WAI: Understanding reflow]

Give the scroll region a useful accessible name when it needs one, expose a visible cue that more columns exist and check keyboard focus. A clipped scrollbar alone is a poor instruction. On a phone, verify that a user can reach the last column without accidentally moving the entire page sideways.

Do not apply character-by-character wrapping to every table cell. An amount split across several lines is technically inside the viewport but difficult to compare. Preserve readable numeric groups and provide enough column width. Long prose can wrap naturally within its cell; a raw URL needs a different wrapping rule from a currency value.

A concrete acceptance checklist

  • At a narrow viewport and enlarged text, read the longest header aloud without reconstructing broken word fragments.
  • Navigate cells with a screen reader and confirm the associated row and column labels.
  • Use only the keyboard to reach the scroll region and its final column.
  • Check positive, zero, negative, unknown and unavailable values without relying on color.
  • Copy a number and confirm its sign, decimal separator and unit remain unambiguous.
  • Compare the compact, scrolling and stacked versions against the same reader question.

Record the viewport, zoom, browser, assistive technology where used and the exact fixture. “Mobile passed” is too vague to reproduce. This focused acceptance record supports the comparison component; it does not establish accessibility conformance for the whole site or prove a conversion-rate improvement.

I would remove a low-value column before adding another layer of scrolling instructions. Keep the dimensions that change the decision, and move supporting detail into a nearby explanation. The result should remain useful even when readers never see the desktop layout.

Sources

AI-assisted writing and an AI-generated editorial cover. Source links and checked dates are listed below; illustrative examples are labeled in the text.

More on the topic