Pick by the reader. If the only people who will ever see the result are inside your building, an internal review is a real evaluation and the money is better spent on fixing things. If somebody outside your company has to weigh the answer, so a customer, a procurement team, a regulator or a court, then who produced it starts to matter more than how good it was. An outside audit is what you are actually buying.
What is not in play here is permission. WCAG contains no independence rule of any kind. Read the whole conformance section and you will find five requirements, an optional claim with five components, and two statements of partial conformance. Nothing about who evaluated the site, nothing about their employer, nothing about their credentials. If somebody has told you a third party is required, that requirement came from a contract, a procurement rule or a regulator. Read the actual sentence. It usually says less than the person quoting it thinks.
W3C's own evaluation methodology goes further and settles the question outright. Its definition of an evaluator is a person, a team of people, an organization, an in-house department, or another entity responsible for carrying out the evaluation. In-house is in the definition. The method is written to be used for self-assessment and for third-party assessment, and it says so in its abstract.
What an Internal Team Has That Nobody Can Sell You
This is the part that gets skipped in articles written by audit firms, so here it is first. W3C's methodology names the advantage and it sits with the inside team.
In-house evaluators, and evaluators who are part of the development process, have easier access to almost everything an evaluation needs. The developers and maintainers. The development and hosting environments. The authoring tools, and the materials used to build and run the thing. Particular use cases, design analysis, technical specifications, documentation and testing resources make an evaluation more effective, and the method says those should be used where possible.
In practice that means an internal reviewer can do three things an outsider cannot buy at any price. They can walk to the person who wrote the component and ask why. They can reach the states that only exist with particular data behind them, so the account with three failed payments and the order that shipped in two parts. And they can test on the schedule the work actually runs on, which means a finding lands while the code is still warm rather than three weeks after the release.
What an Outsider Has That You Cannot Manufacture
Two things, and only one of them is expertise.
The first is unfamiliarity, which is genuinely a testing asset and the one thing an internal team loses permanently on their first week. Somebody who has never used your checkout does not know that the filter is a dropdown until they find it. They do not know which of the four buttons is the real one, and they cannot skip a step out of habit. Your own team has learned your interface, and that learning is exactly what a first-time user does not have.
The second is that the result is not written by the party it is about. That is not a claim about honesty. It is about what the reader can do with it. A procurement team reading a self-assessment has to take the assessment and the assessor on the same word, and they discount it accordingly, whatever its quality. The same document from outside costs them one fewer act of trust, and that is the whole product.
The methodology is honest about the flip side too. Independent external evaluators typically have less information about the internal software, areas and functionality of a product, because they were not involved in how it was procured, designed or built. So they often have to go and ask the owner for what they need. That is why an outside audit that never asks you a question is a slightly worrying outside audit.
The Decision Table
Seven situations, and the honest answer for each. Find the row that describes why you are asking.
| Your situation | What it needs | The honest answer |
|---|---|---|
| Nobody has ever looked, and you want to know roughly where you stand | Breadth and speed, at almost no cost | Internal, today. The keyboard pass, the zoom pass and a screen-reader pass on your main journey will find more than you expect. Buy an audit once you have stopped finding things yourself |
| A customer, a procurement team or a regulator will read the result | Evidence somebody outside your company can weigh without taking your word for it | Outside. The reader discounts self-assessment whatever its quality, so an internal review here is work you will end up paying for twice |
| You need to verify fixes your own team has just made | Distance between the person who wrote the code and the person who signs it off | Outside, or at the very least a different internal team. A fix verified by whoever made it has not been verified |
| You are deciding what to build and change next quarter | Depth on your own components, and access to the people who own them | Internal, or a hybrid. This is planning rather than evidence, and your own team is faster at it once they know what to look for |
| You want to know whether people can actually use the thing | Disabled participants doing real tasks, which is not conformance testing at all | Neither. That is usability testing with disabled users, a third kind of work with a different method and a different output |
| Your team has never done this and does not know what good looks like | The four capabilities the method assumes, which take time to build | Hybrid. Buy one round, have your team sit in on it, and take over the parts you can run yourselves afterwards |
| You have a report already and you think some of it is wrong | A second reading of specific findings, not a second full evaluation | Outside, narrowly scoped. Retesting named findings is a smaller and cheaper thing than a fresh audit |
The Four Capabilities, Wherever They Live
The methodology assumes whoever uses it has a solid understanding of how to evaluate content against WCAG, of accessible design, of assistive technologies, and of how people with different disabilities use digital products. It breaks that into four areas, and it allows a team to hold them collectively rather than demanding one person carry all four.
- The technologies your product is built from, well enough to read what the markup actually exposes rather than what the design intends.
- The barriers people with disabilities meet, which is the knowledge that turns a rule into a judgment about whether something is genuinely usable.
- The assistive technologies and adaptive approaches people use, at the level of driving them rather than knowing they exist.
- The evaluation techniques, tools and methods for finding barriers, which includes knowing what each tool cannot see.
Run that list against your own team honestly and it usually comes out the same way. The technical knowledge is there and the disability-specific knowledge is not, which is what W3C found too. Its guidance on combining expertise says the internal gaps are often in areas specific to disability and accessibility, so the guidelines themselves, cross-disability barriers, and the use of assistive technology. That is a useful diagnosis, because it tells you what to buy rather than whether to buy.
The Hybrid Is What Most Organizations Land On
W3C describes the pattern directly. The first instinct is to hand the job to one person inside the organization or to outsource it whole. Many organizations end up somewhere else, running a collaborative process that uses in-house expertise alongside outside experts where they are needed.
One of its worked shapes is the one worth copying. A development or quality assurance team brings in outside experts to help them run evaluations in the short term, and to build the team's own capability over the longer one. You are buying two things there, a result now and a team that needs less help next time, and only one of them appears on the invoice.
The version of that we see working splits by what each side is good at. Your team owns the continuous half, so the checks in the build, the definition of done, the component tests and the pass on every release. The outside audit owns the periodic half, so the full evaluation, the screen-reader sessions on real journeys, and the dated document somebody else can read. Neither half substitutes for the other, and the second one gets cheaper every time the first one does its job.
There is one more piece W3C adds and almost nobody buys. However good a group of evaluators is at conformance evaluation, an organization may want periodic review by users with a range of disabilities. That is not an audit and it does not produce conformance evidence. It answers a question conformance cannot, which is whether the thing is any good to use, and our guide to testing with disabled users covers how to run it.
The One Split You Should Never Collapse
Whoever makes a fix should not be the person who signs off that the fix worked. That is the split worth defending even when everything else is internal, and it is worth understanding why, because it is not about anybody's honesty.
A person who has just written a change knows what it was supposed to do, and that knowledge is exactly what stops them seeing what it actually does. They test the path they were thinking about. They reach the state they built for. They hear the announcement they were expecting, because they know what to expect. The double-fix regression, where a message ends up announced twice because two correct fixes were applied at once, is invisible to the person who applied both and obvious to anybody who did not.
Add money to that and it gets sharper. A supplier paid by the length of the repair job, who also wrote the list of repairs, and who then certifies its own work, has three roles and no check anywhere in the chain. Nothing in that arrangement is illegal and plenty of firms run it. It just means nobody has independently confirmed anything, and the person who eventually needs to rely on the result is the one who finds out.
There is no WCAG rule to cite here, and pretending otherwise would be exactly the kind of overstatement this site exists to argue against. What there is, in US federal practice, is a role split. One manager makes sure defects are logged, prioritized and resourced. A different one oversees compliance and validates the fixes. Executives sign off where the risk is high. The remediation plan is not retired until the validation happens, separately from the resolution. That is a governance control somebody thought worth writing down, and you can adopt the shape of it at any size.
Our own version of it is the reason our retest is worth reading. We sell no repair work, at any price, so we cannot have been the people who made your fixes. That costs us the part of this trade where the real money is, and it is what turns a verification into a check rather than a firm grading its own homework. The verification re-audit is where that lands as a product, and how we think about buying remediation is the guide we wrote instead of selling it.
Four Questions That Decide It For You
If the table did not settle it, these usually do. Answer them in order and stop at the first one that gives you an answer.
- Who reads the output? If the answer includes anybody outside your company, go outside. Everything after this question is about how much of the work stays inside.
- Which of the four capabilities do we actually have? Be honest about the assistive-technology one, because knowing a screen reader exists and being able to drive one are separated by about forty hours.
- Is anybody grading their own work? If the person testing is the person who built or fixed the thing, change one of the two, even if it stays internal.
- What happens between rounds? An audit is a photograph. If nothing internal runs between photographs, buying a bigger camera does not help.
What Neither Route Certifies
Whichever way you go, nobody hands you a certificate, because there is no such thing to hand you. WCAG has no certification scheme, no register of approved evaluators and no validation service. A conformance logo is itself a claim under the standard and has to carry all five required components, which means a badge with no date, no page list and no technology list is not a badge at all.
What either route produces is evidence, dated and scoped, about the pages somebody opened. An internal review produces evidence your own team can act on. An outside audit produces the same evidence in a form somebody else can weigh. Both are worth having, and neither is a certificate, which is why we do not sell one.
The most common mistake in this decision
It is not choosing wrong. It is choosing once. An internal review and an outside audit answer different questions, and most teams that get good at this end up running both on different clocks, so the continuous checks internally and the full evaluation periodically. If you are treating this as a single either-or purchase, the question to ask is what happens in the eleven months between audits, because that is where accessibility is actually won or lost.