Guides
Web design quality assurance checklist for every launch
A web design quality assurance checklist orders launch testing: browsers, devices, forms, and ADA checks, each with a duration and a blocker.
What to take away
- A launch QA pass runs 5 to 15 working days for a typical marketing site, split into stages that cannot overlap.
- Nothing gets tested on staging until content is frozen and the staging environment matches production.
- Cross-browser and device coverage is the longest stage, usually 2 to 4 days, because it repeats on real hardware.
- Accessibility checks belong in QA, not after launch. The ADA is enforced by the U.S. Department of Justice, and private suits are common.
- The checklist stops mattering about 30 days after launch, once error logs and analytics are quiet.
The short version
A QA checklist is a sequence, not a list of good intentions. Each stage needs an entry condition and a duration. Skip the order and you retest the same pages three times.
Most agencies run QA as a single "test everything" day before launch. That produces shallow coverage and a launch week full of fixes. Staging the work costs the same hours and finds defects earlier, when they are cheap.
The stages below assume a marketing site of 10 to 40 templates with one form and one analytics stack. Larger builds scale the durations, not the order.
Stage by stage
- Content freeze and environment parity. Duration1 day. The client signs off on copy, images, and redirects. Staging is rebuilt from the same deploy pipeline as production.
- Functional pass. Duration1 to 2 days. Links, navigation, forms, search, and third-party embeds. Every form submission is tested with a real inbox.
- Cross-browser and device pass. Duration2 to 4 days. See the table below.
- Accessibility pass. Duration1 to 3 days. Keyboard paths, focus order, contrast, alt text, and form labels.
- Performance and analytics pass. Duration1 day. Core Web Vitals on mobile, tag firing, and conversion events.
- Launch and hypercare. Duration: 30 days. Daily log checks for the first week, then weekly.
| Stage | Typical duration | Blocking prerequisite |
|---|---|---|
| Content freeze | 1 day | Client sign-off on copy and images |
| Functional pass | 1-2 days | Staging built from production pipeline |
| Cross-browser and device | 2-4 days | Functional pass closed, no open P1 defects |
| Accessibility | 1-3 days | Content freeze, final templates |
| Performance and analytics | 1 day | Accessibility fixes deployed |
| Hypercare | 30 days | Successful production deploy |
A P1 defect blocks launch. Examples include navigation that fails, a form that does not submit, a checkout error, and an accessibility barrier that stops a keyboard user from finishing a task. P2 and P3 defects can ship with a dated fix plan.
Sign-off sits with one named person per stage. The client owns content freeze, the QA lead owns the functional and device passes, the developer on call owns performance and analytics, and the account manager owns hypercare.
Typical tooling: Screaming Frog for the link and crawl pass, BrowserStack plus two studio devices for cross-browser, axe DevTools or WAVE for accessibility, and Lighthouse or WebPageTest for performance. For hypercare, UptimeRobot and Sentry cover uptime and error logs.
What has to exist before what
The stage table sets the order. Environment parity and content freeze gate everything downstream, and stage 1 covers both. If staging runs a different server configuration, cache layer, or CMS version than production, every test result is provisional.
Accessibility testing also needs final templates. Retrofitting focus states and heading order after a redesign costs far more than testing them once.
For the standards themselves, the W3C's Web Content Accessibility Guidelines set the levels most US clients now ask for in writing, and web accessibility explains why the legal exposure is real rather than theoretical. Federal sites follow Section 508, summarized under the Section 508 Amendment.
Cross-browser testing for agencies
US traffic concentrates in a handful of engines, but the tail still costs money. Test the current and previous major versions of Chrome, Safari, Edge, and Firefox, plus iOS Safari and Android Chrome on real devices.
Emulators miss touch targets, font rendering, and scroll behavior. Keep two mid-range Android phones and one older iPhone in the studio for this stage. They pay for themselves in one avoided post-launch hotfix.
The checklist below is the minimum for the device pass.
| Device or browser | Versions | What to verify |
|---|---|---|
| Chrome desktop | Current and previous major | Forms, navigation, console errors |
| Safari desktop | Current and previous major | Inputs, date pickers, font rendering |
| Edge desktop | Current and previous major | Print layout, focus rings |
| Firefox desktop | Current and previous major | Focus rings, video, layout |
| iOS Safari | Current and previous major | Touch targets, scroll, modal close |
| Android Chrome | Current and previous major | Touch targets, keyboard overlap, back button |
Device pass minimum checks
- Mobile menu opens, closes, traps focus
- Forms deliver to client inbox
- Images and fonts load without shift
- Sticky headers and modals work on touch
- Analytics and consent tags fire once
If your studio sells accessibility work as a service, the ADA and WCAG 2.2 compliance service article covers scoping and pricing that offer.
Where it stalls
The named failure mode is the silent regression. A plugin update, a CDN rule, or a form handler change lands after QA closes and breaks a page nobody rechecks.
Its cause is almost always the same: QA ends at deploy, and nobody owns the site afterward. The defect surfaces weeks later, often when a customer complains.
The fix is hypercare with an owner. One person checks error logs, form deliveries, and uptime daily for the first week. If that role is unfilled, the contract terms that prevent disputes article explains how to write post-launch support into the agreement.
A second stall is scope drift during QA. Clients see a working site and request changes. Route those requests to a change order, or the QA window doubles.
Studios that onboard new testers mid-project lose days to context. The training checklist for new hires covers how to bring someone onto a live QA cycle without restarting it.
What to do while waiting
Use blocked time for documentation. Write the defect log format, the browser matrix, and the accessibility evidence pack the client may need later.
Run a partial performance pass on templates that are already frozen. Draft the launch announcement and the redirect map.
QA is defined by quality assurance principles: prevention over inspection. The earlier a defect is caught, the less it costs to fix.
