Pre-Launch Accessibility and Performance Gate (QA)

Pre-Launch Accessibility and Performance Gate (QA)

1. 01

   Freeze the generated build and record the exact platform version before any manual edits

   Tag the snapshot so a failed gate can be rolled back to a known state instead of patched forward. Note the hosting tier, since CDN and image handling differ between plans.

2. 02

   Run an automated accessibility pass on every template the client will actually use

   Check heading order, form labels, focus states, and color contrast on the pages in the sitemap, not just the homepage. Generated layouts frequently ship decorative images with empty alt text and low-contrast button states.

3. 03

   Test keyboard-only navigation through the primary conversion path

   Tab from landing page to form submission and confirm no control traps focus or disappears. This catches menu and modal behavior that automated scanners miss.

4. 04

   Measure Core Web Vitals on a throttled mobile connection, not office wifi

   Record LCP, CLS, and total page weight for the three highest-traffic templates. AI-selected hero images and embedded fonts are the usual causes of a failing LCP.

5. 05

   Confirm export and portability terms in writing before the client sees the site

   Establish whether the client can take the code, the content, or neither if the retainer ends. Platforms such as 10Web and Duda publish white-label and export terms that vary by plan, and the answer changes how you price the engagement.

6. 06

   Log every defect with a severity and a named owner

   Separate launch blockers from post-launch polish so the client conversation stays about the blockers. Assign fixes to the builder, the designer, or the platform support queue.

7. 07

   Re-run the full gate after fixes and archive the passing report with the project file

   The archived report becomes the baseline for the next template the agency ships on the same platform, cutting repeat QA time on later client builds.