Element extends outside the visible area

At all three measured widths we check whether the right edge of an interactive element (link, button, field, select) extends past the right edge of the window. The finding is only raised when all of this holds at once: the page really does scroll horizontally at that width, the element reaches past the right edge of the window, and after clipping by its ancestors some visible area is left out there. The finding then carries the measured numbers, including the document width.

It differs from DSG-01 in what is measured. DSG-01 reports that the document as a whole is wider than the window. DSG-06 reports a specific control that lies partly outside the visible area on such a page. DSG-06 therefore cannot occur without DSG-01: since 20 September 2026 both conditions are required together.

A deliberate gap, and it is fair to admit it: a page that cuts the overflow off (overflow-x: hidden on html/body) and cannot be scrolled is the worse case: the element is unreachable for good. DSG-06 does not report it, because its wording talks about horizontal scrolling and there is none. Look for that case through DSG-01 and DSG-04.

What the check does not do: it does not watch for overflow to the left or downwards, it cannot see elements revealed only after an interaction, and it cannot judge whether an element is hidden deliberately (parking elements off screen for screen readers is standard practice). Severity rises to critical on broad impact across viewports; the finding comes with an annotated screenshot.

For visibility in AI answers there is no effect. But there is a direct impact on whether a visitor can reach what they need on the page.

The distinction that decides the severity for you: if an element is off screen and the page can be scrolled sideways, it is an inconvenience, and that is exactly the case DSG-06 reports. If the overflow is hidden and it cannot, the element is unreachable. And when it is the “Submit” or “Add to basket” button, that is not a design defect, it is a broken function; that case is carried by DSG-01, not by this finding.

Until 20 September 2026 the finding did not distinguish those two cases. Today it reports only the first and openly leaves out the second. The report gives you coordinates and a screenshot; judging the impact is yours.

Where it is a false alarm: elements deliberately parked off screen, typically a “Skip to content” link that appears only on Tab. That belongs there and the finding on it can be ignored. A closed off-canvas menu (zero width, clipped content) is no longer a false alarm: its items do sit past the window edge by coordinates, but none of them is visible and they are reachable by opening the menu. On a Shoptet e-shop that produced 240 untrue occurrences in a single audit until 20 September 2026.

The cause is usually one of three, and you find it by looking at the overflowing element's parent rather than at the element itself:

1. A fixed pixel width. width: 320px inside a container with 358 px usable on a phone. Fix: max-width: 100%.
2. A horizontal row that does not wrap. Buttons in a flex without flex-wrap: wrap squeeze together and the last one slides out.
3. An absolutely positioned element whose coordinate was computed for a wide screen: a dropdown, a tooltip, a floating button.

/* A row that can wrap */
.actions {
  display: flex;
  flex-wrap: wrap;
  gap: 0.5rem;
}
.actions > * {
  max-width: 100%;
}

For dropdowns and tooltips that slide out, letting the browser position them is more reliable than computing it. Modern CSS can anchor them so they flip inward when they would overflow.

And a check worth more than any tool: open the page on a phone and try to complete the task people come to the site for: fill in the form, finish the order. An unreachable button finds itself.