Scope, method, findings, and what happens afterwards
A website accessibility audit, described without the mystique.
Audit is a word that makes people expect either a rubber stamp or a six-month engagement. It is neither. It is five days of somebody working through your site the way a person with a disability would, writing down what stops them, and signing a document that says so. This page explains how the scope is decided, what the five days contain, how the report is structured and what the organisation does with it afterwards.
Nothing is installed on your site. Credentials stay with the tester.
How the scope is decided
Scope is where audits become either useful or expensive, and the decision is made before any testing starts.
Auditing every URL of a large site is expensive and mostly redundant, because templates repeat. The scope that produces useful results follows three rules.
One instance of each template. If forty product pages share a template, the barriers on them are identical. Testing one and confirming the pattern is honest and efficient.
Every unique flow, end to end. Checkout, booking, registration, application, contact. These are where tasks fail, and they cannot be sampled: a flow is only as usable as its worst step.
Everything with a form in it. Forms concentrate the failures that stop people: labels, errors, validation, time limits, and the moment a task is abandoned.
What the five days contain
Five days is not a marketing figure. It is what the sequence below takes on a site of ordinary size.
| Day | Activity | What it catches |
|---|---|---|
| One | Scope, credentials, automated pass | Alternative text, contrast values, malformed structure |
| Two | Keyboard testing of every flow | Traps, unreachable controls, invisible focus, broken order |
| Three | Screen reader testing | Unnamed controls, silent errors, wrong reading order |
| Four | Zoom, reflow, contrast in every state, motion, timing | Clipped content, unreadable states, unstoppable animation |
| Five | Writing, statement, signature, code | The part your team actually uses |
Day one is cheap and fast; days two to four are the audit. The proportion is worth knowing when comparing quotes, because a supplier whose process is mostly day one is selling a scan with a report cover.
How the report is built
Four decisions about structure, each taken because the opposite produced reports that went unread.
A findings list that nobody acts on has failed regardless of its accuracy, so the structure is designed for the people who will read it rather than for the standard.
By impact, not by number
Blocking first, then serious, moderate and minor. Criterion references are present but secondary.
Plain language
Each item says what a person cannot do, where, and what to change. A developer can act; a manager can understand.
Split by owner
Content items to the people who publish pages, technical items to engineering. Undifferentiated lists go unread.
With the evidence
Page, component and the condition under which it fails, so a fix can be verified rather than assumed.
What an audit cannot do
Being clear about the boundaries is part of the service. An audit is expert testing against criteria: it does not replace user research with people with disabilities, which finds friction rather than failures and is a separate, worthwhile exercise.
It does not remediate. We describe the change precisely; somebody has to make it, and pretending otherwise leads to the common situation of an organisation with three audits and no fixes.
It does not certify on behalf of any authority. No private company anywhere does, whatever the badge on their website suggests. What it produces is evidence: dated, external, signed and verifiable.
After the report: the part that decides the outcome
Two organisations receive identical reports and end up in completely different places a year later, and the difference is never technical.
The first assigns an owner. One named person receives the findings, decides what becomes a ticket, hands the content half to whoever publishes pages, and reads the monthly result. Blocking items close within a month, the rest fold into normal releases, and the statement gets reissued twice.
The second circulates the report to a distribution list. Everybody assumes somebody else owns it, the blocking items are still open at the next audit, and the organisation concludes that accessibility is expensive — having spent nothing beyond the audit itself.
The cost difference between those two outcomes is roughly two hours of someone's attention per month. It is the highest-leverage decision in the whole process, and it is made before the audit starts.
Audit, re-test, and the annual cycle that went away
The traditional model is an audit every twelve to eighteen months, which made sense when sites were rebuilt rarely. It does not describe a site that deploys weekly, where a report is stale within a month and a regression can live for a year before anybody notices.
Our plan replaces that with one audit and monthly re-testing: each run compared with the previous one, a short note when something moves, and the statement reissued when the change is material. Over a year this produces a dated history of what was tested, found and fixed, which is worth more in an inspection or a tender than any single report.
690 € a year for the European Union, 890 CAD for Canada, 1,290 € for three domains and six languages, 1,990 € for all three regions with one renewal date. The detail of what sits inside the price is on the cost page, and the testing method on the WCAG audit page.
What we ask you before starting
Six questions, and none of them technical.
The scope form takes about ten minutes and asks six things. Knowing them in advance makes the conversation faster.
The domain, and any others in the same plan. Subdomains with their own content count separately, because they usually have their own templates.
What people come to do. Buy, book, apply, register, download, contact. This determines which flows are tested end to end rather than sampled.
Anything behind a login. Members' areas, customer portals, application forms. If it matters to your business it should be in scope, and we need a test account.
The company that will be named. The legal entity that appears on the statement, which is not always the brand on the website.
The markets you sell in. This decides which document is produced and which entity signs it.
Any known problems. If your developer already knows the date picker is broken, say so. It saves nobody time to have us discover it, and it tells us where else to look.
One practical note on timing. The five days are consecutive working days once the scope form and any credentials are complete, and the most common source of delay is not our queue but the test account: somebody has to create it, and in larger organisations that request travels through a service desk. If the login area is in scope, start that request the day you order rather than the day we ask.
The second common delay is deciding which legal entity is named on the statement. It sounds trivial and it occasionally takes a week, because the brand on the website and the company that signs contracts are not always the same, and somebody has to confirm which one belongs on a public document.
What we do not need
Access to your code, your analytics, your hosting or your CMS. An audit that requires all of those has usually been scoped as a development project rather than an assessment, which is a different service at a different price. We open the site the way your customers do, and that is the point: what matters is what they meet, not what the source intends.
The findings you should expect on a first audit
Not a promise about your site, but a pattern consistent enough to plan against.
Predicting results before testing would be dishonest, but the distribution is remarkably stable across hundreds of sites, and knowing it helps with planning.
Two to six blocking items. Almost always fewer than people fear. Typically a keyboard trap in an overlay, an unnamed control in a transactional flow, and a form whose errors are invisible to assistive technology.
Ten to thirty serious and moderate items. Heading structure, focus visibility, contrast on secondary elements, link text, announcements after asynchronous updates.
A long tail of minor items. Redundant alternative text, small inconsistencies, decorative elements exposed unnecessarily. Worth fixing eventually, never worth delaying the statement for.
A content list that needs no developer. Usually a third of the total: images carrying text, vague link wording, headings used for size, tables saved as pictures.
The useful consequence: the work that removes the real barriers is measured in days, not months, and it can start the week the report arrives rather than after a planning cycle.
Comparing audit quotes
Proposals in this field are hard to compare because they describe different products in similar language.
If you are collecting proposals, four questions separate them faster than reading the documents.
How much of the work is manual, and who does it? What is the deliverable, exactly — a report, a statement, both, signed by whom? What happens between audits: nothing, or continuous testing? And is remediation included, because a quote that includes developer time is not comparable with one that does not.
Answer those four and most price differences explain themselves. Ours is a fixed annual fee covering testing, documentation, signature and monthly re-testing, with remediation explicitly excluded and described honestly on the cost page.
Audit questions
What is a website accessibility audit?
A structured assessment of a site against WCAG, combining automated checks with manual testing by a person using a keyboard and a screen reader.
How is it different from a scan?
A scan is software. An audit includes a person completing your real tasks and reporting what happens.
What do I receive?
A findings report ordered by impact, a signed statement written from it, a public verification code and monthly re-testing.
How long does it take?
Five business days from a complete scope form.
How many pages are covered?
A representative sample of templates plus every unique flow, rather than every URL.
Do you need access to our code?
No. We test the site as a user experiences it.
Do you test areas behind a login?
Yes, with test credentials you provide.
Which standard?
WCAG 2.2 level AA. Ontario's legal minimum is WCAG 2.0 AA, which this exceeds.
Do you test mobile?
Yes: layout, touch target size, zoom, reflow and orientation.
Do you fix the problems?
No. We test, document and sign. Your team or agency implements from the list.
How are findings prioritised?
By what a person cannot do: blocking, serious, moderate, minor.
Will the report make sense to non-developers?
Yes. It is split so content people and developers each get their part.
What if we have several sites?
Three domains are covered by the EU Plus plan; beyond that, ask.
How often should we re-audit?
The plan re-tests monthly, which replaces the annual audit cycle for most organisations.
Do you provide a certificate?
A signed record with a public code anyone can verify. No private company issues government certification.
What does it cost?
690 € a year for the EU, 890 CAD for Canada, 1,290 € for three domains, 1,990 € for all three regions.
Is there a trial?
Seven days free, no card, with cover from day one.
How do we start?
Free scan, then the scope form. Testing starts the same day.