The owner is usually surprised, because their site had “passed” an automated scan. And that, in one sentence, is why this article exists.

If you’re considering an accessibility audit, you deserve to know exactly what you’re buying. So here is our entire website accessibility audit process, step by step, in plain English, what we do, why we do it by hand, and what lands on your desk at the end. No mystery, no jargon, no black box.

First, Why “Manual” Is the Most Important Word in the Title

There are two ways to audit a website. The fast way is to point a piece of software at it and print whatever comes out. The right way is to have trained people actually use your website the way your visitors do, including visitors who are blind, who can’t use a mouse, who have low vision, or who process information differently.

We use software too, as a warm-up. But automated scanners can only detect issues with clear yes-or-no answers: is the alt text present, is the contrast ratio above the line, does this form field have a label. That covers roughly a third of what accessibility guidelines actually require. Everything else takes judgment.

Here is the difference in one example. A scanner can confirm that your team photo has alt text. It cannot tell you that the alt text says “IMG_4092.jpg”, which, to a blind visitor, is worse than useless. A scanner can confirm your page has headings. It cannot tell you they’re in an order that makes the page read like a shuffled deck of cards. Whether something actually works for a human being is a question only a human being can answer.

That is why every audit we deliver through our manual website audit and remediation service is performed by people, page by page, task by task. Now let’s walk through exactly what those people do.

Step 1: We Learn How Your Website Is Actually Used

Before anyone tests anything, we ask questions. What do visitors come to your site to do? Where does the money, the signup, or the service request happen? Which pages get the most traffic? Are there forms, payment steps, document downloads, videos, or third-party tools like booking widgets and chat boxes?

This matters because accessibility isn’t about pages in the abstract, it’s about journeys. A visitor doesn’t experience your “homepage” and your “contact page” as separate items on a list. They experience one continuous attempt to get something done: find the phone number, book the appointment, pay the bill, download the form. If any single link in that chain is broken for them, the whole journey fails.

So we map your site’s key journeys and its representative page types, home, navigation, content pages, forms, search, checkout or signup if you have them. On a large site we don’t need to test every one of ten thousand pages, because most pages are built from the same templates; we test each template thoroughly plus every unique, high-stakes page. That keeps the audit focused on what actually affects your visitors.

Step 2: The Automated First Pass (the Warm-Up, Not the Workout)

Yes, we run scanners, and we’re glad they exist. Automated tools are fast and tireless, and they reliably catch the mechanical problems: images missing alt text entirely, text with contrast below the required ratio, form fields with no label attached, links with no readable name.

We use this first pass for two things. First, it sweeps up the easy findings quickly, so human time gets spent where human judgment is needed. Second, it gives us a map of where problems cluster, if one template lights up with errors, we know its siblings deserve extra attention.

What we never do is stop here. A clean scan is not a clean site, it’s a site with none of the problems a machine can see. The rest of the process exists to find everything a machine can’t.

Step 3: Keyboard Testing, We Unplug the Mouse

Here is where the manual work begins in earnest, and it starts with something disarmingly simple: our testers put the mouse away and attempt every important task on your site using only the keyboard. Tab to move forward, Shift-Tab to move back, Enter and Space to activate, arrow keys inside menus.

Why? Because a large group of your visitors has no other option. People with tremors, arthritis, or limited fine motor control. People recovering from injuries. People with permanent paralysis who navigate with adaptive switches that mimic a keyboard. And every blind visitor, because screen readers are driven from the keyboard. For all of these people, the keyboard is the front door to your website, and it’s astonishing how often that door is locked.

During this step, our testers are checking three things on every page and in every task:

• Can you reach everything? Every link, button, menu, form field, and control must be reachable with the Tab key. A “Book Now” button that only responds to mouse clicks is invisible to keyboard users, it may as well not exist.
• Can you see where you are? As you Tab through a page, a visible outline should always show which element has focus. When that highlight disappears, hidden by a designer who found it ugly, or buried behind a sticky header, keyboard users are navigating blind.
• Can you always get out? Popups, chat windows, and menus must release the keyboard when you’re done. A cookie banner you can enter but never leave is called a keyboard trap, and it ends a visit instantly.

