A website can pass every functional test and still look broken on launch day. The form submits, the menu opens and the checkout works, yet on a real phone the headline wraps over the button, a card sticks past the screen edge and the sticky header covers the first line of text. Visual QA is the separate pass that checks how a site looks, not only whether it works — run it at real widths, against the approved design, before sign-off.
The short answer: the visual QA pass in one checklist
Work through one template at a time on staging, recording every defect with a screenshot and the exact viewport width where it appears.
| Check | What you are looking for |
|---|---|
| Breakpoint sweep | Layout holds while resizing continuously |
| Horizontal overflow | No sideways scrolling or clipped content |
| Spacing and alignment | Consistent gaps and shared edges |
| Typography | One type scale, no clipped or overflowing text |
| Images and media | Correct crop and file at each width |
| States and sticky elements | Menus, hovers and headers never cover content |
| Tap targets | Buttons and links large enough to tap accurately |
| Sign-off triage | Every defect marked launch-blocker or fix-after |
Fix launch-blockers first, agree the fix-after list in writing, then re-check the same widths.
The problem: functional tests pass, the site still looks broken
Functional testing asks whether things work: does the form send, does the link resolve, does the payment complete. Visual defects live in a different layer. A button can work perfectly and still sit off the grid, overflow its container on a smaller phone, or disappear behind a sticky header when the page scrolls.
These are the defects clients spot in the first minute. They also cluster between the widths in the design file: a layout mocked up at desktop and mobile sizes can behave at both and still break at the tablet width nobody opened, or mid-resize, where columns squeeze before they stack.
Set up the pass: staging, real devices, and resizing between breakpoints
Run the pass on staging with final content in place: placeholder text hides overflow and dummy images hide cropping faults. Test the homepage plus one template of each kind — service, listing, form and your longest page.
Combine three views. A real phone and tablet, because emulation misses device chrome and true tap behaviour. Browser emulation for the width list below. And a continuous resize: drag the window slowly from wide to narrow and back, watching for the moment anything overlaps, jumps or scrolls sideways. Between-breakpoint defects appear during that drag. Performance is a separate pass — our Core Web Vitals launch checklist covers the speed side.
The breakpoint sweep: what to look for at 375, 768, 1280 and beyond
Check each template at a spread of widths, not the two in the design file: 320, 375, 414 or 430, 768, 1024, 1280 and 1920 pixels, in portrait and landscape on phones and tablets. At every width ask: any horizontal scrollbar or sideways swipe, any element crossing the screen edge, columns stacking in the intended order?
At phone widths, hunt the classic overflow causes. A section sized at 100vw can overflow because the viewport unit includes the scrollbar width; sizing to 100% avoids it. Flex and grid children refuse to shrink below their content by default, so one long word or embed can push a whole row wide until a minimum width of zero is set. Full-height 100vh sections can hide their last line behind mobile browser chrome; MDN documents dvh, the dynamic unit that tracks visible height instead.
At tablet widths, check the in-between states designers skip: navigation caught between a full menu and a hamburger, grids with one orphaned card, sidebars squeezing text into a ribbon. At desktop widths, check over-long text lines and content drifting apart where a layout has no maximum width.
Spacing and alignment: auditing the rhythm of the page
Most builds use a spacing scale, so the same gaps should repeat everywhere. Audit the rhythm section by section: gaps around headings should match across pages, and cards in a row should share edges and equal padding, with buttons aligned even when one card has longer text.
Look for padding collapse: sections touching on mobile because a margin was removed at that breakpoint, or a background colour ending before its content does. Small drifts make a page feel untidy even when a visitor cannot name the fault.
Typography and content overflow: the text bugs everyone sees
Typography defects are the most visible. Check that headings use one consistent scale and weight at every width, and that body text never falls below a readable size on mobile. Then test with real words, not neat placeholders: the longest service name, the longest testimonial and an unbroken string such as an email address.
Hunt for text escaping its container: labels wrapping inside a button, prices pushing out of cards, table cells stretching a layout, headlines clipped by a fixed-height hero, and headings ending in a single orphaned word.
Images and media: cropping, stretching and the wrong file at the wrong width
Check every image at every width for three faults. Distortion: the aspect ratio changed in CSS, so faces and products stretch. Cropping: a fixed crop cuts the subject at one width — often a hero whose focal point leaves the mobile frame. Wrong file: a heavy desktop image served to phones, or a small file scaled up until it blurs.
Test the awkward cases: no image at all, a tall portrait image in a landscape slot, and a video or map in place of a still.
States and sticky elements: menus, headers, hovers and overlaps
Static screenshots miss state bugs, so work through the interactive states visually. Open and close the mobile menu at each phone width and in landscape. Check dropdowns against the content beneath them, and cookie banners and chat widgets against the content they may cover on small screens.
Sticky headers cause a signature family of defects: the header covers the heading an anchor link jumps to, or content slides under a transparent header and becomes unreadable. WCAG 2.2 makes one version a formal criterion, Focus Not Obscured: a focused element hidden behind sticky content blocks keyboard users, and the same overlap annoys everyone. Also check hover-dependent content, which touch users can never trigger, and that focus indicators stay visible.
For tap targets, three published references apply. WCAG 2.2 sets a minimum of 24 by 24 CSS pixels at level AA; its enhanced AAA criterion asks for 44 by 44. Apple's Human Interface Guidelines recommend 44 points and Google's Material Design recommends 48 density-independent pixels. Treat anything under the WCAG floor as a defect.
Report bugs so they get fixed first time: screenshot, width, severity
A visual bug reported as "the homepage looks off on mobile" will bounce back and forth. A report a developer can act on first time carries five things: an annotated screenshot with the defect circled, the page URL, the exact viewport width and device or browser, what the design shows instead, and a severity.
Use two severities only. Launch-blocker: overflow, overlap, unreadable text, an unusable menu or a broken layout on a common width. Fix-after: a minor spacing drift or edge case, agreed in writing. Triage turns a defect list into a launch decision a client can sign.
Common mistakes
The most common mistake is checking only the widths in the design file, which guarantees the between-breakpoint defects ship. Close behind is signing off on placeholder content, then finding real headlines, prices and names overflow containers that dummy text never stressed.
Other frequent errors: testing in emulation only and never on a real phone, reporting defects without widths or screenshots so they cannot be reproduced, and re-checking only the fixed defect instead of the whole width range after changes.
FAQ
What is visual QA, and how is it different from functional testing?
Functional testing checks that features work: forms submit, links resolve and payments complete. Visual QA checks how the site looks at real widths — layout, spacing, typography, image crops and overlaps — against the approved design.
Which screen widths should I test before launch?
Test a spread covering real devices and the gaps between them: 320, 375, 414 or 430, 768, 1024, 1280 and 1920 pixels. Also resize continuously between widths, where many defects live.
Why does my website scroll sideways on mobile?
Sideways scrolling means some element is wider than the viewport. Common causes are a section sized at 100vw, which includes the scrollbar width, flex or grid children that refuse to shrink below their content, an oversized image or embed, or a long unbroken word.
How big should tap targets be?
WCAG 2.2 requires at least 24 by 24 CSS pixels at level AA, with a spacing allowance, and its AAA criterion asks for 44 by 44. Apple's Human Interface Guidelines recommend 44 points and Google's Material Design recommends 48 density-independent pixels.
What should a good visual bug report include?
Five things: an annotated screenshot with the defect marked, the URL, the exact viewport width and device or browser, what the approved design shows instead, and a severity of launch-blocker or fix-after.
If the QA pass finds too much (CTA)
A short defect list means the build was sound. A long one, full of overflow and overlap on common widths, usually means the build needs professional attention rather than more patches. Our fixed-price web design packages cover a scoped rebuild. Where a redesign is the answer, our website redesign SEO migration checklist covers protecting rankings through the change. Or bring your defect list to our web design company in Dubai: tell us which widths fail, and we will tell you plainly whether it needs fixes or a rebuild.
