What Makes an Audit Finding Defensible When a Competent Reader Pushes Back

A finding is the smallest unit of an audit that can be argued with. Everything else in a report is an arrangement of findings, and if the findings do not hold, nothing built on them holds either. The test of whether one holds is not whether the client accepts it in the meeting. It is whether it survives a competent reader who has an interest in it being wrong: the developer who wrote the code, the agency whose work is under review, the internal marketer whose budget the remediation will come out of.

Audit practice outside digital work settled on five elements a long time ago. Condition, criteria, cause, consequence and corrective action. The structure travels well. What does not travel is the assumption underneath it, which is that a published criterion already exists and both parties are bound by it. In digital work that assumption fails most of the time, and the failure is where most weak findings come from.

A report is bought, but what it asks for is larger than its fee. It asks a client to reallocate developer time, to delay something else, or to defend a decision internally to somebody who was not in the room. That is a persuasion problem, and there are only two ways to solve it. You can persuade by alarm, or you can persuade by verifiability.

Alarm is easier to write and it works exactly once. A report that opens with a score, a red band and a count of critical issues gets attention in the meeting, and then somebody checks one of the critical issues. If the check confirms the finding precisely, the reader extends credit to the forty findings they did not check. If the check finds the claim overstated by even a little, the reader re-reads the whole document sceptically, and they are right to.

Credit compounds across a document and it is withdrawn wholesale.

That asymmetry is the whole argument for being conservative. One finding that cannot be reproduced does not cost you one finding. It costs you the reader's willingness to accept anything they cannot personally check, which is most of the report.

Verifiability is not the same thing as detail. A finding can be long, technical and entirely unverifiable, and a paragraph of mechanism with no evidence attached is exactly that. A finding can also be three lines and completely verifiable, because those three lines name a URL, a retrieval time, a criterion and an observed value. Length is a cost the reader pays. Verifiability is the product.

Three kinds of sentence appear in audit reports, and they are routinely set in the same typeface, in the same list, with the same confidence. They are not the same claim and they do not carry the same burden.

• An observation states what is the case. The contact page at a given address returned HTTP 200 and its served markup contains no form element. Anybody can check it, and either it is true or it is not.
• An inference states what follows from the observation. Enquiries from that page therefore reach the business only through the email address in the footer. This is probably true, and it is not established by the observation alone.
• A finding states what is the case measured against a criterion, together with what the gap exposes. It is the only one of the three that can be agreed with, disagreed with or acted on, because it is the only one that contains a standard.

Most disputed findings are not disputed at the observation. The observation is usually correct, because it is the part that was actually checked. The dispute lands on the inference, and it lands there because the inference was written in the register of an observation: flat, present tense, unhedged, indistinguishable on the page from the thing that was verified.

The tell is an absent alternative. If a condition has two plausible explanations and the report names one without acknowledging the other, an inference has been laundered into an observation. A form element missing from the served markup might mean there is no form. It might mean the form is injected by a script the retrieval did not execute. Those two readings produce different findings, different causes and different fixes, and choosing between them requires a second piece of evidence rather than a confident tone.

None of this argues for removing inference from a report. Inference is most of the value, because a client can observe their own site, and what they are paying for is somebody who can say what the observation means. The argument is for marking it. An inference that announces itself, in the form the most likely explanation on the evidence available is, is a claim a reader can weigh. An inference disguised as a fact is a claim that will be checked, and when it fails it takes the observation down with it.

Three of the five elements do the arguing. Condition establishes that something is the case, criteria establishes that it should not be, cause establishes why it is. If those three hold, the remaining two are largely arithmetic. If any of the three is missing, what remains is a sentence with a severity label attached to it.

Condition: what is demonstrably the case

A condition is a single, present-tense, scoped statement of what is demonstrably true. Every one of those words is doing work. Single, because a condition containing two facts cannot be refuted cleanly, and a reader who disproves half of it will treat the whole as unsound. Present tense, because a condition set in the past is a story and cannot be rechecked. Scoped, because the difference between the site and the fourteen pages built on the service template is the difference between a finding and a complaint.

