toolkit

Scenario · Content and search

Redesign this section

“This part of the page looks dated — can you rework it?”

Redesigning one part of a page is the highest-risk routine change there is, because it replaces working markup with brand-new markup instead of editing it — the old section was accessible and responsive mostly by accident of having survived this long, and the new one starts having proved nothing. This captures exactly what the old section looked like and contained before anything changes, then checks the new one on real screen sizes, for accessibility and load cost, and diffs the actual wording against what came before — because a rebuilt section loses a paragraph or a call-to-action far more often than anyone expects, and only that comparison catches it.

What to ask for

Layout / front-end QAFront-end / layout QA for a live page — measures the rendered DOM across device presets and flags objective layout defects: horizontal overflow, tap targets too small, text below the legible floor, skipped heading levels, DOM bloat, interactive elements whose contrast passes at rest but fails on hover or focus, a mobile nav toggle that reveals nothing, and viewport meta defects (missing or blocking zoom).ScreenshotsCapture multi-device screenshots of any URL from the command line — one PNG per device preset (iPhone → Desktop 4K), headless, on a Playwright core.Accessibility (a11y)Accessibility scan for a live page — runs axe-core (Deque) across device presets and scores the page against WCAG, returning an absolute PASS / REVIEW / FAIL verdict plus a self-contained HTML report grouped by impact.Performance (Core Web Vitals)Core Web Vitals and performance scan for a live page.Motion & animation auditMotion and animation audit for a live page — reads the page's authored CSS inside a real rendered browser and returns PASS / REVIEW / FAIL plus a self-contained HTML report.Before/after checkBefore/after verification for a change to a live page — the safety net for the small edit that doesn't justify a staging round-trip.

See it work

A real run of Layout / front-end QA:

Layout / front-end QA · layout-front-end-qa — https://toolkit-tests.pages.dev/layout/overflow.html
  measuring layout across desktop,iphone-17 …

FAIL — https://toolkit-tests.pages.dev/layout/overflow.html
  1 error  0 to review  1408px overflow  16 nodes
  ✗ error  overflow content overflows the viewport by 1408px on iphone-17 — horizontal scroll (offenders: div)

  report: ./out/layout-front-end-qa-layout-front-end-qa.html
  json:   ./out/layout-front-end-qa.json
  text:   ./out/layout-front-end-qa-layout-front-end-qa.txt

The captured report, exactly as a run hands it to a client —open the full report ↗

A redesign is the highest-risk routine change on a page, because it replaces working markup with new markup rather than editing it. The old section was accessible and responsive by accident of having survived; the new one has proved nothing.

  1. Capture the section as it is, thoroughly. Screenshots across every device preset, and a before/after snapshot of the page. On a redesign this is not a formality — it is the only record of what content the section used to carry, and step 6 depends on it.
  2. Agree what must survive. The headings, the call-to-action, the phone number, whatever the section was actually there to do. Write it down before it is rebuilt, because “we removed the booking button” is discovered weeks later by whoever is looking at conversions.
  3. [manual] Build the new section. In the CMS or the page builder, reusing existing components over new ones where possible — a bespoke section is a bespoke maintenance and responsive-testing burden. Publish and purge.
  4. Check the layout on real viewports. The layout check finds overflow, collapse and overlap; the screenshot set across desktop, tablet and phone shows what it looks like. A new section that works at 1440px and breaks at 768px is the normal outcome of building one, not an unusual one.
  5. Check accessibility and cost. Contrast, focus order and keyboard reach on the new markup, and a performance re-measure — a redesign that introduced a full-width background image or a web font is a redesign that has a load cost. If it animates, audit the motion: a section that ignores reduced-motion preferences is a defect, not a flourish.
  6. Diff the content against step 1. Read the before/after word-level diff and confirm nothing that mattered vanished. This is the check that a purely visual review always skips.

Rebuilt, not edited

The distinction runs through this whole procedure. An edit inherits the old section’s accessibility, responsiveness and content; a rebuild inherits none of them and has to earn each one back. Treating a redesign as a content change is how a page ends up prettier and worse.

What this does not cover

Whether the new design is better. Every check here grades the *consequences* of a redesign — layout integrity, contrast and keyboard reach, load cost, motion — and none of them has an opinion on taste, brand fit, or whether the section now says what the practice wanted. It also cannot tell you that the redesign quietly dropped content: a section rebuilt from scratch loses a paragraph or a call-to-action more often than anyone expects, and only reading the before against the after catches it.

← All scenarios