DSG-04
Clipped text
What the check measures
The finding goes to an element meeting both conditions at once: its CSS hides overflow (overflow: hidden or clip) and its content is genuinely wider than what is visible. It is not a guess. The element really is concealing something.
The report distinguishes two cases, and they are worth separating when fixing too: with an ellipsis (the text ends in “…”, so at least it is visible that there is more) and with no indicator (the text simply stops mid-way with nothing to suggest it). The second is worse.
It is measured at three widths (390, 768, 1440 px) and severity rises to critical when the same problem appears at enough viewports of one page. The three measurements are merged into one report row.
What the check does not do: it does not judge whether the clipping is intentional (in multi-row listings it usually is), it does not distinguish clipping by two characters from clipping half a sentence, and it cannot see vertical clipping, only horizontal. The finding is page-level, with an annotated screenshot.
How strong the evidence is
We recommend it because it does no harm or has some other benefit, but we promise nothing about whether it makes language models cite you. Nobody has demonstrated that yet.
For visibility in AI answers there is no effect. And it is worth saying why here in particular, because it gets confused: the clipped text is still in the HTML. A model and a search engine read all of it; only CSS hides it in the browser. This finding is therefore exclusively about people.
And about people it is rather fundamental. The variant without an ellipsis is the dangerous one: a visitor has no way of knowing the text continues. A price that ends mid-number, a product name missing a crucial part, an address without the house number: that looks like complete information and is not.
Where it is intentional and the finding is a false alarm: single-line listings, article previews, catalogue tiles. There text is clipped deliberately and the full version is one click away. Ignore the finding when you know it is meant to be that way.
Where it is almost never intentional: buttons, headings, navigation items and values in forms. A clipped button leaves no way of telling what it does. And that is a defect regardless of design.
How to fix it
First decide whether the element is supposed to clip. That gives three routes:
- It should not clip → remove
overflow: hiddenand let the text wrap. For long words and URLs,overflow-wrap: anywherehelps. - It should clip, but visibly → add an ellipsis. Without
white-space: nowrapandtext-overflow: ellipsisthe ellipsis will not appear. - It should clip over several lines →
-shows the first three lines and suggests the rest.webkit- line- clamp
/* One line with an ellipsis */
.name {
overflow: hidden;
white-space: nowrap;
text-overflow: ellipsis;
}
/* Three lines, then an ellipsis */
.excerpt {
display: -webkit-box;
-webkit-line-clamp: 3;
-webkit-box-orient: vertical;
overflow: hidden;
}Two things not to forget with this fix:
- The clipped text must be available somewhere. When a tile cannot fit the whole name, it must be in
title, in the detail view, or at least on hover. An ellipsis says “there is more”; somewhere that more must exist. - Never clip buttons and links. Let the label wrap onto two lines instead; a button whose purpose is unclear is worse than a button one pixel taller.
What the report says about it
Finding description
At widths [viewports] px we found text that is visually cut off (the overflow is hidden via `overflow: hidden`). Without an ellipsis ("…") visitors have no way to tell content is missing; with an ellipsis they at least see the text continues, but the hidden content stays inaccessible.
Recommendation
Either give the element enough room (or let the text wrap to more lines), or at least add `text-
Sources
- MDN: text-overflow (accessed 2026-09-12)
- W3C WAI: Reflow (WCAG 1.4.10) (accessed 2026-09-12)
Text verified 2026-09-12