A Website QA Process for Web Agencies
95.9% of top home pages have detectable accessibility failures. A QA process for web agencies that covers more than clicking around on staging.
A Website QA Process for Web Agencies
Here's how QA works at a lot of agencies. The developer says it's done. The project manager opens staging, clicks around for twenty minutes on a laptop, and says it looks good. The client finds the first bug on their phone within a minute.
That isn't testing. It's hoping, with extra steps.
The numbers suggest it's a widespread habit. The WebAIM Million, which scans the top one million home pages each year, found detectable WCAG 2 failures on 95.9% of them in 2026, up from 94.8% in 2025. That's only what automated tools can find, and it's on home pages, the part of a site that gets the most attention.
Most of those failures are the kind a basic QA process would catch.
What QA Is For
Good QA answers one question: does this site do what we agreed it would do, for the people who'll really use it?
The second half matters. A site can match the design perfectly and still fail anyone on a slow phone, anyone using a keyboard, or anyone filling in a form in a hurry.
Start From What You Agreed
QA starts before testing, with acceptance criteria. If a ticket says "build contact form", no one can say when that's finished. If it says "form validates email, sends to sales@, shows a confirmation and works on mobile", anyone can test it.
Write the test plan from those criteria. It doesn't need to be a big document, just a list of what's being tested, on which devices, by whom, and what counts as passing.
One rule is worth keeping at any size: the person who built it shouldn't be the only person who tests it. You can't see your own mistakes, because you know what you meant.
The Four Passes
Don't try to test everything at once. Do separate passes, because each one needs a different kind of attention.
Pass 1: Does it work?
- Every page loads, and every link goes where it should
- Every form submits, validates and sends its data to the right place
- Search, filters, logins and checkout work from start to finish
- Error states are real: try submitting an empty form or a wrong password
- Content is final, with no lorem ipsum, and the right legal pages
Test on staging with real content. Layouts that look lovely with placeholder text can fall apart with a client's actual 14-word headline.
Pass 2: Does it work everywhere?
Decide what you support, based on the client's real analytics if they exist, rather than testing "all browsers". For most sites, that means current versions of Chrome, Safari, Edge and Firefox, on real desktop and mobile screens.
Use at least one physical phone. Device emulators are useful but they don't tell you how a page feels under a thumb, and iOS Safari has a habit of finding things that nothing else does.
Pass 3: Can everyone use it?
The WebAIM results show where to look. The most common failures on those million home pages were:
| Failure | Share of home pages |
|---|---|
| Low contrast text | 83.9% |
| Missing image alt text | 53.1% |
| Missing form input labels | 51.0% |
| Empty links | 46.3% |
| Empty buttons | 30.6% |
Those are specific, testable things, and that's good news. WCAG 2.2 is the standard, and level AA is the usual target. In practice, a solid pass looks like this:
- Run an automated scan on key templates. It catches a lot of the table above, though not everything.
- Put the mouse down. Tab through the page using only the keyboard. Can you reach everything, and can you see where you are?
- Try a screen reader on the main journey. VoiceOver is built into Macs and iPhones.
- Zoom to 200% and check that nothing breaks.
The W3C's guidance on evaluating accessibility goes further. Automated tools only find part of the problem, so don't let a clean scan be the end of it.
Pass 4: Is it fast enough?
Test on a mid-range phone and a normal connection, not an office fibre line. Google's Core Web Vitals give you three clear measures to check: loading, responsiveness and visual stability.
The usual culprits are oversized images, too many third-party scripts and web fonts. Measure key templates rather than only the homepage. The product page or article template is often where the real traffic lands.
Log Bugs So They Get Fixed
A bug report saying "contact page broken" just starts a conversation. A useful one has:
- Where: the URL, browser and device
- Steps: exactly how to reproduce it
- Expected and actual: what should have happened, and what did
- Severity: see below
- A screenshot or recording
Agree severity levels before you begin, or everything ends up "urgent":
| Severity | Meaning | Launch? |
|---|---|---|
| Blocker | Core journey fails, or something legal is wrong | No |
| Major | Important feature fails, with a poor workaround | Fix first |
| Minor | Works, but looks wrong or is awkward | Fix or schedule |
| Trivial | Polish | Backlog |
Then retest every fix. Fixes break other things, and "fixed" should mean that someone other than the developer has confirmed it.
Bring In Real Users
If the project justifies it, watch a few real people try the site. Nielsen Norman Group's well-known analysis argues that a study with five users can uncover about 85% of usability problems, and that several small rounds beat one big one. That applies to similar users. If you have distinct audiences, you'll need to test each of them.
Even an hour of this tends to be humbling. People get stuck on things no one on the team had thought about.
Client Sign-off
User acceptance testing is the client's turn. Give them a short script of the journeys that matter, one list to log issues in, and a deadline. Without that structure, UAT becomes a stream of design opinions arriving by email.
Keep a clear line between bugs, which you fix, and changes, which are new scope. Agree who decides. When the client signs off, get it in writing, then move on to the launch checklist.
The Honest Trade-off
Thorough QA costs real time, usually more than agencies quote for, and that time tends to be squeezed first when a project runs late. It's better to price it openly as a line item than to promise it and then skip it.
The depth should also match the stakes. A five-page brochure site doesn't need the same process as a shop processing payments, so scale the passes to the risk. But don't drop Pass 3. Accessibility is a legal concern in many markets and a real barrier for real people, and it's far cheaper to get right before launch than after.
Put It in Writing
Having a written process also means QA doesn't depend on who's free that week.
Clicking around on staging tells you that the site works for you. QA is finding out whether it works for everyone else, before they tell you it doesn't.
