Catch the bugs you can see.
Find cut-off text, covered buttons, broken images, and low contrast on every page the agent visits, with a screenshot of each. They are findings, never test failures.
Mechanism: Layout checks that run inside the live page on every page a survey or discovery run visits, with an optional Gemini review of page screenshots.
The problem: Assertions find the element, so a button covered by an overlay or cut off by the edge of the screen still passes. Text that is clipped or spills out of its box, and images that never loaded, are in the DOM and look fine to a test. Low text contrast is easy to ship and rarely checked until someone complains. Layout checkers are often so noisy that teams turn them off, because they flag every truncated label and every cookie banner.
Check every page the agent visits — The checks run on each page a survey or discovery run loads. There is nothing to configure and no separate crawl: the pages the agent already visits while it maps your app are the pages that get checked.
Run the checks inside the page — The checks run in the live page itself, in the same browser that is exploring your app. They need no AI: there is no prompt and no model call in this path. On a demo page it takes about 150 to 200 ms per page.
Look for five kinds of problem — Text that is cut off (clipped by its box or a container) or spills out of its box. Buttons and links that are covered by another element so they can't be clicked, or cut off by the edge of the screen. An overlay that blocks the page and offers nothing to click. Broken images. Low text contrast, using axe-core's color-contrast rule, with serious violations only.
Skip what sites do on purpose — Low noise is the design goal. Ellipsis and line-clamp truncation, screen-reader-only text, carousels and horizontal scrollers, collapsed menus and accordions, off-canvas drawers, decorative fades, sticky headers, cookie banners and modals, tracking pixels, lazy images below the fold and icon fonts are all skipped. Findings are capped per page.
Save each finding with evidence — Every finding has a cropped screenshot of the element, a CSS selector, its position on the page, a plain-English description and a severity of high, medium or low. Findings show up in Site Intelligence (a badge on each page, boxes drawn on the page screenshot, and a Visual issues tab with filters and a dismiss-all-on-this-page button), on each discovery session, in a Visual tab on each feature, and in a Visual issues panel in Reports.
Triage them, never a test failure — Visual issues are findings, like security findings, so they never fail a test. You can flag one as a bug or dismiss it, and the decision is remembered on later runs. An issue that no longer shows up on a page that has been checked again is marked fixed.
Optionally add a Gemini review — Once an admin saves the team's Gemini API key in Admin AI Settings, an AI visual review runs too, with a switch on the same page to turn it off. A Gemini Flash-class model looks at page screenshots, only for pages that changed or already had layout findings, and at most 30 pages per run. Only high-confidence hits (0.8 or above) go to a Gemini Pro-class model to confirm. Confirmed hits appear as Possible visual issue suggestions next to the layout checks, and are never test failures.
Hand the findings to your coding agent — The MCP server has a list_visual_issues tool, so a coding agent in Claude Code, Cursor or a similar tool can find the element and fix it. The project overview over MCP includes visual counts too.
Open Visual & layout checks · Get Started Free