Which axe-core failures are real WCAG failures, and which are not

A scan finishes and hands you a list of violations. Before that report goes to a buyer or into a ticket queue, someone has to decide which findings a reviewer would count as a failure of a WCAG success criterion and which are the tool’s own advice.

The report already carries the answer, in a field that explains nothing about itself. doc/API.md lists the properties on every entry in the violations, passes, incomplete and inapplicable arrays: description, help, helpUrl, id, impact, tags and nodes. Only tags separates a WCAG failure from vendor advice, and its published description is a single line, “Array of tags that this rule is assigned.” What the individual tags mean, which rules carry them, and which rules never ran at all live in other files that ship with the library.

Read those once and a flat list becomes three piles: findings that cite a WCAG criterion, findings that cite the vendor’s own judgment, and results the tool declined to decide.

Everything below is read out of axe-core 4.13.0. The npm registry records it as dist-tags.latest, published 5 August 2026. Version matters more than it looks like it should, and a later section shows why.

The rule file behind the tags

axe-core publishes doc/rule-descriptions.md, whose first line declares that it “is automatically generated using build/configure.mjs.” It describes the shipped software rather than marketing it. At tag v4.13.0 it carries seven ## rule sections and 105 rules, and parsing the enabled field and tags out of package/axe.js in the published tarball returns the same 105, rule for rule.

Section as published	Rules	On by default	Off by default
WCAG 2.0 Level A & AA Rules	60	60	0
WCAG 2.1 Level A & AA Rules	2	2	0
WCAG 2.2 Level A & AA Rules	1	0	1
Best Practices Rules	27	27	0
WCAG 2.x level AAA rules	3	0	3
Experimental Rules	7	0	7
Deprecated Rules	5	0	5
Total	105	89	16

Counts are axe-core 4.13.0, released 5 August 2026, from doc/rule-descriptions.md at tag v4.13.0 and the enabled field in the shipped axe.js.

Four of the seven sections carry a sentence under the heading explaining that they are switched off. “WCAG 2.0 Level A & AA Rules” and “WCAG 2.1 Level A & AA Rules” carry no explanatory sentence at all. The only sections that say anything about the default are the sections that are off.

A default scan runs 89 rules. Sixty-two carry a WCAG success criterion tag. Twenty-seven carry the tag best-practice and no WCAG criterion tag at all. That 27 is the number to hold onto.

What “disabled by default” means in the shipped code

The documentation and the code disagree here, and the difference determines what a custom configuration can turn back on.

doc/API.md states, under its options examples, that “The default operation for axe.run is to run all rules except for rules with the ‘experimental’ tag.” That sentence is incomplete. Read package/axe.js from the published 4.13.0 tarball and two separate mechanisms are doing the work:

1. An enabled: false field on the rule definition. Exactly nine rules carry it in 4.13.0: aria-roledescription, audio-caption, color-contrast-enhanced, duplicate-id-active, duplicate-id, identical-links-same-purpose, landmark-complementary-is-top-level, meta-refresh-no-exceptions and target-size.
2. A tag exclusion list on the audit object. The shipped bundle sets this.tagExclude = [ 'experimental', 'deprecated' ], and axe.getRules returns a rule’s effective state as matchingRule.enabled && !matchingRule.tags.some(function(tag) { return tagExclude.includes(tag); }).

The same file gets closer elsewhere, describing enabled as “false for rules that are disabled by default (i.e. experimental and deprecated rules).” That parenthetical still misses four rules: color-contrast-enhanced, identical-links-same-purpose, meta-refresh-no-exceptions and target-size are off by an enabled: false flag alone and are neither experimental nor deprecated.

The consequence runs the other way for the seven experimental rules, which do not carry enabled: false at all. They are off by tag exclusion, and the exclusion is dropped only for a tag the configuration itself names: matchTags in the shipped bundle computes exclude = defaultExclude.filter(function(tag) { return include.indexOf(tag) === -1; }). So a pipeline running runOnly: { type: 'tag', values: ['wcag2a', 'wcag2aa'] } does not reach them, including the three experimental rules that carry wcag2a: p-as-heading, table-fake-caption and td-has-header. Three configurations do reach them: naming experimental in the tag list, naming rules by id with runOnly: { type: 'rule', values: [...] }, which ruleShouldRun honors on id membership alone, or flipping a single rule with rules: { 'p-as-heading': { enabled: true } }. All five deprecated rules are off by both mechanisms, carrying enabled: false and the deprecated tag.

