Text printed over other text

For every element with text of its own the check takes the boxes of that text's rendered lines (Range.getClientRects()) and looks for pairs of elements whose lines intersect. The intersection has to exceed a couple of pixels in both dimensions: two adjacent lines touching at the edge is not an overlap.

The point is that element boxes are not compared; text lines are. Text that overprints its neighbour has usually spilled out of its own box: a cell in a table-layout: fixed table, a fixed grid column, an element with white-space: nowrap. The boxes themselves do not overlap at all, so a check built on them would find nothing. In our own audit this defect was first spotted by eye on a screenshot; this is how to find it by machine.

What is skipped to avoid false findings: pairs where one element is an ancestor of the other (a descendant lies inside its ancestor by definition); pairs where either element sits in a positioned layer (position: absolute/fixed/sticky or under a transform): a dropdown, a sticky header or a modal covers content on purpose; and elements the visitor does not have on screen (the content of a closed <details>, screen-reader-only labels).

Thresholds and caps live in config/design.json (overlap). The finding is a warning; when it appears at two or more of the measured widths it is raised to critical. It counts towards the design score as a high problem: overprinted text is as unreadable as clipped text (DSG-04).

What the check does not do: it does not judge text overlapping an image or a background colour (that is contrast, COLOR-01), it cannot see an overlap that only appears after user interaction, and it cannot tell whether this particular overlap is acceptable to the author.

There is no effect on visibility in AI answers. Both texts are in the HTML in full; the overlap appears only when the page is rendered.

It is, however, the design finding a visitor notices first. An unreadable word on top of another word looks like a broken page even when everything else works. And because it only appears at some window widths, the site owner never sees it on their own laptop.

The accessibility link is indirect. WCAG 1.4.10 (Reflow) requires content to be presentable without horizontal scrolling; overlapping text is often the second symptom of the same layout that breaks that criterion. Claiming this finding measures conformance would be overreaching, though: we measure geometry, not a criterion.

A false finding is not ruled out. A few pixels of overlap can be intentional (a decorative underline, a number bleeding over a frame). That is why the finding is an invitation to look rather than a verdict, and why each one comes with a screenshot marking the spot, so judging it takes seconds.

The commonest cause is a fixed-width cell the text is not allowed to wrap in:

table { table-layout: fixed; }
td.code {
  width: 60px;
  white-space: nowrap;   /* the text will not wrap… */
  overflow: visible;     /* …and spills over the next column */
}

Either let the text wrap, or give it enough room:

td.code {
  width: 60px;
  white-space: normal;   /* wraps inside the cell */
  overflow-wrap: break-word;
}

• Grid and flex: an item with the default min-width: auto will not shrink below its content width and pushes it over its neighbours. Give it min-width: 0.
• Absolutely positioned labels (a number in a card corner, a badge over an image) should have space reserved in the normal flow, or a background of their own; otherwise they meet the content underneath at a width you did not test.
• Do not try to fix it with z-index. That decides which text is on top; the other one stays unreadable.
• Verify the fix at all three widths. An overlap typically appears at one of them and everything looks fine at the other two.