A comparison table can fit inside a phone screen and still be hard to read. Our mobile check found exactly that problem: an early layout avoided page overflow by breaking words into awkward fragments. We changed the table to keep readable columns inside a horizontally scrollable region, then tested that region with the keyboard.
The observed problem and change
The test page was our creator-search guide, whose table compares a known handle, a name, an interest and a price preference as different starting points. On the narrow preview, compressed columns interrupted ordinary words.
The revised layout gives the table a minimum width while containing it within the article. A short instruction explains that smaller screens can scroll across it. The region is keyboard focusable, has a descriptive accessible name and shows a visible focus outline.
At a 320-pixel viewport, the region measured 273 pixels across and contained a 576-pixel table. After we focused it and pressed ArrowRight, the observed horizontal position changed from 0 to 80 pixels. A screenshot confirmed readable words and a visible horizontal scrollbar. The page itself did not become wider than the viewport.
Three sizes, one table
Scroll across the table on smaller screens.
| Browser viewport | Table region | Table content | Observation |
|---|---|---|---|
| 320 pixels | 273 pixels | 576 pixels | Contained horizontal scroll; keyboard movement observed |
| 390 pixels | 343 pixels | 576 pixels | Table remained within the article |
| 1440 pixels | 760 pixels | 760 pixels | Table fit without horizontal overflow |
The browser's vertical scrollbar accounted for 15 pixels between the viewport width and the document width. These are measured CSS layout dimensions from one browser, not a description of every physical phone.
Our audit record records the preview deployment, selection, dimensions and limitations. It also separates this table check from three image-markup observations.
What the result does and does not establish
The change made this particular comparison easier to read at the tested sizes and enabled the keyboard interaction we observed. It did not establish full accessibility conformance. We did not test every screen reader, browser, zoom level or article, and a focusable scrolling area alone does not make a complex table understandable.
This was also not a speed benchmark. We did not collect Core Web Vitals or Lighthouse scores, so no loading-performance improvement can be claimed from these measurements.
For readers comparing offers, the useful principle is practical: keep the labels and their values together, make hidden columns discoverable, and avoid treating a clipped cell as a complete offer. Our cost-comparison guide applies that approach to entry fees, optional purchases and unknown charges.