View the data as a table

	enabled: false field	Tag exclusion list
Where it lives	A field on the rule definition in the shipped package/axe.js	this.tagExclude on the audit object, set to experimental and deprecated
Rules it holds down in 4.13.0	Exactly nine rules carry the field	The seven experimental rules and the five deprecated rules
Rules off by this alone	color-contrast-enhanced, identical-links-same-purpose, meta-refresh-no-exceptions and target-size	The seven experimental rules, which carry no enabled field at all
What doc/API.md says about it	False for rules that are disabled by default, a parenthetical that misses four of the nine	Names only the experimental tag, and the shipped list also excludes deprecated
Rules held down by both	All five deprecated rules carry the field	All five deprecated rules carry the tag

The tags are the vocabulary that maps a finding to a standard

doc/API.md states the rule plainly: “Each rule in axe-core has a number of tags. These provide metadata about the rule. Each rule has one tag that indicates which WCAG version / level it belongs to, or if it doesn’t, it has the best-practice tag. If the rule is required by WCAG, there is a tag that references the success criterion number. For example, the wcag111 tag means a rule is required for WCAG 2 success criterion 1.1.1.”

That is the whole decode: a finding carries either a WCAG level tag or best-practice, with no third state. What each tag lets you claim is a separate question, and the right-hand column below is this article’s reading, not axe-core’s.

Tag	axe-core’s own gloss	What a finding with it supports
wcag2a	WCAG 2.0 Level A	A criterion incorporated by the Revised Section 508 Standards at E205.4
wcag2aa	WCAG 2.0 Level AA	The same, at Level AA. Three rules: color-contrast, meta-viewport, valid-lang
wcag21a	WCAG 2.1 Level A	Bears on rules that name WCAG 2.1. The only rule with this tag is experimental and off
wcag21aa	WCAG 2.1 Level AA	Three rules, two of which run by default
wcag22aa	WCAG 2.2 Level AA	One rule, target-size, and it is off by default
wcag2aaa	WCAG 2.0 Level AAA	Above the Level A and AA that E205.4 incorporates. All three rules off by default
wcag2a-obsolete	WCAG 2.0 Level A, no longer required for conformance	The 4.1.1 Parsing removal. Both rules deprecated and off
best-practice	Common accessibility best practices	Not a WCAG failure. 27 rules, all on by default
ACT	W3C approved Accessibility Conformance Testing rules	Alignment with a W3C-published test rule, which is informative, not required for conformance
section508	Old Section 508 rules	The 2001 Section 508 paragraphs, not the Revised 508 Standards in force today
TTv5	Trusted Tester v5 rules	Alignment with the DHS process a federal reviewer may run
EN-301-549	Rule required under EN 301 549	A European procurement standard, not US law
RGAAv4	Rule required under RGAA	A French methodology. A best-practice rule can carry this too
experimental	Cutting-edge rules, disabled by default	Off by tag exclusion, not by an enabled flag
cat.*	Category mappings used by Deque	Grouping only

Two shipped tags are missing from that published table. deprecated is absent, although five rules carry it and the audit excludes it; its only gloss is the line in rule-descriptions.md that deprecated rules “are disabled by default and will be removed in the next major release.” review-item is absent too, carried by frame-tested and hidden-content, with no published gloss in axe-core 4.13.0.

One caution against reading a criterion-number tag as a level: scrollable-region-focusable sits in the WCAG 2.0 A and AA section and carries both wcag211 and wcag213, and 2.1.3 Keyboard (No Exception) is Level AAA. The section heading and the level tag tell you the level; the criterion number does not.

A criterion tag is not a verdict on the criterion

The decode above answers which standard a rule was written against. It does not answer whether that standard was failed, and the difference is where a careful reviewer will push back first.

A rule tagged wcag141 was written against 1.4.1 Use of Color, which WCAG 2.2 states in full as: “Color is not used as the only visual means of conveying information, indicating an action, prompting a response, or distinguishing a visual element.” The only enabled axe-core rule carrying that tag is link-in-text-block, published as “Ensure links are distinguished from surrounding text in a way that does not rely on color.” A link in a paragraph is one of the ways color can be the only visual means. The rule tests that one, on the elements it can evaluate. A finding reports that the rule’s narrower test failed on a node. A criterion failure is a judgment about the page.

