Free guideEditorial review in progress; your agent sees whether each guide's current version is reviewed. What “reviewed” means

Pre-launch design QA checklist for marketing and content sites

A single gate run on every public template before launch: content and claims, layout at four widths, type and color tokens, states, accessibility (automated + manual), performance budgets, SEO/metadata, forms and legal — each with a concrete pass condition and evidence.

Discipline
Websites
Type
Verification rule
Platforms
Website, Web app
Version
1.1.1 · 2026-09-26

Overview

What: the final checklist an agent or reviewer runs before a site (or template) is published.

Why: most launch defects are not exotic: a missing focus style, a success message that lies, an oversized hero image, a placeholder logo, a broken mobile crop. They slip through because checks live in people's heads. GOV.UK's audit of automated accessibility tools showed that tools together still missed a substantial share of barriers — so a checklist must combine automated and manual steps. This gate operationalizes Motif's doctrine: evidence over assertion.

Use on every template/page type (not every URL): home, listing, detail, pricing, contact, legal, 404.

Implementation

Run each block; record pass/fail, tool, date and screenshots in acceptance-checklist.md.

  1. Content & claims — no lorem ipsum, placeholder names, or TODOs (grep); every metric/testimonial/logo in the evidence register; prices and limits match billing configuration; dates current.
  2. Layout — screenshots at 360, 768, 1280, 1600; 320px reflow without horizontal scroll; at least one recomposed section on mobile; no text over images below contrast.
  3. Tokens — no raw hex/px outside token files; type roles ≤ 8; spacing on scale.
  4. States — hover, focus-visible, active, disabled; form idle/submitting/success/error; empty and no-results; loading skeletons with final dimensions; offline/failure messaging where data is fetched.
  5. Accessibility — axe (or equivalent) zero violations; manual keyboard pass; screen-reader smoke test (VoiceOver + NVDA or TalkBack) on nav, forms and dialogs; 200% zoom and text-spacing override; WCAG 2.2 new-criteria checks; reduced-motion pass.
  6. Performance — Lighthouse mobile median of 3: LCP ≤ 2.0 s lab, TBT ≤ 200 ms, CLS ≤ 0.05; budgets met; LCP image prioritized.
  7. SEO/metadata — unique titles/descriptions, canonical, OG image per key page, sitemap, private routes non-indexable and authenticated; 404 returns 404.
  8. Forms & integrations — real submission tested end-to-end or demo mode clearly labeled; emails received; error paths tested offline.
  9. Legal & consent — required policies linked; consent banner behavior verified in a fresh profile.
  10. Cross-browser — latest Chrome, Safari (macOS + iOS), Firefox; one physical Android and one physical iPhone.
  11. Sign-off — reviewer name, date, open issues with severity; no launch with open severity-1 issues (broken task, false claim, inaccessible primary flow).
  12. Gate artifacts — design-note.md with one section per page (composition, card budget, forbidden defaults rejected, product-proof declaration) and design-score-sheet.md with one verdict per page (overall ≥ 4.0, no axis ≤ 2, zero hard-fails) exist and are stored with the build (web-design-gate-workflow, web-anti-slop-rubric-scored).
  13. Hard-fail lint — the eight DOM/CSS signatures run against the built pages with output stored; for multi-page builds and template families the cross-page differentiation check (HF-9) is clean.
  14. Proof residue — grep for template strings, placeholder names, # hrefs on proof items, stock filenames; name/address/phone identical in header, footer, contact page and structured data; every badge/award/press mention links externally (web-anti-placeholder-proof-residue).
  15. Product media classification — every static media node in <main> carries an allowed role (identity, editorial-photography, supporting-screenshot with date/version) or sits in a live/runnable/recording container; no screenshot gallery as proof (web-product-proof-hierarchy).
  16. Cross-type norms — two chrome colors + one accent (or justified), every rendered number sourced per figure, one aspect ratio per media class, constraints stated as honesty bands.

Verification

  • acceptance-checklist.md exists with all 11 blocks recorded for each template type.
  • Evidence (screenshots, reports) stored with commit hash.
  • Zero severity-1 issues open at launch.
  • Automated and manual accessibility results both recorded — automated alone is not accepted.
  • Re-run after any change to shared components (header, footer, tokens).
  • Design note and score sheet present for every page; lint output stored; HF-9 clean for multi-page builds.
  • Residue grep and NAP consistency check recorded with command and result.
  • Media-role audit: zero unclassified static media inside <main>.

Sources:

Limitations

  • A checklist catches known failure types; usability testing with real visitors is still needed to find comprehension problems.
  • Physical-device and screen-reader checks take time; prioritize the primary conversion path if time-boxed.
  • Passing this gate is not a legal accessibility conformance claim.
  • Values verified 2026-09-26: all 9 numeric values in this item were checked (4 against published standards, 4 against platform documentation, 1 in Chromium lab tests) and confirmed; no corrections were needed.