Demonstrably is the hard one. It rules out anything requiring the reader to trust your reading of the evidence rather than the evidence itself. The navigation is confusing is not a condition; it is a conclusion wearing the costume of one. The primary navigation exposes eleven top-level items, four of which lead to pages that redirect to the same destination, is a condition, because every clause in it can be checked by somebody with a browser.

Counting is where conditions most often go soft. If a condition says several pages, the reader cannot check it, because there is no state of the world that would make several wrong. If it says fourteen pages, the reader can check it, and if the fourteenth turns out not to qualify, the finding is damaged. That risk is worth taking. A number invites verification, and inviting verification is the entire point. Where an exact count is genuinely impractical, name the population and the sample instead: eleven of the twenty service pages examined, drawn from a template that generates forty.

Criteria: where they come from when nothing is published

A criterion is the sentence that says what should be the case. Without it, a condition is merely a description of the world, and the world is entitled to be like that. This is the element most often missing, and its absence is usually invisible, because a condition delivered with enough confidence reads as though a criterion were implied. There are four places a criterion can come from, and they are not equal.

• A published standard that genuinely covers the case. WCAG 2.2 is the clearest example in digital work: its success criteria are numbered, testable and public, so a finding can cite 1.4.3 Contrast (Minimum) or 2.4.7 Focus Visible and the reader can go and read the criterion themselves. Google Search Central documentation, the HTTP specifications and a framework's own documented behaviour serve the same role in their own domains.
• The client's own stated commitment. A published accessibility statement, a brand guideline, a signed specification, a documented internal policy. These are strong precisely because the client cannot dispute the standard without disputing themselves.
• A documented mechanism whose outcome is not a matter of preference. A redirect chain adds a round trip. A noindex directive removes a page from an index. Here the criterion is not that one thing is better than another, but that a stated intention and an implemented mechanism disagree.
• A criterion you author. Most findings about digital work end up here, because most of what an audit examines has no published standard and never will.

The counterfeit to watch for is a standard cited outside its scope. WCAG is the most abused, because it is public, numbered and carries obvious authority. It has a great deal to say about contrast, focus, target size and programmatic structure. It has, at AA, nothing to say about whether your copy is persuasive; reading level appears at AAA, and the distinction is not a technicality. Citing an accessibility standard to support a copywriting preference is worse than authoring the criterion yourself, because the reader who knows the standard now knows that you either did not read it or hoped that they had not.

Cause: the element most often skipped and most often wrong

Cause is skipped more often than any other element, and where it is present it is wrong more often than any other element. Both failures share a root: cause is the only element that cannot be read directly off the evidence.

The commonest wrong cause is the condition restated with a process noun bolted on. The images are unoptimised because there is no image optimisation process. That sentence carries no information. It cannot be false, it cannot be checked, and it points at no particular thing to change. A usable cause names a level instead.

• Instance. This one page was edited by hand and the edit removed the description. The fix touches one page.
• Template. Every page produced by the service template inherits the same title pattern. The fix touches one file and changes forty pages.
• Process. The template is correct and pages are drifting from it, because publishing passes through no check that would catch the drift. The fix is a gate, not a page.
• Incentive. The check exists and is routinely bypassed, because the person publishing is measured on volume and the check costs them a day. The fix is not technical at all, and reporting it as technical guarantees the condition recurs.

Getting the level wrong is expensive in a specific way. It produces a remediation that removes the symptom and leaves the mechanism, so the condition returns, and it returns after the engagement has ended and the report has been filed as complete. An instance fix applied to a template problem is the classic version. It looks like success for exactly as long as it takes to publish the next page.

The honest move, when the evidence does not reach the cause, is to say so. A finding that states the condition, names the criterion, and records that the cause is undetermined along with the single check that would determine it, is more defensible than one carrying a plausible guess. The guess costs nothing to write and a great deal to be wrong about, because the cause is what the client will use to decide who owns the fix.