No false-positive rate for any axe-core rule appears in the package, the changelog or the documentation, and none turned up in the research for this article. So the tag supports an entry on a defect list and a pointer to the criterion it was written against. Reading it as a settled conformance failure is the same error as reading a clean scan as conformance, run in the other direction.

View the data as a list

1. The rule carries the tag wcag141: It was written against 1.4.1 Use of Color
2. The rule tests one narrower thing: link-in-text-block, on the elements it can evaluate
3. A finding says the test failed: No false-positive rate is published
4. A criterion failure is a judgment: About the page, so the tag supports a defect list entry

Twenty-seven rules run by default that are not WCAG rules

The Best Practices section of rule-descriptions.md defines itself in one sentence: “Rules that do not necessarily conform to WCAG success criterion but are industry accepted practices that improve the user experience.”

All 27 run by default and land in the violations array beside WCAG failures, with the same impact labels. Their ids include region, heading-order, landmark-one-main, skip-link, tabindex and empty-heading. Two of them describe markup worth having in a design system: content contained within landmarks and hierarchical heading order.

Neither is a success criterion. WCAG 2.2, the W3C Recommendation of 12 December 2024, defines Level AA conformance at section 5.2.1 as the state in which “the web page satisfies all the Level A and Level AA success criteria, or a Level AA conforming alternate version is provided.” A rule mapped to no success criterion cannot move that determination either way. Ten open region findings and zero WCAG failures is not evidence of non-conformance on any success criterion, and a report presenting both as “40 violations” has merged two kinds of claim into one number.

The reverse error inflates a remediation sprint sized against a raw violation count, because part of that count is advice, and a supplier folding best-practice findings into a “does not support” row on an Accessibility Conformance Report has overstated its own non-conformance. Our guidance on what belongs in a conformance claim works through that line.

Say plainly what is not known. No published decision, agency finding or resolution agreement turned up in the research for this article that turns on which axe-core rule section a finding came from. Whether an unremediated best-practice finding carries legal weight has, so far as this research found, never been decided anywhere. The argument above rests on the definition of conformance, not on precedent.

The one WCAG 2.2 rule ships switched off

The section headed “WCAG 2.2 Level A & AA Rules” contains one rule, target-size, tagged wcag22aa. There is no wcag22a tag in axe-core 4.13.0, so the heading is broader than its contents. The sentence under it states the reason for the default: “These rules are disabled by default, until WCAG 2.2 is more widely adopted and required.”

target-size also carries enabled: false, so it is off by both mechanisms. A default scan of a page with 20-pixel tap targets returns nothing about them, and that silence is not evidence. Turning it on takes one line, rules: { 'target-size': { enabled: true } }, and adds findings no US rule in force asks for. If your obligation or a buyer’s solicitation names WCAG 2.2, touch target size and spacing has to be covered one way or the other.

The default is defensible. eCFR full-text search on 21 August 2026 returned “WCAG 2.2” in exactly one place in the entire Code of Federal Regulations, Appendix D to 28 CFR part 35, which is the Department of Justice’s discussion of its Title II rule rather than an operative provision. As we set out in which WCAG version each US rule requires, no rule in force requires it. That is a product decision, and it is reversible by configuration.

Eight default rules can never produce a violation at all

rule-descriptions.md carries an “Issue Type” column with three values: failure, needs review, and both. Across the 89 default rules, 39 can only produce a failure, 42 can produce either, and eight can only ever produce a needs-review result.

doc/API.md defines what lands there. The incomplete array “indicates which nodes could neither be determined to definitively pass or definitively fail,” and its contents are separated out “in order that a user interface can display these to the user for manual review.” The same file adds that such results “were aborted and require further testing. This can happen either because of technical restrictions to what the rule can test, or because a JavaScript error occurred.”

Rule id	What it checks	WCAG tag
aria-braille-equivalent	Ensure aria-braillelabel and aria-brailleroledescription have a non-braille equivalent	wcag412
bypass	Ensure each page has at least one mechanism for a user to bypass navigation and jump straight to the content	wcag241
duplicate-id-aria	Ensure every id attribute value used in ARIA and in labels is unique	wcag412
form-field-multiple-labels	Ensure form field does not have multiple label elements	wcag332
frame-title-unique	Ensure <iframe> and <frame> elements contain a unique title attribute	wcag412
no-autoplay-audio	Ensure <video> or <audio> elements do not autoplay audio for more than 3 seconds without a control mechanism to stop or mute the audio	wcag142
server-side-image-map	Ensure that server-side image maps are not used	wcag211
video-caption	Ensure <video> elements have captions	wcag122

