An accessibility audit does not check whether a site is fast and visible in Google - it checks whether the site can be used without a mouse and without sight. That is a completely different perspective from a classic technical review, even though both documents are called an “audit” and both can run to a similar page count. Which is where most of the confusion over quotes comes from: the client asks for one thing, gets another, and only notices the difference when someone actually tries to get through a form using the keyboard alone.
So let me break the topic into parts: how this audit differs from an ordinary one, what stages it consists of, what really drives the price, and how to tell human work from a scanner printout. If you want the wider context of work on an existing site, I describe it on the page about optimization.
How an accessibility audit differs from an ordinary site audit
An ordinary technical audit answers the question “does this site work well for a search engine and for an average user with a mouse”. It looks at indexing, speed, content structure - the way I describe it in the piece on what an SEO audit costs and what it must contain. The result speaks about visibility and performance.
An accessibility audit asks something different: can this site be operated by someone who does not use a mouse, cannot see the screen, or sees it poorly. Can you reach the cart with the Tab key alone. Is a button that looks like a button also a button to the software that reads the page aloud. Does the “something went wrong” message in a form reach a person who will never see it in a red box.
That distinction matters, because a site can have excellent Core Web Vitals scores and still be completely unusable without a mouse. Speed and accessibility measure different things and are fixed with different tools.
What a serious accessibility audit is made of
A proper audit has four layers, and none of them replaces the others.
- The automated part - scanners run through the code and catch what a machine can check: text contrast that is too weak, images with no alternative description, form fields with no label, broken heading structure. It is a fast, cheap stage, but it catches only a slice of the problems. A scanner will check whether an image has a description - it will not check whether that description means anything.
- The manual part - someone puts the mouse aside and goes through the site using the keyboard alone. Can every element be reached. Can you see where the cursor currently is (that outline around the active element). Is the tab order logical, or does it jump from a heading to the footer and back. Can a pop-up be closed without a mouse, or does it trap the user. Are form errors described in words rather than colour alone.
- A screen reader test - walking the key paths with the software that reads the page aloud switched on. This is where things invisible in the code come out: links read as “click here, click here, click here”, tables with no headers, dynamic parts of the page that change in silence.
- A content review - the language of the messages, link descriptions that make sense, transcripts and captions for video, how readable the instructions are. That is the layer no tool will judge for a human.
The proportion is roughly this: the automated pass gives you a starting point, the rest is manual work. An offer built entirely on the first point is not an audit, it is an export.
WCAG levels A, AA and AAA in plain language
WCAG is the international set of guidelines describing what “an accessible site” means. Formally the regulations do not point at it directly, but at a European technical standard, and that standard carries WCAG 2.1 at level AA - which is the reference point worth using when you talk about an offer. If you are still checking who is actually covered by the accessibility obligation, start with that piece. The guidelines themselves have three levels.
A is the absolute minimum - without it the site is simply closed to some people. Images have descriptions, video has captions, the site can be navigated with a keyboard.
AA is the level people talk about in practice and the one taken as the target in normal projects. Here you get requirements that are measurable and concrete: adequate text contrast, readability when zoomed, a visible focus indicator, consistent navigation, sensible error handling in forms. When someone writes “WCAG compliant”, they almost always mean AA.
AAA is the highest level and rarely achievable in full - some requirements are unrealistic for a typical company site (very strict contrast thresholds, for example, or text written at a reading level simpler than the industry itself uses). Individual AAA criteria are worth implementing selectively where they bring a real benefit, but a goal of “all of AAA” usually means burning budget.
The practical conclusion: talk about AA. A supplier selling “full AAA” either does not know what they are promising, or is counting on nobody checking.
What a website accessibility audit costs - what drives the price
There is no single rate, because there is no single site. There are, however, a few factors that push a quote up and down - worth knowing before you ask for one.
- The number of unique templates, not the number of pages - this is the most common misunderstanding. A store with a thousand products has one product page template. You audit templates and view types (home, listing, product page, form, cart, customer account), not every address separately.
- Feature complexity - a static brochure site is one league, a cart with a multi-step checkout, a login, a booking calendar or a configurator is a completely different one. Every interactive element has to be clicked, tabbed and listened to separately.
- The state of the code - a site built on decent, semantic code needs less analysis than a layer of visual overlays where every button is an artificially styled square. That same factor then drives up the cost of the fixes.
- Report only, or report plus implementation - two different products. A report ends with a document; a package with implementation covers actual fixes in the code and a re-check after the changes.
- The accessibility statement - public bodies publish an accessibility declaration, and private companies describe how they meet the requirements in their service information and terms. In both cases someone has to prepare it from the audit results, not paste it from a template. That is a separate line in the quote.
You see three billing models: per template (a rate times the number of unique views), per working day (on larger sites), or a report-plus-implementation package with one figure for everything. Each of them is honest - as long as it was calculated after looking at the site.
What helps: before you ask for a quote, write down the list of unique page types on your site (home, listing, product page, contact form, cart, customer account) and mark the ones where something interactive happens. That single sheet cuts the quoting conversation from a week to one email, and means you get a figure for your site rather than for an idea of it.
How to read the offers and what you should get out
Three warning signs come back regularly. First: a report that is a scanner printout - you recognise it because every finding can be reproduced with a free tool in five minutes, and none of them describes a real user path. Second: no priorities, meaning a list of two hundred remarks with no indication of what genuinely blocks people and what is cosmetics. Third: a price given on the spot, without looking at the site - nobody knows how much work a site needs when they have not seen it.
What you should get out is one thing: a list of findings ordered by severity, where every point has the problem described, the consequence for a specific user (“a person using a keyboard cannot reach the Order button”), the way to fix it and the estimated effort. Plus the order of work - what we do first, what second, what can wait. A document you cannot build a schedule from is not a plan.
Where to start if the budget is small
You do not have to start with a full audit of the whole site. A sensible order on a limited budget looks like this: first, the one path that genuinely earns money or generates enquiries - in a store, the route from the product page to the order; in a service company, the route from the home page to a submitted form. Checking and fixing that single path gives you more than a complete set of remarks about the footer and the terms page.
The second step is exactly the things the scanner caught in the first layer - cheap to fix, and effective across the whole site at once. That is usually hours of work, not weeks. Only after that does a full review of all templates make sense.
If the fixes go in alongside bigger changes, it pays to fold them into the existing scope - during a site rebuild accessibility costs a fraction of what it costs to add later to a finished front end. With me, fixed-bid projects usually land in the 5,000-10,000 PLN net range, and ongoing fixes after launch I handle under monthly care (Basic from 1,000, Pro from 2,000, Premium from 3,500 PLN net per month). You do not have to decide anything up front - a free diagnosis will show what is really blocking your site.
Frequently asked questions
How much does a website accessibility audit cost? It depends mainly on the number of unique templates and how many interactive features the site has - not on the number of pages. Billing may be per template, per working day or packaged with implementation, but every honest quote starts with looking at the site, not with a price list.
Is a free accessibility scanner enough? As a first signal, yes - it will show contrast, missing descriptions and part of the code errors. But the biggest problems - keyboard traps, nonsensical focus order, error messages invisible to a screen reader - only come out in a manual test.
Which WCAG level should I choose? In practice AA - and that is what is taken as the standard in projects anyway. Level A is the minimum below which the site is simply closed to some people, and full AAA is neither achievable nor economical for a typical company site.
Does an accessibility audit fix the site? No - an audit is a diagnosis, the fixing happens at implementation. So before you order one, ask outright who will do the fixes and what they will cost, so you are not left with a list of problems and a question about what next.
Sitting on this yourself and unsure where to start? I speed up and repair existing sites and stores - Core Web Vitals, outages, the features that are missing. Tell me what is happening and you will get a concrete quote with a date.