The first three elements are what the finding argues. The last two are what the client does with it, and they fail in opposite directions: consequence tends to overclaim, corrective action tends to underspecify.

Consequence stated as exposure, not as prophecy

A prophecy says what will happen and how much it will cost. It is the most quoted line in any audit and the most fragile, because it is the one claim in the document with no evidence behind it at all. A percentage attached to a consequence is almost always a number the author did not measure and could not have measured from the artefacts they were given.

Exposure is the defensible form. It names what is at risk, who it affects, and the condition under which the risk realises, and then it stops. Nobody using only a keyboard can reach the enquiry form, because focus cannot enter the panel once it opens. That claim is testable and bounded, and the part you do not know, which is how many of this client's visitors it describes, is the client's to supply. Saying so explicitly is not weakness. It is the sentence that tells the reader you distinguished what you established from what you assumed.

Consequence also has to be commensurate with the criterion. If the criterion is a published standard the client has committed to, the consequence can be stated in the register of a breach. If the criterion is one you authored out of your own judgement, the consequence has to be stated in that register too, as a risk under a named assumption rather than as a violation. Findings lose credibility fastest when a soft criterion is paired with a hard consequence, because the mismatch is visible even to a reader who agrees with the underlying point.

Corrective action somebody else can execute

The test is mechanical. Could the person who will do the work start on Monday morning without asking you a question. If not, what you have written is a recommendation, and a recommendation is something the client must first convert into work before anything happens.

Improve internal linking is an outcome. Add a link to the pricing page from the three service pages listed above, in the body copy rather than in the footer, is a corrective action. The second one names an artefact, a change and a location, and it can be marked done by somebody who was never in the audit.

Three parts belong in a corrective action and usually only the first is written. The change itself. The verification, which is the specific check showing the criterion is now met and is often simply the original observation repeated. And the constraint that decides ownership: whether this is a content change, a template change or a build change, because that determines which queue it joins and what it costs.

Scope the change to the criterion rather than to your preferences. If the criterion is met by a small change, recommend the small change. If a larger rebuild would be better for reasons beyond this finding, that is a separate recommendation with its own criterion and its own justification. Bundling it into a remediation is the move that gets audits accused, often fairly, of manufacturing work.

What a corrective action must not do is settle the order of work. A finding can carry a severity, because severity is a property of the gap between condition and criterion. Priority is a property of the client's situation, set by consequence, cost and dependency together, and the two are not the same thing. An audit that hands over a numbered list of what to do first has quietly made budget decisions it has no standing to make.

Most findings about commercial websites rest on criteria nobody has published. No standard says that a service page should let a buyer form a cost expectation, or that a case study should name the constraint it worked within, or that a navigation label should describe a destination rather than the internal department that happens to own it. These are judgements. They can be good judgements, well founded and worth paying for, and they are still judgements.

The instinct is to hide that, either by borrowing a standard that does not quite fit or by writing the criterion so flatly that it reads as received wisdom. Both are worse than the alternative, which is to state the criterion, its basis and its limit inside the finding. In practice that is three lines.

• Criterion. A service page should state a price, a price range, or the reason no price is given.
• Basis. A buyer who cannot form any cost expectation defers the enquiry rather than making it, and a deferred enquiry is usually not made later.
• Limit. This is a judgement about buyer behaviour in this category rather than a published standard, and a business that withholds price deliberately, because its pricing is genuinely bespoke, may reject the criterion on strategy grounds without the finding being wrong about the condition.

The limit line feels like giving away the argument and is in fact the strongest sentence in the finding. It converts a disagreement about you into a disagreement about a proposition. A reader who rejects a named criterion has rejected one thing and can still accept the other thirty findings. A reader who senses an unstated criterion and dislikes it has no way to reject it locally, so they reject the author instead, and that judgement is not reversible in the same meeting.

A criterion you named can be argued with. A criterion you implied can only be resented.