Two different things put a rule in that list. Five of the eight are declared that way: aria-braille-equivalent, bypass, duplicate-id-aria, frame-title-unique and no-autoplay-audio carry reviewOnFail: true in the shipped bundle, which routes a failed check to incomplete instead of violations. The other three have checks that ship no failure message at all. The multiple-label check behind form-field-multiple-labels, for instance, defines a pass message and an incomplete message and nothing else, so there is no wording in which the tool could report a violation.

Read the list against the criteria it names. Captions on video under 1.2.2 and a mechanism to bypass repeated blocks under 2.4.1 sit squarely inside Level A. A clean violations array with those two rules parked in incomplete is not a page that passed 1.2.2 and 2.4.1. It is a page where the tool declined to rule.

ACT Rules Format 1.1, a W3C Recommendation of 5 February 2026 published as REC-act-rules-format-1.1-20260205, is more precise about this than any tool report. Its conformance requirements state what a non-failing result means: “When all of the outcomes are passed or inapplicable for a test subject, the accessibility requirement could be satisfied or further testing is needed for the test subject.” Could be satisfied, or further testing is needed. WCAG works the same way: its success criteria “do not evaluate to passed, failed or inapplicable. Rather they can be satisfied (or not).”

Take that as an analogy rather than a rule binding axe-core. The Rules Format governs ACT rules, and 25 of the 89 default rules carry the ACT tag. It is the closest thing to a normative statement of what a non-failing automated result means, and it does not say the criterion is satisfied.

What nobody has published is what a reviewer should do with a needs-review result. ACT Rules Format has a cantTell outcome, axe has incomplete, and no source verified for this article states what an auditor or a federal reviewer is expected to conclude from either.

The other ceiling: what has a published test rule at all

Everything so far is about reading a report you have. The harder question is what a scan was never positioned to raise, and it can be bounded without any vendor’s claim.

W3C WAI publishes a catalog of ACT Rules indexed by success criterion. Each criterion either lists rules or prints “No ACT Rules available for this criterion yet.” The method, so you can re-run it: fetch the page with a browser user agent, enumerate every li.act-rule inside every div.sc-item whose data-level is a or aa, deduplicate by rule id, and exclude data-status="deprecated", as the page’s own counter does. Three rules under Level A and AA criteria are deprecated and are excluded everywhere below. Queried 21 August 2026; page last-modified 19 August 2026.

WCAG 2.2 has 55 success criteria at Levels A and AA, counted directly from the Recommendation: 31 at Level A, 24 at Level AA. Of those 55, 31 have at least one ACT rule and 24 have none, and only 18 have a rule that is approved rather than proposed. The catalog’s own counter that day read: “Showing 84 rules for 31 of 55 selected WCAG Success Criteria and 6 rules for ARIA.”

All six criteria WCAG 2.2 added at Level A or AA are in that group of 24, alongside long-standing criteria that carry a large share of real barriers.

Criteria with no ACT rule, Level A	Criteria with no ACT rule, Level AA
1.3.2 Meaningful Sequence	1.2.4 Captions (Live)
1.4.1 Use of Color	1.4.11 Non-text Contrast
2.3.1 Three Flashes or Below Threshold	1.4.13 Content on Hover or Focus
2.4.3 Focus Order	2.4.5 Multiple Ways
2.5.1 Pointer Gestures	2.4.11 Focus Not Obscured (Minimum)
2.5.2 Pointer Cancellation	2.5.7 Dragging Movements
3.2.1 On Focus	2.5.8 Target Size (Minimum)
3.2.2 On Input	3.2.3 Consistent Navigation
3.2.6 Consistent Help	3.2.4 Consistent Identification
3.3.2 Labels or Instructions	3.3.3 Error Suggestion
3.3.7 Redundant Entry	3.3.4 Error Prevention (Legal, Financial, Data)
	3.3.8 Accessible Authentication (Minimum)
	4.1.3 Status Messages

