Let the table scroll while the article stays in place

Explore a small example

This isolated example explains the structure. The article records what has actually been verified.

I do not begin by making every cell smaller

Continually shrinking text to fit every column onto a phone can defeat the purpose of the table. The criteria still exist, but visitors cannot make a useful comparison if sentences are unreadable in tiny cells. I first identify which relationships the information needs to retain.

Preserving horizontal relationships may help when several options must be compared across the same row. If each item can be understood independently, a mobile card layout may suit it better. Converting a table to cards requires restoring the relevant label for each value and reviewing the reading order. Stacking cells while removing their criteria does not preserve the same information.

I give the article and the table separate width responsibilities

The inspected implementation limits the wrapper to the article’s width and permits overflow inside that wrapper. The inner table retains a minimum width suitable for reading. The table may be wider than a phone while the surrounding article remains inside the screen.

Setting only the inner table’s minimum width can cause a grid or flex parent to grow with it. I check that both the wrapper and the reading container can shrink. Hiding overflow on the whole document may conceal a wrongly enlarged area and make clipped content harder to find. I identify the source of the overflow and put the scrolling boundary there.

I explain that the table can move

If a phone shows only part of the second column, a visitor may not realize more columns exist. I add a visible instruction before the table explaining how to inspect the full width. When important information is initially outside view, visible scroll affordances and treatment of the first column also need a rendered review.

Touch and mouse interaction are not the only requirements. The original source makes the region focusable and connects it to a name. This example also retains a visible focus outline and links the region to its heading and hint. A tabindex alone does not guarantee keyboard scrolling in every browser. Entering, moving within and leaving the area should be checked with actual keyboards and assistive technology.

I preserve the relationship between headings and values

Building a visually attractive table from generic div elements means implementing its relationships separately. I use native table structure with a caption explaining the table as a whole. Column headers have scope="col", and row criteria have scope="row". An article heading and a table caption serve different purposes, so the table retains its own explanation.

This is a simple comparison with one header row. More complex, merged headers may need additional associations; this example should not be assumed sufficient for them. Multiple tables on one page also need distinct heading and hint IDs so one region does not inherit another table’s name.

<section class="comparison-block">
  <h2 id="comparison-title">Choose a publication workflow</h2>
  <p id="comparison-hint">Scroll this table sideways to see every column.</p>
  <div class="comparison-scroll" role="region" tabindex="0"
       aria-labelledby="comparison-title"
       aria-describedby="comparison-hint">
    <table>
      <caption>Synthetic comparison: two example approaches</caption>
      <thead><tr>
        <th scope="col">Question</th>
        <th scope="col">Approach A</th>
        <th scope="col">Approach B</th>
      </tr></thead>
      <tbody>
        <tr><th scope="row">What changes?</th>
          <td>Content records</td><td>Generated files</td></tr>
        <tr><th scope="row">What needs checking?</th>
          <td>Versions and publication state</td>
          <td>Build output and route availability</td></tr>
      </tbody>
    </table>
  </div>
</section>

I keep the scrolling rules inside the table area

The CSS below gathers only the rules needed for this new explanatory table. The outer region respects the reading width, while the inner table retains space for its content. The 40rem minimum is a starting point, not a standard for every table. It should be adjusted for the real number of columns, sentence length and text size.

I retain a fallback for long strings without imposing nowrap on every cell. Long explanations benefit from ordinary wrapping. A short identifier or date may need to remain together, in which case that specific cell can receive a separate treatment. Preventing all table text from wrapping can increase the width unnecessarily.

.comparison-block { min-width: 0; max-width: 100%; }
.comparison-scroll {
  width: 100%;
  min-width: 0;
  max-width: 100%;
  overflow-x: auto;
  border: 1px solid #cbd2cd;
}
.comparison-scroll:focus-visible {
  outline: 3px solid #2d6a51;
  outline-offset: 3px;
}
.comparison-scroll table {
  width: 100%;
  min-width: 40rem;
  border-collapse: collapse;
  line-height: 1.6;
}
.comparison-scroll caption {
  padding: 1rem;
  text-align: left;
  font-weight: 700;
}
.comparison-scroll :is(th, td) {
  padding: 1rem;
  border-bottom: 1px solid #dce0dd;
  text-align: left;
  vertical-align: top;
  overflow-wrap: anywhere;
}
.comparison-scroll thead th { background: #edf2ee; }
/* If the parent is a grid, use minmax(0, 1fr) for its content track. */

I check document overflow and table overflow separately

A review can compare scrollWidth and clientWidth on the document, then compare those values inside the table wrapper. The intended result is no horizontal document overflow and internal overflow only where the narrow screen needs it. Measurements should be paired with reading and interaction because a column or focus outline can still be clipped.

Historical notes record no mobile document overflow together with internal table scrolling. Some explicitly limit their keyboard claim to focus on the table rather than a full page traversal. I preserve that limit. The new HTML and CSS here have been prepared from inspected structure; this is not a report of a current desktop, mobile or screen-reader review of the example.

1. Does the table leave the body and headings inside the screen?
2. Can a visitor reach the final column and then leave the region?
3. Are the focus indicator, instruction and table name usable?
4. Do header relationships remain clear with enlarged text?
5. Are IDs unique when the page contains several tables?
6. Are required columns preserved when printing or sharing?

I preserve a small change that protects the information

Removing the table can simplify a mobile page while also removing the reason for comparison. Smaller type can satisfy a width target while making the values harder to read. I chose a boundary that lets visitors read the article comfortably and inspect the table’s necessary relationships.

The reusable idea is this division of responsibility, more than a particular color or column count. Explain how wide the table can be, who can navigate within it, and which criteria its values refer to. That makes the module possible to review and apply again as the content grows.