There is a real limit to this. An authored criterion is worthless where the client needs the published one. If somebody is buying an audit to evidence a contractual or regulatory obligation, your judgement about buyer behaviour is not an acceptable substitute for the standard that obligation names, and the honest answer, when the standard does not cover the case in front of you, is that the case falls outside that scope. Saying so costs a finding. Not saying so costs the report at the moment it reaches somebody who knows the obligation better than you do.

Evidence in a digital audit is usually ranked by how much work it took to produce. That ordering is wrong. The useful ordering is by what each artefact establishes on its own, and by whether the reader can re-derive it without the author present.

What a live URL and a rendered page establish

A live URL is the strongest evidence available, for one reason: the reader can go and get it themselves. Nothing else in an audit has that property. It establishes the response status, the response headers, the served markup and, if the reader renders it, the resulting document. Claims about redirects, canonical elements, robots directives, status codes and served content all resolve here, and they resolve without the reader taking anything on trust.

It establishes less than it appears to, in two ways. First, it establishes the state at one moment of retrieval, from one location, with one user agent, through whatever caching sat in between. A page served from a cache in one region and freshly generated in another is a single condition only if you checked both. Second, live evidence decays. The page can change between your retrieval and the client's reading, which is not hypothetical when your report is the reason somebody changed it. A finding carrying only an address can be silently invalidated. A finding carrying the address, the retrieval time and the observed response can be reconciled with a later state rather than contradicted by it.

The distinction that matters most here is between served markup and rendered document. A claim about what a crawler encounters and a claim about what a person sees are different claims requiring different retrievals. Presenting one as evidence for the other is the most common technical overreach in audit writing, and it is trivially caught by anybody who checks.

What a screenshot establishes, and the inference it invites

A screenshot establishes that something rendered a particular way once: in one viewport, in one browser, at one zoom level, with a particular set of fonts loaded and a particular set of scripts having run. For visual conditions that is a great deal, and there is no substitute for it. For structural conditions it establishes almost nothing.

A screenshot cannot establish a contrast ratio. It can show that two colours look close, but the ratio comes from the colour values and the computation, and a finding citing 1.4.3 needs the values rather than the impression. It cannot establish focus order, because focus order is a sequence and an image is a moment. It cannot establish what a screen reader announces, because that is a different output entirely. It cannot establish that a page is slow; it can establish what a page looked like at a timestamp on a timeline, which is a narrower claim than most reports make with it.

The particular damage a screenshot does is the inference it invites. An unannotated image lets the reader construct the claim themselves, and the claim they construct is broader than the one you would have written. Then they check the broad claim, it fails, and the failure is attributed to you. Annotation is not decoration. Marking the region, stating what is being asserted about it, and recording the viewport and the time are what turn an image from a suggestion into evidence.

What an export, a design file or a spreadsheet establishes

Everything the client supplies is second-hand, and its reliability is inherited rather than established. That does not make it unusable. It makes provenance the whole question.

An export establishes what a system reported at export time, under whatever filters were applied, and the filters are the part that never survives into the file. A date range, a segment, a property, a timezone and a sampling threshold can each move the number by more than the finding claims to have found. An export used as evidence needs those recorded beside it, and where they cannot be recovered, the honest treatment is to use the export as an indication and to say plainly that is what it is.

A design file establishes intent, never implementation. It is evidence of what was specified, which makes it excellent for one class of finding, the gap between what was agreed and what shipped, and inadmissible for any claim about what a visitor currently experiences. Treating a design file as evidence of the live state is a category error that a developer will spot immediately and will remember.

A spreadsheet establishes whatever its author put in it, and its author is frequently unknown by the time it reaches an audit. Ask who produced it, from what, and when. A finding built on a supplied artefact can absolutely stand, because a client can reasonably be held to their own numbers, but the finding inherits every weakness of the source and it does so under your name. If the export was wrong, the finding is wrong, and it is yours.

Provenance is the least interesting part of a finding to write and the part that decides whether the finding survives contact with time. An audit is read in the meeting by people who were there. It is read six months later by a developer who was not, or by a new head of marketing deciding whether the previous agency was any good. Without provenance, findings age into assertions. The minimum record is short.