Set the axe-core side beside it. Take the 89 default rules, read their wcagNNN tags, expand each to a criterion number and intersect with the 55: 19 criteria have at least one enabled axe-core rule tagged to them, and 36 have none. Twenty-two of the 55 have neither. Two have an enabled axe rule but no ACT rule: 1.4.1 Use of Color, where links must be distinguished from surrounding text by more than color, and 3.3.2 Labels or Instructions. Note what the second one is worth. The only enabled axe-core rule tagged wcag332 is form-field-multiple-labels, one of the eight that can only ever return a needs-review result, so 3.3.2 counts toward the 19 on the strength of a rule that cannot report a violation.

View the data as a table

	Published ACT rules	Enabled axe-core rules
Criteria of 55 with at least one rule	31	19
Criteria of 55 with none	24	36
Rules behind the count	84 rules for Level A and AA criteria, plus 6 for ARIA	The 89 rules on by default, read through their wcagNNN tags
The caveat on the count	47 of the 84 are still proposed, and only 18 criteria have an approved rule	A tag is not coverage, and it does not mean any of the 19 is fully tested

Bucket	Criteria
Has at least one ACT rule and at least one enabled axe-core rule	17
Has an ACT rule but no enabled axe-core rule	14
Has an enabled axe-core rule but no ACT rule	2
Has neither	22
Total	55

ACT catalog queried 21 August 2026. axe-core column is 4.13.0, rules on by default only, counted from wcagNNN tags.

Four qualifications, all narrowing the claim rather than widening it.

This is not automatability. ACT Rules Format is explicit that a check “can be a step by step description of how to manually perform a test, a fully automated test, or some combination of manual and automated testing.” Six of the 84 rules mapped to Level A and AA criteria record no implementation at all, which means none is on record, not that the rule cannot be automated.

ACT rules are not requirements. The catalog says of them: “they are not required for determining conformance to WCAG or ARIA.” The Rules Format is a Recommendation; the rules themselves are informative, and 47 of the 84 under Level A and AA criteria are still proposed, agreed by the ACT Task Force but not approved by a Working Group. No source states how long approval takes.

A tag is not coverage. Nineteen of 55 counts criteria that at least one enabled rule is tagged to. It does not mean any of them is fully tested, and expressing it as a coverage percentage would be wrong.

The mass is concentrated. Three criteria carry the largest rule counts on both sides: 4.1.2 Name, Role, Value has 15 ACT rules and 28 enabled axe rules, 1.3.1 Info and Relationships has 13 and 9, and 1.1.1 Non-text Content has 8 and 7. Before anyone treats report length as a measure of a site, that is where the volume comes from.

axe-core’s README states that “you can find on average 57% of WCAG issues automatically.” No sample, denominator, corpus or date for it appears in the package, the changelog or the documentation. Report it as the vendor’s claim, say in the same sentence that no method is published for it, and derive no complementary figure from it.

The inventory is not stable, so neither is your report

Rule sections move between releases, and a moved rule changes what a default scan says about an unchanged page.

Release	Date	Total	2.0 A/AA	2.1 A/AA	2.2	Best practice	AAA	Experimental	Deprecated
4.10.0	2024-07-29	104	59	2	1	28	3	7	4
4.11.0	2025-10-09	104	59	2	1	28	3	7	4
4.12.0	2026-06-01	105	60	2	1	27	3	7	5
4.13.0	2026-08-05	105	60	2	1	27	3	7	5

Release dates from the npm registry time object; section counts from doc/rule-descriptions.md at each tag.

Exactly two inventory changes happened between 4.11.0 and 4.12.0, both confirmed by diffing the rule id sets: aria-tab-name was added to the WCAG 2.0 Level A and AA section, and landmark-complementary-is-top-level moved from Best Practices to Deprecated, which turned it off. Between 4.12.0 and 4.13.0 no rule was added, removed or moved.

Follow that second change to its consequence. A page raising a landmark-complementary-is-top-level finding under 4.11.0 raises nothing under 4.12.0, with no change to the page. Any violation count in an evidence file, an ACR appendix or a ticket backlog is a count against a versioned rule set and needs that version written beside it. A workable cadence: on every minor version bump, re-read rule-descriptions.md at the tag your pipeline actually resolves and diff the section membership.

View the data as a list

