On a 320 CSS pixel viewport, one of my data-heavy notes was 460 pixels wide. Its first table had six columns and was 436 pixels wide on its own. The extra width did not stay inside that table. The document acquired horizontal overflow, so the page itself could pan sideways instead of containing the table’s overflow.
That was one public page, observed once. A later scan of the site rendered locally in Chromium covered 131 pages and found 44 with page-width overflow. I treat that count as what it is: a measurement of my local build, not a fresh census of the live site, and not a breakdown of what caused each overflow.
A table sizes itself to its content. Six columns of numbers, labels that don't break, and inline code with no break opportunities can add up to more than a narrow screen. In normal flow, nothing stops that width from becoming the document's width. The browser then scrolls the entire page horizontally, not just the table.
The W3C's Understanding Reflow document draws the distinction I needed. Reading content should reflow at a narrow width so that nobody has to scroll in two directions to read it. Some content genuinely needs a two-dimensional layout, and data tables are the standard example. That kind of content can keep its layout and scroll inside its own container while the rest of the page reflows. This does not make every scrolling table automatically acceptable. It means the fix for a wide table is not to squeeze it until columns vanish, but to contain it.
The obvious move is to open the site's CSS and add a rule. That would change something, and prove nothing about the next article.
New notes are not styled by a shared stylesheet. They are generated by a converter, md2canonical.py, that turns a Markdown draft into a standalone HTML page. For its CSS, the converter reads the <style> block of one specific existing note and reuses it. Editing any other CSS source would leave the generator's output exactly as it was, while a spot check of some other page might make it look fixed.
So the repair had to live in the converter, because that is the path the next article actually takes. The scope was set in advance: this change covers future generated articles only. Retrofitting old pages was explicitly excluded, so this repair did not retrofit the 44 overflowing pages from the scan.
The converter now wraps each Markdown table in a scroll container. The output looks like this (illustrative, with the label taken from my test sample):
<div class="table-scroll" role="region" tabindex="0"
aria-label="Table 1: Output tokens per thread by role">
<table>…</table>
</div>The wrapper is a named region, so assistive technology can announce it, and tabindex="0" makes it focusable, so a keyboard user can scroll it. The name is "Table N:" followed by the nearest preceding heading. No columns are dropped or hidden. All the data is still there; you scroll to it inside the box.
The CSS that goes with it is small. The container gets overflow-x: auto, max-width: 100% and a visible focus style, and the body gets overflow-wrap: break-word so long inline code wraps instead of pushing the page out. These rules live in a block called READING_STYLE, appended once after the inherited template style. If the template already contains it, the converter doesn't add it again.
While I was in the converter, every body h2 and h3 also got a unique ID so sections can be linked, with a numeric suffix for repeated headings. Two headings were deliberately left alone: the exact "FAQ" and "Related notes" h2 strings. Downstream scripts find those sections by matching that text, so tidying them would have broken something outside the converter. The converter's tests now check that those strings survive.
The check that matters is not "does the table scroll". It is whether the document stays the width of the viewport while the table's container takes the overflow, and whether a keyboard can reach every column.
I generated a new synthetic note with the production converter: a six-column table, a long run of inline code and a repeated heading. I rendered it with JavaScript off at three viewports. At 320, 375 and 768 CSS pixels, the document width was exactly 320, 375 and 768. In the table region, pressing Tab to focus it and then the right arrow key moved scrollLeft to 229, and scrolling reached both ends of the table. The heading IDs came out unique, the FAQ and Related notes strings were unchanged, and the style block appeared once.
On the test side, 137 converter, localization and analytics tests passed, and 59 tests for the curation script passed. A separate offer-exposure suite ran 63 passing tests and 1 failing one. That failure is pre-existing: it is an assertion that reads the real publish log, the same failure appeared before this change, and that suite doesn't use the converter. I'm not describing the run as all green, because it wasn't.
The rendering checks ran in Playwright's Chromium against local file:// pages. I did not test Safari, a screen reader or a physical phone. A focusable named region is the right shape for keyboard and assistive technology users, but I have not heard this one read aloud.
The repair covers articles generated from now on. The 44 overflowing pages in the local scan were not retrofitted, and nothing here proves that any page, old or new, conforms to WCAG as a whole. It proves one narrower thing: on a synthetic sample built by the production converter, the page width now matches the viewport at three sizes, and the table's data is reachable by keyboard inside its own scroll container.
Two habits came out of it. Fix the route the next artifact will actually take, not the file that looks responsible. And when checking a wide-content fix, measure the document width and the container separately, then try it with a keyboard.
An uncontained wide table can create page-level horizontal overflow. The repair puts the table in its own scrollable region so the rest of the page can reflow, rather than hiding columns.
The W3C's Understanding Reflow document treats content that needs a two-dimensional layout, such as data tables, differently from reading text: it can scroll within its own container while the rest of the page reflows. That does not make every scrolling table automatically accessible, and this work did not establish WCAG conformance.
New notes are built by a converter that reuses the style block of one specific existing page. Editing any other CSS source would not change what the converter produces, so the scroll wrapper and wrapping rules went into the converter, the path the next article actually takes.
A synthetic note built by the production converter, with a six-column table, long inline code and a repeated heading, was rendered with JavaScript off. At 320, 375 and 768 CSS pixels the document width was exactly 320, 375 and 768, and Tab then the right arrow key moved the table region's scrollLeft to 229. Only Playwright Chromium over file:// was tested, not Safari, a screen reader or a physical device.
No. A local Chromium scan of 131 rendered pages found 44 with page-width overflow, and retrofitting old pages was excluded from this change. The repair applies to notes generated from now on.