Performance Optimization·7 min

Accessibility and Performance Audit: What I Check Before Launch

By Bahaj Abderrazak·Published August 4, 2026
Accessibility and Performance Audit: What I Check Before Launch

Launch day is the wrong time to discover a broken form or a missing alt tag. Here's the exact checklist I run through before any site goes live.

Launch day is the worst possible time to discover a broken contact form, an unreadable color combination, or a page that takes eight seconds to load on mobile. This is the actual checklist run before any site goes live — not a generic "best practices" list, but the specific items that catch real problems before real visitors do.

Performance checks

  • Run the site through PageSpeed Insights on both mobile and desktop — mobile scores are typically lower and matter more, since a large share of traffic for most small business sites is mobile. See A Non-Technical Guide to Reading Your Lighthouse / PageSpeed Report for interpreting the results.
  • Confirm all images are optimized — correctly sized, modern format, lazy-loaded where appropriate. See Image and Asset Optimization for the specifics.
  • Check Core Web Vitals scores specifically, not just the overall score — a page can score reasonably overall while still failing one Core Web Vital that directly affects ranking and user experience.
  • Test load time on a throttled connection, not just on a fast office or home connection — a page that loads instantly on fiber internet can be a very different experience on a slower mobile connection, which matters directly for reaching users across Morocco's full range of connection speeds.

Accessibility checks

  • Run an automated accessibility scan (tools like axe or the Lighthouse accessibility audit) to catch the most common, mechanically detectable issues — missing alt text, insufficient color contrast, missing form labels. See What WCAG Compliance Actually Requires for what these checks are actually looking for.
  • Tab through the entire site using only the keyboard — every interactive element should be reachable and show a visible focus indicator, with no keyboard traps.
  • Check color contrast on all text, especially any text placed over images or on brand-colored backgrounds, where contrast issues are most common.
  • Verify every form has real, persistent labels — not placeholder text standing in as the only label.

Mobile responsiveness checks

  • Test on real device sizes, not just by resizing a desktop browser window — actual phone rendering (font sizes, tap target sizes, viewport behavior) can differ from browser dev tools' simulation.
  • Confirm tap targets are large enough — buttons and links that are easy to click with a mouse can be genuinely difficult to tap accurately on a phone screen if they're too small or too close together.
  • Check that no content is cut off or requires horizontal scrolling on common phone screen widths.

General pre-launch readiness

  • Test every form end-to-end, including what happens on validation errors and what confirmation the user sees after a successful submission — a form that silently fails to send is one of the most damaging, hardest-to-notice bugs on a live site.
  • Verify all links work, including footer links, navigation links, and any links embedded in content — broken links are a small thing individually but add up to a real trust problem across an entire site.
  • Check that analytics and any tracking scripts are actually firing correctly — confirmed by checking the analytics platform itself after a test visit, not just assumed because the code was added.
  • Confirm the site works correctly across major browsers, not just the one used during development — Safari in particular sometimes renders certain CSS and JavaScript features differently than Chrome.
  • Double-check that no placeholder or test content remains — Lorem ipsum text, test images, or draft copy accidentally left in from earlier in development.

Why this belongs in "before launch," not "after"

Fixing a broken form, a failed contrast check, or an oversized hero image is quick and low-stakes before launch. The same issues discovered after launch mean real visitors had a broken or frustrating experience in the meantime — lost leads, lost trust, and sometimes lost search ranking if the issue persisted long enough to be indexed. A structured pre-launch pass, run the same way every time, catches the large majority of these before they become customer-facing problems.

This checklist mirrors the "Launch and Improve" step in the actual development process — see the Process section on the Services page for how it fits into a full project, or the performance optimization services page for a dedicated audit on an existing site that's already live.

Web DevelopmentAccessibilityPerformance OptimizationPre-Launch ChecklistWebsite Launch

Bahaj Abderrazak

Full-Stack Developer · Morocco · Maroc (Casablanca, Rabat & Remote)

About the author →

Related articles

Let’s begin

Building something with these tools?

I help teams apply these patterns to real products. Share your project and I'll respond with next steps.