1. Two rule changes land in 4.12.0: Confirmed by diffing the rule id sets
2. One rule moves to Deprecated: landmark-complementary-is-top-level
3. The same page raises nothing: It raised the finding under 4.11.0
4. So the count needs its version: In an ACR appendix or a backlog

What a federal reviewer runs instead

If the report is going near a federal buyer, the standard it will be read against is not the scanner’s.

OMB Memorandum M-24-08, Strengthening Digital Accessibility and the Management of Section 508, dated 21 December 2023, tells agencies to scan and then bounds what scanning settles. Agencies “should leverage automated testing tools in combination with targeted manual testing because automated testing tools cannot fully assess conformance to accessibility standards,” and footnote 31 gives the reason: “Automated testing cannot evaluate the criteria of accessibility standards that require human subjectivity.” The memorandum names the substitute: agencies “should perform manual conformance validation testing, such as the Trusted Tester Conformance Test Process for the Web, in addition to automated testing.”

The Access Board’s ICT Testing Baseline for Web, version 3.1 published 1 April 2024, defines the coverage a Section 508 test process should reach and names no tool for it: “The Baseline for Web does not identify testing tools … No tools are identified to help perform the tests.” DHS states that its Trusted Tester process “follows the ICT Testing Baseline, which meets the minimum requirements for Revised 508 standards (including WCAG 2.0 Levels A and AA).”

Note what that does to one axe-core tag. Nineteen default rules carry section508, glossed as “Old Section 508 rules,” with sub-tags that are 2001-era paragraph numbers in the form section508.22.a. Those paragraphs are still printed in the Code of Federal Regulations, at Appendix D to 36 CFR part 1194, headed “Electronic and Information Technology Accessibility Standards as Originally Published on December 21, 2000.” Their remaining job is narrow: E202.2 exempts existing ICT that complies with the earlier standard “as republished in Appendix D” and “has not been altered on or after January 18, 2018.” What governs federal electronic content otherwise is Appendix A at E205.4: “Electronic content shall conform to Level A and Level AA Success Criteria and Conformance Requirements in WCAG 2.0.” Nothing in axe-core maps to the Revised provisions directly, and no source verified for this article explains why the older mapping was kept. The TTv5 tag, on 37 default rules, points at a process a federal reviewer might run. We compare the two modes in automated versus manual accessibility testing.

What to do with the report on your screen

1. Record the version. Print the axe-core version into the report artifact. A violation count without it cannot be compared to next quarter’s.
2. Split on tags, not on impact. Every entry in violations carries a tags array. violations.filter(v => v.tags.includes('best-practice')) is the advice pile and the complement is the WCAG pile. Conformance is defined at 5.2.1 in terms of satisfying success criteria, and severity does not enter that definition, so the two piles belong in different sections of any document making a conformance statement.
3. Treat the incomplete array as work, not noise. Eight default rules produce nothing else, and two sit on Level A criteria.
4. Write down what was off. One WCAG 2.2 rule, three AAA rules, seven experimental and five deprecated did not run. If your obligation reaches any of them, say how they were covered instead.
5. Name the criteria no rule touched. Thirty-six of the 55 Level A and AA criteria have no enabled axe-core rule tagged to them. A test plan that stops where the scan stopped has 36 open questions in it, and a WCAG audit closes them.

One honest gap. The axe browser extension is a separate product, and axe-core’s documentation disagrees with itself about it. Released 4.13.0 says experimental rules “are disabled by default in axe-core, but are enabled for the axe browser extensions.” The unreleased develop branch of the same file says they are “disabled by default in axe-core and the axe browser extensions.” Which is true of the extension on your machine cannot be determined from axe-core, and no rule count for it is published in any source verified here. If your evidence came from the extension rather than the library in CI, the section table above is a guide, not a manifest.

Where this stops

Everything above is a reading of published software metadata and published standards. It tells you what a finding claims and what it does not claim. It does not tell you what exposure any particular unremediated finding creates, how to answer a demand letter, or how to word a representation in a contract. Those are questions for your counsel, and the answer to them turns on facts about your organization that no rule file contains.

The part that is ours is the part before that: knowing which findings map to a criterion, which criteria no scan reached, and what has to be tested by hand to close the difference. If you are holding a scan report and a buyer’s requirement and the two do not obviously line up, send us both and we will mark which findings would survive a reviewer and which criteria the scan never reached.