Our testers don’t just Tab around aimlessly, they complete your real journeys, start to finish. Find the service page. Fill out the contact form. Add the item to the cart and check out. If any step of any journey can’t be finished by keyboard alone, that’s a critical finding, and it goes to the top of your report.

Step 4: Screen Reader Testing, We Listen to Your Website

A screen reader is software that speaks the contents of the screen aloud, and it’s how blind and many low-vision visitors use the web. In this step, our testers turn on a screen reader, turn their attention away from the display, and experience your website the way those visitors do: entirely by ear.

This is the part of the audit that surprises site owners most, because a page that looks perfectly organized can sound like chaos. Here’s what we’re listening for:

• Does the page have a spoken skeleton? Screen reader users navigate by jumping between headings, the way sighted users skim. If your headings are just big bold text rather than real headings, there’s nothing to jump to, the visitor is forced to listen to the entire page from the top.
• Do things say what they are? Every button, link, and control gets announced. “Download our pricing guide, link” is useful. “Click here, link”, heard out of context, tells the listener nothing. Neither does “button,” “image,” or dead silence.
• Do images speak or stay politely quiet? Meaningful images need descriptions that convey what matters. Decorative flourishes should be marked so the screen reader skips them, instead of announcing “decorative-divider-final-v2.png.”
• Does dynamic content announce itself? When a form error appears, when items load, when a popup opens, does the screen reader user find out, or does the page change silently around them while they wonder why nothing happened?
• Does everything read in an order that makes sense? Visual layout and spoken order are two different things. We regularly find pages where the price is announced before the product, or the “agree to terms” checkbox reads after the submit button it governs.

Just like the keyboard step, this isn’t abstract checking, our testers complete your real tasks by ear, start to finish. It’s slow, deliberate work, and it’s precisely the work no scanner on earth can do, because “does this make sense when you hear it?” is a human question.

Step 5: Visual Checks, Zoom, Contrast, and Color

Not every visitor with a vision impairment uses a screen reader. Far more people simply need things bigger and clearer, older adults, people with low vision, and honestly anyone reading a phone in sunlight. So the next round of manual testing is visual.

We enlarge every key page to 200 percent and watch what breaks. Done well, text reflows and everything stays usable. Done poorly, columns overlap, buttons slide off screen, and menus become unreachable. We check that text contrast holds up not just in body copy, where scanners check it, but in the places scanners miss: text sitting on photos, hover states, disabled-looking buttons that are actually active, placeholder text inside form fields.

And we hunt for places where color is doing a job all by itself. If your form marks errors only by turning fields red, a colorblind visitor sees nothing wrong. If your links are distinguished from ordinary text only by color, they vanish for the same audience. Every one of these needs a second signal, an icon, an underline, a written message, and we note every spot that lacks one.

Step 6: Forms, Real Tasks, and the Mobile Pass

Forms get their own dedicated attention, because forms are where websites and visitors do business, and where accessibility failures cost the most. Our testers fill out every important form the hard ways: keyboard only, screen reader on, zoomed in. They make deliberate mistakes to see what the error messages do. A good error says what went wrong, where, and how to fix it, and announces itself to assistive technology. A bad one turns something red and hopes.

Then everything gets a mobile pass. More than half of web traffic is on phones, and accessibility problems compound on small screens: touch targets shrink below what fingers can reliably hit, pinch-zoom gets disabled by a single line of code, and mobile menus behave differently from their desktop cousins. We test your key journeys on mobile with the same rigor as desktop, including with the mobile screen readers built into phones.

Along the way we also check the pieces owners often assume are “not really our site”: embedded videos (do they have captions?), PDFs linked from pages (are they accessible documents?), and third-party widgets like booking tools and payment forms. Your visitors don’t distinguish between your code and your vendor’s code, and neither do accessibility laws.

Step 7: A Report You Can Actually Read

