What Actually Happens During a Website Accessibility Audit

“Accessibility audit” is a phrase people buy without much idea what arrives. Sometimes it is a serious piece of work. Sometimes it is a PDF export from a free scanner with a logo on the front, sold for a thousand dollars.

So here is exactly how I do it, step by step, including the parts that are unglamorous. If you end up hiring someone else, use this as a yardstick for what you should be getting.

Step one: audit

The audit runs in two passes, and the second one is where the real findings come from.

The automated pass comes first because it is fast and it clears the mechanical questions cheaply. Scanners are genuinely good at things that are true or false in the markup: does this image have an alt attribute, does this input have an associated label, does this text pass a contrast ratio, is the page language declared. Running these first means I am not spending your money hand-checking things a machine settles in seconds.

Then I test by hand, which is where most of the report comes from. Four things in particular:

• Keyboard. The mouse goes away and I work through every menu, form, modal and control with Tab, Shift-Tab, Enter, Space and the arrow keys. This is where keyboard traps, unreachable controls and broken custom components turn up. No scanner finds these reliably, because whether you can escape a modal is a behavior, not an attribute.
• Screen reader. I listen to the pages the way a blind visitor would. This is the only way to find out whether your alt text is actually useful, whether the reading order matches the visual order, whether your headings describe the page, and whether a control announces what it is and what state it is in.
• Contrast and focus. Measured values rather than opinions, including the states scanners routinely miss: hover, focus and disabled. A button that passes at rest and fails on hover still fails.
• Zoom and reflow. The site at 200 percent, and at narrow widths, checking that content reflows instead of overlapping or running off the edge.

On coverage, I audit by template rather than by page. Your site probably has one home page, one blog post layout, one product layout and a handful of one-off pages. Testing four hundred blog posts individually would be theater; they all come from the same template, so a defect in it is one finding and one fix. What I do check individually are the pages where the money and the risk sit: home, contact, checkout, and anything with a form.

Step two: prioritize

A raw findings list is not useful. A real audit of a site that has never had one will produce dozens of issues, and if I hand you all of them flat you will either panic or ignore the whole thing.

So issues get ranked by two things: severity, meaning how badly it blocks a real person, and legal exposure, meaning how often this specific failure shows up in complaints.

The distinction that matters is blocking versus degrading. A checkout button that cannot be reached by keyboard stops a transaction dead, and it gets fixed first. A decorative image with a slightly clumsy alt description is worth correcting but nobody was ever prevented from buying anything by it. Those are not the same priority, and treating them as equal is how remediation budgets get spent in the wrong order.

You get this as a ranked list with plain-English explanations of what each issue does to a real visitor, not just a success criterion number.

Step three: remediate

This is the step that separates real accessibility work from the alternative, and it is simple to describe. I fix the markup, the styles and the templates at the source.

Not a script layered on top of the finished page. Not a widget in the corner. The actual HTML your server sends, so that the site is accessible whether or not any JavaScript loads, and stays that way if you change themes or move hosts. I go through why the other approach fails in why overlay widgets don’t make your site compliant.

Fixing at the template level also means a single change frequently resolves the same issue everywhere it appears. One correction to a form template fixes every form built from it, which is a large part of why this costs less than people expect.

One thing I do not do is hand you a list and wish you luck. Plenty of audit vendors sell the findings and leave the fixing to you or your developer, which is a legitimate service but it is not what you are buying here.

Step four: verify

Then the whole thing is re-audited against WCAG 2.2 AA. Not the pieces I remembered changing, the whole set, by hand as well as automated.

This step exists because fixes break things. Correcting focus order in one component can shift behavior in a neighboring one. Repairing contrast on a button can affect its disabled state. A fix nobody re-tested is a claim, not a result, and the only way to know the site is where you think it is on the day you finish is to measure it again.

You get a written conformance summary at the end, saying what was tested, how it was tested, what was found and what was fixed. Keep it. If a demand letter ever does arrive, contemporaneous documentation that you took accessibility seriously and had it professionally assessed is exactly the kind of thing your attorney will want to see, and it is worth more than any certificate a vendor would sell you.

What it costs and how long it takes

ADA compliance work starts at $1,300 and typically runs one to two weeks. The current figure and full scope are always on the ADA compliance page, which is where I keep pricing current rather than in a blog post that could go stale.

What moves the number is the number of distinct templates, how much custom interactive work you have (sliders, filters, multi-step checkouts, booking widgets), and how the site was originally built. A clean custom site with a few oversights is quick. A page-builder site where the markup is generated by a tool is slower, because sometimes the honest fix is rebuilding the component rather than patching what the builder produced.

I will tell you which of those you have before you commit to anything.

What an audit cannot do

Three limits, said plainly, because you should hear them from me and not later from someone else.

It does not make you lawsuit-proof. Nobody can do that and anyone who says they can is selling something. Good-faith conformance to WCAG 2.2 AA lowers your risk substantially and demonstrates you took the obligation seriously. It does not reduce the risk to zero.

It is a snapshot, not a permanent state. The site is conformant on the day I finish. Then someone uploads an image without alt text, or a plugin update changes the checkout markup, and a gap reopens. This is not a scare tactic, it is just how living websites behave. It is why accessibility is part of my care plan rather than a one-time transaction, and why I show clients the handful of habits that prevent most of the drift.

It is not legal advice. I am not a lawyer. I can tell you precisely what standard your site meets and what it would take to close the gaps. Whether you are legally required to act, and what any particular letter means for your business, is a question for an attorney.

Before you book anything

Run the free checklist first. It takes about an hour, costs nothing, and will tell you whether you are looking at a short job or a real project. I would rather you arrive already knowing roughly what you have.

For the standard behind all of this, see WCAG 2.2 AA explained, and for the legal picture, ADA website compliance, what it actually means. When you are ready, book a free 30-minute call and I will give you a straight assessment. If the honest answer is that your site needs an afternoon rather than an audit, that is what I will tell you.