• What the artefact is. A URL, a file, an export, an image.
• Where it came from. Retrieved directly, supplied by the client, or generated during the engagement, and by whom if the answer is not you.
• When. A timestamp rather than a date, for anything retrieved live.
• How. The method, and the conditions that could change the result: the user agent, the viewport, whether scripts executed, whether a cache was bypassed.
• What state it recorded. The observed value itself, stored rather than described, so that a later state can be compared against it instead of argued about.

Then one sentence most reports omit: how to recheck. A finding that ends with the check that reproduces it, such as request this address and read this header, or open this page at this width and move focus to this control, has handed the reader the means to confirm it without you. That sentence is also what makes remediation verifiable later, because the check proving the condition is usually the same check that proves it is gone.

Provenance protects the author as much as the client. The most awkward moment in any audit review is a client saying the page has never been like that. With a recorded retrieval time and a stored response, that is a one-sentence exchange. Without them it is a disagreement between two memories, and the person being paid loses it.

Before a finding leaves the document, read it as the person with the strongest interest in it being wrong. That person is not the client. It is the developer who wrote the code, the agency whose work is under review, or the internal marketer whose budget the fix will come out of. They are frequently competent, they know the system better than you do, and they will read carefully because something is at stake for them. Six questions cover most of the failure surface.

• Is the condition true as stated, or true only of a subset I have described as the whole?
• Is the criterion named on the page, and does it cover this case rather than an adjacent one?
• Is the cause established by evidence, or asserted because it sounded likely?
• Does the consequence claim more than the evidence carries, or attach a number nothing measured?
• Could a competent person implement the corrective action exactly and still fail the criterion?
• Is there an explanation for the condition I have not considered, and would it change the fix?

The last question is the expensive one, and in mature products it has a specific shape: the deliberate decision. A great deal of what looks like oversight in a system that has been running for years is a choice somebody made, for a reason nobody wrote down, under a constraint that is no longer visible. A finding that does not admit the possibility gets one rebuttal in the room and does not recover. A finding that states its assumption, in the form on the evidence available this appears unintentional, and if it was deliberate the criterion still applies and the trade-off should be recorded, survives the rebuttal and frequently improves because of it.

The test has a cost, and it is worth naming. It slows a report down and it kills findings, which is the point: a document of eleven findings that all hold is worth more than one of forty where nine are wrong, because the nine take the thirty-one with them. Applied without discipline, though, it produces the opposite failure, a report so hedged that nothing in it can be acted on. Hedging is not accuracy. The output of the adversary test should be a confident claim with a named scope, not a timid claim with an open one, and where a claim cannot be made confidently at any scope the finding should be cut rather than softened.

What the adversary test cannot do is replace a second reader. An author checking their own reasoning is checking it with the same assumptions that produced it, which is why a genuine review pass is a separate discipline with its own order of operations. The adversary test is what you owe a finding before it reaches that reader, not instead of it.

The standard to hold a report to fits in one sentence. The client should be able to pick any finding at random, follow it to its evidence, and reach the same conclusion without asking the author a question.

That standard has structural consequences. Evidence belongs inside the finding rather than in an appendix, because appendices are read by nobody and cited only by people who already agree. The criterion belongs inside the finding rather than in a methodology section at the front, because the reader arguing with finding nineteen is not going to page back to discover which standard it was measured against. The recheck instruction belongs there for the same reason. Every part of the argument should sit within a few lines of the claim it supports.

It also explains what a client is buying, which is not the discovery. The discovery is real work and it is not the durable part. What survives an engagement is a document that keeps being persuasive when it is carried into rooms the author is not in: to a developer estimating the fix, to a finance conversation about next quarter, to whoever inherits the site in two years and needs to know whether the previous decisions were reasoned or arbitrary. A report whose claims only work with the author present is a performance. A report whose claims each terminate in something the reader can verify alone is an asset, and it goes on paying after the invoice is settled.

Zealsync develops Prooflin, a product for AI audits and professional reports, which is why the anatomy of a finding is something Zealsync has had to write down explicitly rather than leave to habit.