Horizontal overflow risk

What this check looks for

This check scans inline CSS for width/min-width declarations over 430px, checks whether the viewport meta tag declares a fixed numeric width instead of device-width, and checks width attributes on images, tables, and iframes for values over 430px. Any of these found warns, listing each hit with its pixel value. None found passes.

Why it matters

Any element wider than the phone's own viewport forces the whole page into horizontal scroll mode, which is a jarring, broken-feeling experience — visitors expect a mobile page to fit its screen and scroll only vertically, and a page that doesn't gets abandoned quickly. A hardcoded numeric viewport width is a particularly severe version of this, since it overrides the responsive behavior for the entire page rather than one element. This class of bug is usually a leftover from a desktop-first design that was never properly adapted, or a single legacy table or embed with a hardcoded pixel width nobody revisited for mobile. Like other mobile-usability checks, this feeds into the page-experience quality search engines evaluate on top of pure content relevance.

How to fix it

Replace fixed pixel widths with responsive units, and never set a numeric viewport width:

<!-- Forces horizontal scroll on any phone narrower than 600px -->
<table width="600">...</table>
<meta name="viewport" content="width=600">

<!-- Fixed: responsive table wrapper, standard responsive viewport -->
<div style="overflow-x: auto; max-width: 100%;">
  <table style="width: 100%;">...</table>
</div>
<meta name="viewport" content="width=device-width, initial-scale=1">

For wide tables or embeds you can't shrink, wrap them in a horizontally scrollable container so overflow is contained rather than affecting the whole page.