A test gate is a promise: what ours checks before a site goes live

Looking done is not the same as passing

When someone says your new site is ready, they usually show it to you on a laptop, and it looks right. Looking right tells you very little about whether it works. A page can look finished while a screen reader gets stuck on it, or while its contact form sends messages nowhere.

Plenty of sites look done without passing. The WebAIM Million report, published March 30, 2026, found detected WCAG 2 failures on 95.9% of the top one million home pages. That study covers the top million home pages on the web, not small business sites in particular.

So when we say a site is ready, we mean something narrower that you can check. It passed a gate, and the gate has four parts:

• Accessibility: can everyone use it.
• Speed on a phone: is it quick where your visitors are.
• Every form, proven end to end: does each message reach you.
• The search baseline: can Google find the pages.

The gate is part of every build on the websites page. Here is what each check means for you.

Accessibility: can everyone use it

The W3C's accessibility standard is called WCAG, and WCAG 2.2 was published on October 5, 2023, then updated on December 12, 2024. It sorts its success criteria into three levels, called A, AA and AAA.

There is a legal side too. The US Department of Justice says, in guidance dated March 18, 2022, that the ADA's rules for businesses open to the public cover what those businesses offer on the web. Our check is not a legal opinion, and passing it is not a promise about the law.

What our accessibility check asks is plainer. Can a person using a screen reader, or only a keyboard, get through each page and finish what they came to do? If the answer is no anywhere on the site, the check fails.

Here is the kind of thing it catches. Every form field needs a label tied to it, so a screen reader announces the right label and a tap on the label selects the field. Text that only sits near a field on the screen is not a label tied to it.

Speed on a phone, not on a desk

Google indexes and ranks a site using the version its smartphone crawler sees, so the phone version is the one that counts for search. A site that feels quick on the office wifi can still be slow where it matters.

Google's Web Vitals guidance gives two marks worth knowing. The largest thing on a page should finish loading within 2.5 seconds of the page starting to load. The page should respond to a tap within 200 milliseconds, measured at the 75th percentile of page loads and split by mobile and desktop.

Our speed check is about the phone, not the desk.

You can check your own site's phone speed with a free Google tool. As Google's About PageSpeed Insights page describes it, the free tool reports how a page performs on mobile and on desktop and suggests fixes, with separate scores for Performance, Accessibility, Best Practices and SEO.

Every form, proven end to end

A form is proven when a test message typed into it on the live site arrives in the inbox it is meant for. A thank-you screen only proves the page moved on. We check every form on the site that way, not one sample.

The labels from the accessibility check matter here as well. A field whose label is not tied to it is harder to fill in for someone using a screen reader.

One quiet failure sits in the email itself. Gmail says mail from a domain without SPF or DKIM authentication may be marked as spam or rejected. That is how a contact form's notification can stop reaching the owner, with nothing on the site looking wrong.

The search baseline: can Google find it

Every site we launch ships with its search and answer-engine baseline, and the gate checks it before launch. One small tag can hide a page. A noindex tag left on a page tells Google to drop that page from search results entirely, even when other sites link to it. That tag is useful while a site is half built, and costly if it is still there on launch day.

After launch, Google sets its own pace. In Google Search Console, the URL Inspection tool has a Request indexing button. Google says indexing usually takes a day or so but can take longer, and a request does not guarantee the page appears.

What a failed check does to the launch date

This is the part that makes the gate a promise. If a check fails, the launch date moves, and you are told which check failed and what it found. The problem does not go live with a note to fix it later, because later is when your customers find it.

A late launch is something you can plan around. A form that drops messages costs you people who never hear back, and you may not know it is happening.

A passed gate also does not mean the site shows up in Google that afternoon. Indexing usually takes a day or so and can take longer. Launch day is the day the site passes, and search catches up on Google's schedule.

What to do

1. Run your home page through PageSpeed Insights and read the mobile result first.
2. Send a test message from every form on your site, then check your inbox and your spam folder. If it lands in spam or never arrives, ask whoever manages your domain whether SPF and DKIM are set up.
3. On your phone, tap the label next to each field on your forms. If the field does not get selected, the label is not tied to it.
4. In Search Console, open the URL Inspection tool for your main pages. If a page is missing, check it for a noindex tag, remove it, then press Request indexing.
5. Before your next site, ask whoever builds it what ready means, in writing, and what happens to the launch date if a check fails.

Your Wish Is Our Code puts every site through these test gates before launch, and offers a care plan for after it goes live.