Start by working out which of four things you are actually disputing, because the four have completely different answers and a conversation that never names one runs in circles. Is the fact wrong, so the thing described does not happen on your site? Is the rule wrong, so it happens but breaks a different criterion? Is the level wrong, so it breaks a rule at AAA that got written up as a Level AA failure? Or is the severity wrong, so everybody agrees it fails and disagrees about how much it matters?
Only the first is a question about evidence. The second and third are questions about the standard, and they are settled by reading it, which takes about four minutes and costs nobody any pride. The fourth is a judgment call with no standard behind it at all, so it is a negotiation rather than a dispute, and it should be handled as one.
The truth is, plenty of challenged findings turn out to be right and plenty turn out to be overstated, and the reason is rarely carelessness on either side. It is that two honest testers can hold different assumptions about which browsers and screen readers your site is expected to work with, and those assumptions decide the answer. So this page is the sequence for finding out, and the six calls that come back overstated most often.
The Four-Step Dispute, in Order
Do these in order. Each step is cheap and each one resolves a fair share of cases before you get to the next, which is why the order matters more than any individual step.
- Reproduce it exactly as written. Same browser, same screen reader, same versions, same page state. Not your usual setup, theirs. Roughly half of that is not happening turns out to be that is not happening on my machine, and the difference is the whole finding.
- Read the criterion, not a summary of it. Open the rule the finding names and read the actual sentence. The exceptions live in the sentence, and most of the overstatements below are somebody remembering the gist rather than the wording.
- Check the level. A stricter version of the same idea exists at AAA for several rules, and a Level AAA test written up as an AA failure is the single commonest kind of overstatement there is.
- Then ask about the baseline. If it reproduces for them and not for you, you are not disagreeing about the site. You are testing different combinations of browser and assistive technology, and both results can be true.
Six Calls That Come Back Overstated
Each of these is a real finding about a real thing on your page. What is wrong is the conclusion, and in five of the six the mistake is borrowing a stricter rule than the one you are being measured against. Check the wording column against the report you are holding.
| Reported as | What the rule says | Where the stricter version lives |
|---|---|---|
| Focus ring partly hidden behind a sticky header | 2.4.11 asks that the component is not entirely hidden. Partly covered passes. | 2.4.12 Focus Not Obscured (Enhanced), Level AAA, which forbids any part being hidden |
| A greyed-out disabled button fails contrast | 1.4.3 excepts text that is part of an inactive user interface component, and 1.4.11 excepts inactive components too. Two rules, same exception. | Nowhere. A disabled control is out of scope for both contrast rules at every level. |
| A Read more link has no purpose | 2.4.4 Link Purpose (In Context) is Level A and accepts the link text together with its programmatically determined context, so a card whose heading names the destination conforms. | 2.4.9 Link Purpose (Link Only), Level AAA, which requires the link text alone to carry it |
| Duplicate IDs on the page | Nothing. 4.1.1 Parsing was removed from WCAG 2.2 and is treated as always satisfied in the versions that still list it. | Nowhere. Real problems that used to get filed here belong to other criteria and should be written up under those. |
| The page must have exactly one h1 | Nothing. No such requirement appears anywhere in WCAG, at any level. It is a tool's own best-practice flag wearing a rule number. | Nowhere. Heading structure is 1.3.1 and 2.4.6, and neither counts your h1 elements. |
| The scanner passed it, so the manual finding is wrong | A passing automated rule usually does not settle the criterion. Of the live rules W3C publishes, a passed result records the criterion as still needing further testing on 59 of them, and settles it outright on four. | Not a level problem. A clean scan is evidence about what a machine checked, and it is not evidence against a person who looked. |
One warning about winning these. A finding being overstated at your conformance level does not make the underlying thing good. A focus ring half swallowed by a header passes 2.4.11 and still makes your site harder to use with a keyboard. So the honest way to close that argument is to move it out of the conformance list and into the backlog, rather than out of the conversation altogether.
When Two Honest Audits Disagree, Read the Baseline
This is the mechanism behind most of the disputes that survive the first three steps, and it is not anybody's fault. WCAG requires that the ways you use a technology are supported by the software your readers actually have. It deliberately declines to say which software that is, because the answer depends on your audience, your language, the technologies your site is built from and what people in your market run.
So W3C's evaluation methodology asks the evaluator to write that list down before testing starts and to agree it with whoever is paying. It calls that list the accessibility support baseline. A custom combobox can behave correctly in one screen reader and browser pair and fall apart in the next one along. Tested against a baseline naming the second pair, it is a finding. Tested against a baseline that does not, it passes. Neither tester was careless. They measured different things.
Which gives you a question worth asking early, and it is not accusatory. What baseline was this tested against, and where is it written down? If the answer is a list, you can check whether your audience matches it and the disagreement usually dissolves into a scoping decision. If there is no answer, the testing happened against whatever was installed on somebody's laptop, and that is a bigger problem than the finding you were about to argue with. Our guide to W3C's evaluation methodology covers what the baseline is and why the method treats it as mandatory.
When the Vendor Says Supports and Your Test Fails
This is the same argument with a supplier on the other end of it, and it has a specific explanation that is worth knowing before anybody accuses anybody of anything. A vendor's accessibility conformance report can say Supports on a criterion your own testing just failed, and both statements can be literally true at the same time.
The reason is in the definition. The templates these reports are built from define Supports as meaning the product has at least one method that meets the criterion without known defects. One working method, and known defects only. It does not say every path works, it does not say the vendor looked hard, and a vendor is even allowed to change the definitions as long as they say so in the report's notes. Two reports using the same word may not mean the same thing, and the only way to find out is to read the notes.
There is a second structural reason, and it is the one that surprises people. At Levels A and AA those templates give a vendor no way to record that a criterion was not tested. The Not Evaluated answer exists and can only be used on Level AAA rows. So at the two levels that carry legal weight, an untested criterion and a tested-and-passing criterion look identical on the page. That is a property of the template, not evidence of bad faith, and it changes what you should ask for.
| Check | Why it comes first | What a good answer looks like |
|---|---|---|
| The product version | A report describes a build. If theirs is 4.2 and you are running 4.7, you are comparing two different products and the conflict may not exist at all. | A specific version, not a product name, plus the date the evaluation was carried out rather than the date the document was written |
| The scope | A report may cover the core application and not the module you bought, or the web client and not the embed you dropped into your page. | A written description of what was evaluated, including which components and configurations |
| The path you tested | Supports needs one working method. If they tested the keyboard route through the wizard and you tested the drag route, both results stand. | Either an acknowledgement that a second path fails, or a demonstration of the path they tested |
| The remarks column | Every row is supposed to explain why the conformance level was chosen. An empty remark on a row you can fail is a question, not proof of anything. | A remark specific enough that you could reproduce the vendor's own result |
| Whether the terms were redefined | The templates allow a vendor to deviate from the standard definitions if the change is referenced in the notes. | The notes section, read, and the definitions actually used |
Then send them what you have rather than an opinion. The page, the build, the pairing, the steps, and what you observed. A supplier who gets a reproducible report usually fixes it or explains it, and a supplier who gets your VPAT is wrong usually sends you the VPAT again. Our guides to what a VPAT is and what one cannot tell you cover the document itself in full.
What to Send When You Raise It
A dispute is a piece of evidence meeting another piece of evidence, so send evidence. Five things, and they fit in one message.
- The finding reference, so nobody has to work out which item in a list of twenty-odd you mean.
- Which of the four things you are disputing. The fact, the rule, the level, or the severity. Say it in the first line.
- What you did and what happened, with your browser, your assistive technology and their versions, and the page state you reached.
- The sentence you are relying on, if the dispute is about the rule or the level. Quote the criterion, not a summary of it.
- What you would accept as settling it. A retest on a named pairing, a corrected level, a moved severity band. A dispute with no proposed ending runs forever.
And ask for their working. W3C's methodology tells evaluators to archive what they tested and what they tested it with, and it names conflict resolution as a reason to do it. That archive is internal by default unless you asked for it when the work was scoped, which makes the evidence pack comes to us a line worth putting in a brief rather than a favor to request afterwards.
When You Turn Out to Be the One Who Is Wrong
It happens, often, and usually in one of two shapes. The first is a page state you did not think to reach, so the error message that seemed fine on load says nothing after a failed submit, and the tester went there and you did not. The second is a difference between what the screen shows and what the software reads, which is the whole discipline in one sentence. A label sitting visibly beside a field is not attached to that field unless something attaches it, and the eye cannot tell the difference.
That second one is worth internalizing because it is the source of the argument that feels most unfair. Your developer is not being told the label is missing. They are being told the label is not connected, which is a claim about the markup rather than about the design, and it is checkable in about ten seconds by anybody with a browser inspector open.
One honest limit on this page
None of this tells you whether an auditor's price was fair, and we stay out of that on purpose. Whether their findings are true is an evidence question, which is checkable. Whether their quote was reasonable is a business judgment, which is not ours to make about somebody else's work. If you want the findings checked rather than argued with, our second opinion audit retests every one on your own live pages and marks it confirmed, overstated, or plain wrong. It also names the pages it did not reach, rather than letting silence stand in for a pass.
The Habit That Prevents Most of This
Almost every dispute worth having traces back to something nobody wrote down at the start. So write it down at the start. Agree the baseline before testing, so the yardstick is shared. Agree the conformance level, so nobody borrows a AAA rule by accident. Agree whether findings are listed per occurrence or per criterion, so the count means the same thing to both sides. And agree that the evidence pack is yours, so a disagreement six weeks later has something in it to settle the question.
Four sentences in a scoping email. They cost nothing, and they turn the arguments you were going to have into decisions you already made.