An audit is only as useful as the report it produces, and this is where a lot of audits fall apart. We’ve seen reports that are just raw scanner exports, hundreds of rows of error codes that mean nothing to anyone without a development background. That’s not a report; that’s homework.

Ours is built to be used. For every issue we find, you get:

• What it is, in plain English, not a WCAG criterion number standing alone, but a sentence a non-technical person can understand: “The main menu cannot be opened with a keyboard.”
• Who it blocks and how much, a severity rating that reflects real impact. A broken checkout is critical; a mislabeled decorative image is minor. Not all findings are equal, and your report shouldn’t pretend they are.
• Exactly where it lives, the pages and elements affected, so nobody has to go hunting.
• How to fix it, concrete guidance your developer (or ours) can act on directly.
• What to do first, the whole list sorted into a priority order, so the highest-impact fixes happen soonest instead of whatever appeared first alphabetically.

We also walk you through the findings in person, in plain language, and answer every question. You should finish that conversation knowing exactly where your site stands and exactly what happens next, not clutching a spreadsheet and a sense of dread.

What Happens After the Audit: Fixing It (by Hand) and Testing Again

For most clients, the audit is the first half of the story. The second half is remediation: actually fixing what was found. Here, too, the word “manual” matters. We don’t install a widget that claims to patch problems on the fly, we fix the underlying code, page by page, issue by issue, so the site is genuinely accessible for everyone, on every device, with no layer of software duct tape in between.

And when the fixes are in, we don’t take our own word for it. Every remediated issue gets retested the same way it was found, by hand, with a keyboard, with a screen reader, before we mark it resolved. If you’d like the full picture of that phase, we’ve written a plain-English guide to the website remediation process and what it costs, and a breakdown of what a website accessibility audit costs on its own.

One more thing worth saying: accessibility isn’t a trophy you win once. Every redesign, new plugin, and fresh batch of content can introduce new barriers. That’s why we recommend periodic re-checks after the initial work, smaller, faster, and focused on what changed.

What We Need From You (Spoiler: Very Little)

A common worry we hear: “Will the audit disrupt our website?” No. Testing is done the same way visitors use your site, by browsing it. Nothing is installed, nothing is changed, and your site stays up the entire time. If parts of your site sit behind a login, we’ll ask for a test account; if you have a staging environment you’d rather we use, that works too.

The most valuable thing you can give us is the answer to one question: what do your visitors come to your site to do? The clearer that picture, the sharper the audit. Everything else, the testing, the documentation, the prioritizing, is our job. You can see how the whole engagement fits together in our web accessibility workspace, which lays out every service and how they connect.

Frequently Asked Questions

How long does a manual accessibility audit take?

It depends on the size and complexity of your site, mostly on how many unique templates, forms, and interactive features you have, rather than your raw page count. A small brochure site is a much quicker job than a large site with e-commerce and member portals. When we scope your site (Step 1), we’ll give you a specific timeline before any work begins, so there are no surprises.

Can’t we just run a free scanner ourselves?

You can, and it’s a fine first step, it will show you the mechanical problems and give you a feel for where things stand. Just know what it can’t do: it can’t tell you whether your site actually works for a keyboard user or makes sense through a screen reader, and those judgment-based issues are both the majority of accessibility problems and the ones most likely to block real visitors (and draw legal attention).

Do we have to fix everything at once?

No, and you shouldn’t try. The priority order in your report exists precisely so you can fix the critical barriers first (the ones blocking whole tasks for whole groups of people), then work down the list at a sustainable pace. Steady, documented progress is worth far more than a stalled attempt at perfection.

Find Out What the First Ten Minutes Would Reveal on Your Site

Every website has something, we have yet to audit one that didn’t. The question is whether it’s a loose thread or a locked front door, and there’s only one way to know: have a human try the door.

Request a free audit and we’ll take that first look at your site, by hand, and tell you plainly what we find. Our pricing is published, our process is the one you just read, and our audit and remediation service picks up wherever you’d like the help. No mystery, no jargon, no black box, that’s the whole point.