Four things, and none of them is accessibility work. A written scope, meaning the pages, journeys and states you want covered and the standard you are being measured against. Working access, meaning an account for every role that sees a different screen, in an environment somebody can actually reach. One named person who can answer a question inside a business day. And a window where the build stays still, so the report describes something that still exists when it lands. Have those and an audit starts on the day it was booked to start.
The one that holds everything up is access, and it is not close. Testing is scheduled work and it behaves like scheduled work. A login that turns out not to exist in staging, a role nobody can create, or a password that has to clear a security review first, are what turn a booked start date into a wait. That is worth knowing early, because access is the only item on the list with somebody else's queue in front of it.
There is also one thing to take off the list, and it surprises people. Fixing things is not preparation. Run the free scan and clear whatever it hands you, because those are settled facts and nobody should bill you for them. Then stop, and leave the rest alone until the report arrives. An auditor tests the build they are given, and a site that keeps moving during testing produces evidence about a build that no longer exists.
Why Access Is the Thing That Delays an Audit
Almost everything that matters on a website sits behind something. The account screens, the order history, the saved payment methods, the admin view, the second role that sees a different dashboard. None of it can be reached by a crawler, and none of it can be reached by a tester either until somebody inside your organization creates a way in.
There is a structural reason this lands on you rather than on the auditor, and W3C's evaluation methodology names it. An in-house evaluator has easy access to the developers, the hosting environments and the authoring tools, because they already work there. An outside evaluator has none of that and has to ask, which the method describes as a normal and expected part of a third-party evaluation rather than as a failing. Independence is what you are buying, and this is the price of it. Everything the inside team would simply know has to be handed over on purpose.
Ours runs much like anybody else's, and knowing the sequence helps you get ahead of it. Nothing is charged when you place an order. We confirm the scope by email within one business day, and access is requested at that point, by email, rather than through any form on this website. The order form even says so where you would be most tempted to type a password into it, because a public form is the wrong place for one and always will be. The delivery clock then runs from cleared payment, and it pauses if anything blocks the testers.
So the useful thing you can do before you order is find out how long your own side takes. Ask whoever owns your environments whether a test account can be created this week or next month. That single answer moves an audit date more than anything else on this page.
The Readiness Checklist
Five sections. The first is writing, the second and third are decisions about access, the fourth is your security team's call rather than ours, and the fifth takes five minutes. Work through them in order and the whole thing is an afternoon.
Section One, What to Write Down
Everything here goes in an email or a document, and all of it is cheaper to settle now than to renegotiate halfway through. The scope worksheet is the long version of the first four rows.
| Write down | Why it is needed | Where it comes from |
|---|---|---|
| The templates in scope | Findings repeat by template, so this is what decides the size of the job | Your sitemap, or the theme files your developer can list in a minute |
| The journeys, first step to last | Every page in a process has to conform before any page in it does, so a half-tested journey proves nothing about the whole | Your analytics, or the three tasks that earn the money |
| The states to include | Errors, empty results and confirmations are where the serious findings live, and no crawler reaches them | Whoever tests your releases already has this list |
| The standard and the level | WCAG 2.2 at Level AA is the usual answer, and W3C's evaluation method names Level AA as the generally accepted target. A law or a contract sometimes freezes an older version instead | The contract, the regulation, or the questionnaire that started this |
| The deadline and what it is for | A procurement date, a launch and a legal deadline need different things, and knowing which changes what gets prioritized | You |
| What is out of scope, and why | A named exclusion is honest. A silent one reads as an oversight when somebody checks the report later | Whatever you decided not to include from the four rows above |
Section Two, the Access to Arrange
This is the section with the queue in front of it, so start it first even though it reads second.
| Arrange | What good looks like | What happens without it |
|---|---|---|
| A test account per role | One account for each role that sees a different screen, created for the audit and revocable afterwards | The role goes untested and gets named as untested in the report, which is worse for you than it sounds |
| Test data inside those accounts | An order history, a saved address, a populated dashboard, so the pages are not all empty states | Half the components never render, so the audit covers a version of your product nobody uses |
| A payment sandbox, or a card you are happy for us to use | Your provider's test mode, or written permission for one specific card and a ceiling on it | There is no way to exercise the last step of a checkout, so the most valuable journey stops one page short |
| The environment, named | Production, or a staging build you can say matches it, with the differences listed | Findings get argued about later, because nobody can say which build they came from |
| A reachable address | A public hostname on a standard web port for the automated pass | An intranet, an internal hostname or an odd port gets the human passes and not the machine one |
| Documents, if they are in scope | A list of the PDFs and office files that count, with an owner against each | Documents get treated as out of scope by default, which is fine as long as it was a decision |
| A note on third-party components | Which parts of the page you do not control, so a booking widget, a chat launcher, a payment iframe | Findings land on your team that belong to a supplier, and the ones that matter get lost among them |
None of that is unusual, and it is not a demand invented by suppliers either. W3C's evaluation methodology treats creating an account and making sure the product's configuration is representative as part of exploring a product, and it lists the specific test credentials needed to reproduce a data set or a workflow among the things worth keeping with the evaluation record. An account with nothing in it produces an audit of a product nobody uses, which is the quiet failure this section exists to prevent.
Section Three, How Much Source Access to Give
Short answer, none is required. An accessibility audit is performed against the rendered product, because the standard applies to what actually arrives in the browser rather than to what your codebase intended. Every failure worth reporting can be found, reproduced and evidenced from the page itself, with the element, the state and the markup written down. A firm telling you it cannot start without repository access is describing its own process, not a requirement of the standard.
Source access is still worth considering, because it changes the diagnosis rather than the finding. The table sets out what each level actually buys, so you can weigh it against whatever your own security policy allows.
| What you grant | What it makes possible | What it does not change |
|---|---|---|
| A public address and nothing else | A full audit of everything a visitor can reach without signing in | The parts behind a login, which stay untested and are named that way in the report |
| The rendered product, sign-ins included | Every failure found, reproduced and evidenced from the page, with the failing element, the page state and the markup recorded | Nothing. This is the ordinary case, and it produces a complete audit |
| Read access to the design system | A repeated failure traced back to the one component that emits it, so a failure appearing on every page becomes one ticket rather than forty | The findings themselves. It shortens the fix list rather than deepening the audit |
| Read access to the application repository | Naming the file and the template behind a failure, and spotting the second place the same fix has to land | The criteria covered. Nothing in WCAG is assessed against source code |
So the decision is a security decision and it belongs to you. If your policy says no outside party gets repository access, say no. The audit runs, the findings are the same findings, and the fix guidance names elements and patterns instead of files. If your policy allows read access to a component library, that is usually the cheapest version of yes, because a design system is where the repeated failures come from and it carries far less of your business than the application does.
Section Four, Keeping Real Customer Data Out of Testing
An audit needs a populated account. It does not need a real person's. Everything below is ordinary practice for testing work, and all of it is easier to arrange before an engagement than during one.
- Create accounts for the audit rather than sharing an employee's. A shared login mixes somebody's real activity into your test evidence and cannot be revoked without locking a colleague out.
- Seed the test data. Invent the order history, the saved address, the uploaded document. Pointing testers at a live customer record puts that customer's details into screenshots you will later circulate internally.
- Use your payment provider's test mode. Where that is not possible, name the one card that may be used and the ceiling on it, in writing.
- Never send a password through a public form. Ours has no field for one, and the notes box says so. Use whatever channel your own security policy names for secrets, and treat any supplier who asks you to paste credentials into a web form as having answered a different question about themselves.
- Scope the accounts to the roles being tested. An audit of the member view does not need an administrator account, and handing one over creates a risk that buys you nothing.
- Agree what may appear in evidence before testing starts. Screenshots and session recordings capture whatever is on screen, so if a field must never appear in a report, say which one and it gets masked or the page gets seeded differently.
- Set an end date on the access. Say when the accounts get revoked, and revoke them. This is your control to exercise, and a supplier who has finished has no reason to object.
- Name the data that is off limits. Regulated records, real patient or student data, anything under a legal hold. A tester told which door not to open will not open it.
Where our competence stops
We audit accessibility. We are not a security assessor, and nothing on this page is a security or privacy assurance about your systems or ours. Which of these arrangements your organization requires, what your contract has to say about handling and retention, and whether a given piece of data may leave your environment at all, are questions for your own security and legal people. What we can tell you is which of them come up in practice, which is what this section is, and that an audit runs perfectly well inside strict answers to all of them.
Section Five, the Person and the Window
The last five minutes, and the part that decides whether the report gets used or filed.
- Name one contact who can answer inside a business day. Not a committee. A tester stuck on a broken sign-up link stops, and the waiting comes out of your turnaround rather than out of theirs.
- Agree the window where the build stays still. Anything shipped after the pass arrives untested, and a redesign landing mid-audit turns the report into a description of something that no longer exists.
- Decide who receives the report and who owns the fixes. Those are usually different people, and an audit sent only to the person who bought it tends to stop there.
- Say whether a retest is planned, and when. It changes how the findings are best grouped for you, and it changes what your team should fix first.
What Not to Do in the Two Weeks Before
- Do not install an overlay to tidy things up first. It changes what the tester meets without changing what your visitors meet, and you will pay to have its behavior documented instead of your site's.
- Do not remediate what you have not measured. Work done on a guess lands somewhere harmless about as often as it lands somewhere useful, and you cannot tell which until the report arrives.
- Do not quietly take the broken journey offline. A journey hidden during the audit is a journey nobody tested, and it comes back the week after with all of its problems intact.
- Do not hand over a staging build without saying how it differs from production. Staging is often the right environment. Staging presented as production is how a finding gets disputed six weeks later.
- Do not wait until the scope is perfect. A written scope with three open questions on it is worth far more than a perfect one that arrives a month later.
What Happens Once You Send It
With ours, you pay at order and the scope comes back confirmed by email the same day, with a full refund standing until work starts, so seeing exactly what you are buying still comes before any testing does. Access gets requested at that point rather than earlier. The delivery clock starts when payment clears, and it pauses if the testers are blocked, which is the fair way round, because most blocks are the access ones this page exists to prevent.
What arrives is described in advance rather than after the fact. The sample report shows the format in full, our method sets out the three passes and the three things they do not cover, and the pricing page carries what each tier costs, how many pages it covers and what none of them buys you. Read all three before ordering if you want to. That is what they are there for.
One thing this preparation cannot do
None of it makes the result better. It makes the result arrive on time and cover what you meant it to cover, which is a different and more modest promise. An audit finds what is there, and a well-prepared engagement simply means fewer rows come back marked untested because nobody could open them. We audit and we never sell the repair work, so the fix list that follows is yours to hand to your own team or to a supplier you choose. That split is deliberate, because a firm paid by the length of the repair job should not be the firm writing the list.