Will a federal buyer accept your accessibility test evidence?
By David LoPresti July 15, 2026 One question, three separable parts
You are holding an Accessibility Conformance Report, a test report behind it, and a submission window that closes soon. Someone on the other side of the transaction has to decide whether the evidence is good enough, and neither of you has a published rule to point at. The vendor asks the question one way, “will you accept our test evidence?” The reviewer asks it the other way, “is this enough to award on, or do I send it back and fund a retest?”
It is one question with three separable parts, and they get tangled because the market talks about all three using the single phrase “Trusted Tester.”
- Coverage. Does the method behind this evidence decide every test component a Section 508 conformance process is supposed to contain, and separately, how much of the estate did it look at?
- Competence. Is the tester’s ability attestable in a way this reviewer will treat as meaningful?
- Version. Which WCAG version does this evidence speak to, and is that the version the buyer is legally bound by?
The third one is the part a WCAG 2.0-scoped package cannot answer at all, and nothing on the cover page of the report shows it. Below is each question with the published artifacts that settle it, the exact numbers, and the sentences to put in a solicitation or a supplier reply.
The Baseline and Trusted Tester are not alternatives
These two are not competing methodologies on the same axis. Treating them as a choice is what lets a coverage question get answered with a credential.
The ICT Testing Baseline, maintained by the ICT Testing Baseline Working Group and published on the US Access Board’s site, is a coverage definition. It describes itself as “a comprehensive set of test components that a Section 508 conformance test process should include to ensure full coverage of all requirements.” The Portfolio “establishes the minimum requirements for evaluating the conformance of ICT with the Revised Section 508 of the Rehabilitation Act of 1973, as amended (29 U.S.C. 794d),” and the Baselines “are a benchmark for test processes that determine Section 508 conformance for ICT across federal agencies.”
The same page then says what it is not, in a list headed “What the ICT Testing Baseline Is NOT”: “A step-by-step testing procedure or methodology. A specific testing tool or software for Section 508 conformance testing.”
The Portfolio currently holds two baselines. The Baseline for Web, version 3.1, published 1 April 2024, “was the first baseline in the Portfolio and is recognized as a Best Practice by the Federal CIO Council’s Accessibility Community of Practice (ACOP).” The Baseline for Electronic Documents, version 1.0, published 30 September 2024, covers non-web electronic documents. Software and hardware are not yet covered: the page says only that “Additional Baselines will be developed for all ICT covered by Section 508 including software and hardware.”
The Baseline is readable in full and countable. Fetching the complete web baseline page and extracting every “Baseline Test ID” string gives 62 unique test IDs across 24 numbered requirement groups, from group 1 Keyboard Accessible through group 24 Parsing. The document has two levels. Each of the 24 requirement groups carries Accessibility Requirements, a Test Method Rationale and a Limitations, Assumptions, or Exceptions note. Each of the 62 test IDs beneath them carries Identify Content, Test Instructions and Test Results. The documents baseline runs 57 test IDs across the same 24-group structure, with groups 4 (Repetitive Content), 19 (Frames and iFrames) and 23 (Multiple Ways) marked “Not Applicable to Documents.”
The DHS Trusted Tester Process is a process that implements that definition. Section508.gov states: “The DHS Trusted Tester Process is a manual test approach that aligns with the ICT Testing Baseline, and provides repeatable and reliable conformance test results.”
The process document itself is the cleanest proof of the relationship. The most recent published version is Trusted Tester Section 508 Conformance Test Process for Web, Version 5.1.3, April 2024, from the DHS Customer Experience Directorate. It says:
This test process incorporates all tests in the “Harmonized Processes for Revised 508 Testing: Baseline Tests for Web Accessibility” version 3.0. The baseline tests established the minimum steps required to determine compliance with Revised 508 Standards and WCAG 2.0 Level A and AA. Test instructions that are specific to Trusted Tester only are identified with TT-specific or “[no baseline].” The outcomes of these tests will be reflected only in Revised 508 test results. Baseline test results will be reported separately and are not affected by Trusted Tester-specific tests.
That is a process reporting its own conformance to a coverage definition, and separating its extras so the baseline result stays comparable. DHS says the same on its own page: “Our test process follows the ICT Testing Baseline, which meets the minimum requirements for Revised 508 standards (including WCAG 2.0 Levels A and AA).”
Two version details worth recording rather than glossing. The v5.1.3 process document names Baseline for Web version 3.0, while the Access Board site publishes version 3.1 (1 April 2024) as current. What substantively differs between the two was not verified here, so do not assert a delta. Record the process version you tested under and the baseline version it maps to, and let the reviewer decide whether that matters. Separately, v5.1.3 (April 2024) is the most recent published process document that can be located; Section508.gov, reviewed July 2026, still labels the program “V5” and links to the v5.0 (June 2019) site, which itself tells already-certified testers to “use Trusted Tester 5.1 or above.”
The practical consequence of the two-axis structure is that Trusted Tester is an example, not the only permitted implementation. GSA’s own buyer guidance says so with the operative words “such as”:
Whenever possible, purchasers should conduct independent conformance validation testing and evaluation to verify vendor accessibility conformance claims. For Web-based products, purchasers can refer to the ICT Accessibility Testing Baseline for Web and consider using a “Baseline-aligned” test process, such as the Trusted Tester process.
So the buyer’s coverage question is answerable without a credential argument: hand the supplier the 62 published test IDs and ask which of them its process decides, and how.
View the data as a table
| ICT Testing Baseline | DHS Trusted Tester Process | |
|---|---|---|
| What it is | A coverage definition: the test components a Section 508 process should include | A manual test approach that aligns with the Baseline and returns repeatable results |
| Who publishes it | The ICT Testing Baseline Working Group, on the US Access Board’s site | The DHS Customer Experience Directorate |
| Current published version | Baseline for Web v3.1, published 1 April 2024 | Web test process v5.1.3, April 2024, which names baseline version 3.0 |
| What it explicitly is not | Not a step-by-step testing procedure or methodology, and not a testing tool | Not the only permitted implementation; GSA’s guidance says ‘such as’ |
| Countable content | 62 unique test IDs across 24 numbered requirement groups, web baseline | All baseline v3.0 tests, with TT-specific extras flagged and reported apart |
Question one: coverage, in both of its senses
Coverage of the requirements and coverage of the estate are different questions with different failure modes. Naming a test process only answers the first.
Coverage of the requirements
The Trusted Tester web process contains “63 Test Conditions for evaluation in this test process. Each Test Condition must have a test result for testing to be considered complete.” Those 63 conditions map to a defined requirement set: “The 41 web requirements covered in this test process are 38 WCAG 2.0 Level A and AA Success Criteria and 3 Section 508 requirements.” The mapping is not one to one, and the document says so: “Some web requirement outcomes are determined by more than one Test Condition.”
Those three Section 508 requirements are narrow and specific. Appendix A of the process document maps them to Test IDs 17.D through 17.G: 503.4 User Controls for Captions and Audio Description, 503.4.1 Caption Controls and 503.4.2 Audio Description Controls. That is the whole of the non-WCAG content of a Trusted Tester web package.
Scope boundaries are stated plainly in the same document. “This test process covers web content only. Trusted Tester versions 4.x and older were developed for the original Section 508 standards, which had separate requirements for web and software.” Software elements inside a web application are explicitly handed off: “To test the software elements, use the software test process.” And: “Similarly, any other operating systems, browsers, or platforms such as mobile tablets, must be evaluated using other testing procedures.”
The validated test environment is worth checking against your own product, though it is a narrower boundary than it first looks. Operating systems: “Windows 10 and 11 (desktop mode)” and “macOS (with Safari only).” Browsers: “On Windows 10: Google Chrome, Mozilla Firefox, Microsoft Edge. On macOS: Safari.” The document then relaxes both. On the OS list: “Although Windows 10 and 11 and macOS are the only operating systems listed, no foreseeable issues due to using another operating system have been identified. The operating system has little to no impact on web testing results and is more dependent on the browser.” On the browser list: “Use of newer versions of these browsers is acceptable unless otherwise specified on the DHS Section 508 Compliance Testing Tools website.” So an unlisted desktop browser version is not automatically a defect in the evidence. A mobile app or a tablet interface is a different matter, because that boundary is stated as a hard handoff to another procedure.
View the data as a list
Trusted Tester web process v5.1.3: Validated on Windows 10 and 11, macOS with Safari
- 63 Test Conditions: Each needs a recorded test result
- 41 web requirements: 38 from WCAG 2.0 A and AA, 3 from 508
- 503.4, 503.4.1, 503.4.2: Caption and audio description controls
- Web content only: Software elements go to another process
At the other end of the coverage scale sits the automated scan. GSA’s testing overview defines three methods: “Automated - High volume 508 conformance testing tools automatically scan and test electronic content; Manual - Manual testing uses a documented, consistent, repeatable process; Hybrid - A combination of automated and manual testing.” It then states the structural limit of the first one. Automated scanning tools “cannot apply human subjectivity, and therefore either produce excessive false positives or,” when configured to eliminate those false positives, “test for only a small portion of the requirements.” W3C puts it more bluntly and is a neutral authority for it: “Tools cannot check all accessibility aspects automatically. Human judgement is required. Sometimes evaluation tools can produce false or misleading results. Web accessibility evaluation tools can not determine accessibility, they can only assist in doing so.”
No primary source publishes a percentage for what automation can decide. Neither GSA nor W3C gives a figure. So do not write a percentage into an acceptance criterion. Write the criterion against the 62 Baseline test IDs, which are countable and published.
What GSA does tell buyers to demand from a tool vendor is the mapping itself: “Determine the best strategic mix of false-positive generation vs. coverage of your agency requirements by ensuring the tool vendor defines and quantifies the method and accuracy of its rule sets in regard to its alignment with your agency’s standards and expectations.” A scan is not evidence-free by nature. It is evidence-free when nobody has made the vendor state which rules map to which success criteria and how accurate they are.
Coverage of the estate
Section508.gov treats sampling as its own decision with its own arithmetic. “Comprehensive testing provides the most precise results by testing all applicable Section 508 standards for every ICT item.” Representative sample testing “offers a more resource-efficient alternative,” but the guidance lists the cost in three bullets: “Findings are estimates, not guarantees”; “Risk of missing critical Section 508 defects”; “Confidence depends on representative sample size and selection method.”
It also publishes four tiers you can paste straight into an acceptance criterion. The table below reproduces its Table 3, with the numeric ranges written out.
| Approach | Sample size | Expected confidence |
|---|---|---|
| Baseline Approach (Low Confidence) | Five to ten items such as pages, screens, or documents | High margin of error and low confidence. Testing may miss critical defects |
| Balanced Approach (Moderate Confidence) | 30 to 50 items such as pages, screens, or documents | About 90 to 95 percent confidence, margin of error plus or minus 10 to 15 percent, depending on population size |
| Robust Approach (High Confidence) | 100+ items | 95 percent confidence, margin of error plus or minus 5 to 10 percent, depending on total population |
| Comprehensive Approach (Very High Confidence) | All pages, screens, or documents | 100 percent confidence level and zero margin of error |
The same guidance tells agencies to write the choice down rather than leave it implied: “Clearly record how you selected the sample and what confidence level and margin of error apply.”
A supplier that says “we ran the Trusted Tester process” has answered the first question and not the second. Nine pages tested under a perfect process is nine pages.
Question two: competence, and what the acceptance rule actually says
A Trusted Tester is defined by an exam, and the certification has a scope: “A Trusted Tester is a person who has passed the Trusted Tester Certification Exam and is therefore certified to provide accurate and repeatable Revised 508 conformance test results for web content.”
The exam has a published pass mark. DHS’s training catalog states it twice, for the practice exam and the real one: “You must score 85% or more on the Trusted Tester Certification Exam to be certified.” The program is web-based and self-paced, with enrolment “Limited to 180 days (6 months) to complete the program.”
The sentence usually cited on acceptance is the one below. It is conditional, and the condition runs the opposite way to the way it is normally used.
The only published acceptance statement, quoted in full: “Agencies that adopt the Trusted Tester Process only accept test results from individuals who have been certified as Trusted Testers.” Source: section508.gov/test/trusted-tester
Read it carefully. It restricts, it does not entitle. It tells you what an adopting agency refuses. It says nothing about what any agency must accept, and it does not make certification a governmentwide admission ticket. It also cuts the other way for suppliers who assume equivalent coverage will do: for an adopting agency this is a personnel rule, not a coverage rule, and a beautifully documented non-certified audit does not satisfy a rule written about who held the keyboard.
There is a published precedent for how hard that bites. DHS announced that from 30 September 2019, “Trusted Tester V3 or V4 test results no longer accepted in DHS HQ and DHS component governance processes.” That is historic, not a live deadline, but it is the shape of the risk: an adopting agency can and has refused evidence on process-version grounds alone. Currently, “DHS no longer provides training and certification on Trusted Tester v4.0,” and DHS’s published training catalog lists one Trusted Tester track, the “Trusted Tester for Web Certification Program.” A buyer who needs attestable competence for software, electronic documents or hardware will not find a DHS Trusted Tester credential covering it in the current catalog.
Look up the chain for a general acceptance rule and there is nothing there. FAR subpart 39.2 states the obligation and says nothing about how it is evidenced: “Unless an exception at 39.204 or an exemption at 39.205 applies, acquisitions for ICT supplies and services shall meet the applicable ICT accessibility standards at 36 CFR 1194.1.” Searching the text of 39.201 through 39.205 returns zero occurrences of “Trusted,” “test,” “VPAT,” “conformance report,” “WCAG,” “clause” and “accept.” The word “conformance” appears three times, all inside the undue-burden and fundamental-alteration exemptions.
The closest the subpart comes to evidence is a pointer requirement, and only for one contract type: “The contract must identify which supplies and services the contractor indicates as compliant and show where full details of compliance can be found (e.g., vendor’s or other exact website location).” That obliges a location, not a method. The FAR also carries the obligation forward past award: “At the time of issuance of a task order or delivery order under an indefinite-quantity contract, the requiring and ordering activities shall ensure compliance with the ICT accessibility standards and document an exception or exemption if applicable.”
GSA’s own answer to “who decides” is to ask. Its Essential Elements guidance carries a tip: “Check with the agency’s Section 508 program to find out which testing methodology it follows for Section 508 compliance.” The same guidance treats credentials as optional and gives Trusted Tester as the example rather than the requirement: “Tester credentials, if any, to denote subject matter expertise in the area of testing, such as Trusted Tester ID.” One caveat for buyers who plan to lean on that field: no published route was found for independently verifying a Trusted Tester ID on dhs.gov, section508.gov or the training site. Section508.gov gives the DHS Accessibility Helpdesk (accessibility@hq.dhs.gov) as the contact for Trusted Tester questions.
View the data as a table
| FAR subpart 39.2 | Section508.gov Trusted Tester | GSA Essential Elements | |
|---|---|---|---|
| What it says about test evidence | Nothing: seven evidence terms return zero hits across 39.201 to 39.205 | One conditional sentence about what an adopting agency will accept | Tester credentials, if any, listed as an optional field on the report |
| What it obliges | Acquisitions for ICT supplies and services shall meet 36 CFR 1194.1 | An adopting agency accepts results only from certified Trusted Testers | Check with the agency’s Section 508 program which methodology it follows |
| What it does not do | Name any test process, credential, or method of evidencing conformance | Make certification a governmentwide admission ticket | Require a credential; Trusted Tester is the example, not the requirement |
What competence looks like without the certificate is also published. GSA defines manual testing by its documentation, not its credential: “Manual testing uses a documented, consistent, repeatable process.” And the Trusted Tester process supplies the standard a non-certified methodology can be held to, in its own rule for substituting tools:
If these tools cannot be used, e.g., due to technical or security limitations, other tools may be substituted if it can be demonstrated that they provide equivalent results. Use of alternate tools must be supported by clearly documented test processes and test results showing how the alternate tool is equivalent for each test in which it is used in this test process.
That is a usable bar. If a supplier is not sending a certified Trusted Tester, ask for the equivalent of that demonstration: a written process, mapped test by test to the 62 Baseline Test IDs, with recorded results showing the mapping holds. Appendix A of the Trusted Tester document, which cross-references each of the 63 Test Conditions to a requirement and to a baseline test in both directions, is the public template for what that document should look like.
For reference, the tools the process itself names are ANDI, “a free open-source bookmarklet” developed by the US Social Security Administration, and the Colour Contrast Analyzer, with “Microsoft’s Accessibility Insights (MSAI) … validated as a substitute for CCA for the color contrast test.”
The two-axis matrix
Coverage on one axis, attestable competence on the other. Evidence types plotted against both. There is deliberately no “will a reviewer accept this” column, because no published authority supports one, and inventing a prediction would be the single most damaging thing this table could do.
| Competence: none recorded | Competence: documented, reproducible in-house methodology | Competence: DHS Trusted Tester certification | |
|---|---|---|---|
| Coverage: partial, by construction | Commercial automated scan. GSA: tuned to avoid false positives it tests “only a small portion of the requirements.” | Scan plus undocumented spot checks. Method exists on paper, coverage still unmapped to the 62 test IDs. | Not a meaningful cell. Certification is for the full process, not a scan. |
| Coverage: unstated | Findings with no method, no scope and no environment. Nothing here can be scored against the Baseline or against GSA’s Essential Elements checklist. | Written procedure that never maps to the Baseline. Ask for the mapping. | Certified tester, but the report omits process, scope or environment. The process document requires all three. |
| Coverage: full against the 62 Baseline Test IDs | Coverage claimed, nobody named, so nothing to verify. | Third-party or in-house expert audit, mapped test by test, with the equivalence demonstration the TT process requires for substitutions. | DHS Trusted Tester package: 63 Test Conditions, every one with a recorded result, plus TT-specific steps flagged so baseline results report separately. |
Read across, then read the next table down. Full coverage of the requirements still leaves the estate question open, and full coverage of both still leaves the version question open.
| Evidence type | What it can be held to | What it does not contain |
|---|---|---|
| Commercial automated scan | Whatever rule-set-to-success-criterion mapping and accuracy figures the tool vendor publishes. GSA tells buyers to make the vendor “define and quantify” both. | Any criterion needing human judgement; W3C: tools “can not determine accessibility.” |
| In-house manual audit | Its own written procedure, plus the Baseline if it maps to it. | Third-party independence. An external attestation of tester competence. |
| Third-party expert audit against the Baseline | The 62 published test IDs, item by item. Whatever sample size the contract specified. | A DHS credential, if the agency is one that has adopted the Trusted Tester Process. |
| DHS Trusted Tester package for web | 63 Test Conditions, 41 web requirements, web content on validated desktop environments. | Software, electronic documents, hardware, platforms outside the validated set including mobile tablets, and any success criterion added in WCAG 2.1. |
Question three: which version does the evidence speak to
This is the arithmetic that decides whether a technically flawless package is still short.
What each rule requires
| Rule | WCAG version and levels | Who is bound | Compliance date |
|---|---|---|---|
| Revised Section 508, 36 CFR part 1194 Appendix A, E205.4 | WCAG 2.0 Level A and AA, pinned to the 11 December 2008 Recommendation by 702.10.1 | Federal agencies and, through acquisition, their vendors | In force |
| ADA Title II, 28 CFR part 35 subpart H | WCAG 2.1 Level A and AA | Public entities, for web content and mobile apps a public entity “provides or makes available, directly or through contractual, licensing, or other arrangements” | 26 April 2027 for entities with a total population of 50,000 or more; 26 April 2028 for smaller entities and special district governments |
| Section 504, HHS recipients, 45 CFR part 84 subpart I | WCAG 2.1 Level A and AA | Recipients of HHS financial assistance | 11 May 2027 for recipients with fifteen or more employees; 10 May 2028 for smaller recipients |
Both sets of 2027 dates are the extended ones. DOJ moved Title II by a year in an interim final rule published and effective 20 April 2026: “The compliance date for State and local government entities with a total population of 50,000 or more is extended from April 24, 2026, to April 26, 2027.” HHS did the same in an interim final rule published 11 May 2026: “The compliance date for recipients with fifteen (15) or more employees is extended from May 11, 2026, to May 11, 2027.” Any evidence plan still keyed to 2026 is working from a superseded date, and any plan that treats April or May 2027 as universal has the same problem in the other direction, because the smaller-entity and smaller-recipient dates fall a year later again.
Note also that the references are pinned, not floating. Section 508 incorporates “WCAG 2.0, Web Content Accessibility Guidelines, W3C Recommendation, December 11, 2008.” Title II incorporates a specific dated snapshot of 2.1, the 5 June 2018 Recommendation at https://www.w3.org/TR/2018/REC-WCAG21-20180605/. Incorporation by reference freezes the document; only a rulemaking moves it. Which rule pins which version, across Section 508, Title II, Section 504 and the EU, is worked through in which WCAG version each rule actually requires.
Federal agencies are not Title II entities, so a purely federal supplier lives entirely in the WCAG 2.0 column. The problem lands on the supplier selling the same product to a federal agency and to a state university, a school district or an HHS-funded health system.
The twelve rows
WCAG 2.1 “provides 17 additional success criteria to address: mobile accessibility, people with low vision, people with cognitive and learning disabilities.” Twelve of the 17 are at Level A or AA, and those twelve are the entire gap.
| Level | Success criteria added by WCAG 2.1 | Present in the WCAG 2.0 A/AA row set | Present in Baseline for Web v3.1 | Present in VPAT 2.5Rev 508 edition |
|---|---|---|---|---|
| A | 2.1.4, 2.5.1, 2.5.2, 2.5.3, 2.5.4 | No | No | No |
| AA | 1.3.4, 1.3.5, 1.4.10, 1.4.11, 1.4.12, 1.4.13, 4.1.3 | No | No | No |
Backwards compatibility runs one way only, and the 2018 Recommendation says which way: “Content that conforms to WCAG 2.1 also conforms to WCAG 2.0. The WG intends that for policies requiring conformance to WCAG 2.0, WCAG 2.1 can provide an alternate means of conformance. The publication of WCAG 2.1 does not deprecate or supersede WCAG 2.0.” There is no converse statement, and there cannot be, because 2.1 adds criteria and removes none. That is also why a Trusted Tester web package is not a package that avoids WCAG 2.1. It evidences 38 of the 50 A and AA criteria that WCAG 2.1 contains, and is silent on the other twelve.
The Baseline Portfolio addresses the obvious objection head on. The Baseline tests do cite WCAG 2.2 Understanding articles, and that citation changes nothing: “While Section 508 requires WCAG 2.0 Level A and AA, Baseline tests with applicable WCAG success criteria (SC) reference the latest version (2.2) of WCAG Understanding SC articles … However, the Baselines are mapped only to Section 508 (and WCAG 2.0) requirements.” Counting confirms it independently. Extracting every success-criterion reference from the full published web baseline returns all 38 WCAG 2.0 A/AA criteria and not one of the twelve listed above.
View the data as a list
- Section 508 pins WCAG 2.0: E205.4, 36 CFR 1194
- Baseline maps only to 2.0: Even where it cites 2.2
- 38 of 50 A and AA criteria: WCAG 2.1 contains 50
- Twelve rows unevidenced: For a Title II or 504 buyer
Where the mismatch gets baked in: the template edition
The version of the VPAT template is not what decides the row set. The edition is. ITI publishes VPAT 2.5Rev, dated 24 April 2025, in four editions, and states the mapping outright: “WCAG 2.0 is incorporated into the 508 edition. WCAG 2.1 is incorporated into the EU edition. WCAG 2.2 is incorporated into the WCAG and INT editions.” A brand new, correctly completed VPAT 2.5Rev 508 edition ACR is a WCAG 2.0 document.
This is countable from GSA’s own machine-readable catalogs, which is the version of this argument that survives a hostile reviewer. Download 2.5-edition-wcag-2.0-508-en.yaml, 2.5-edition-wcag-2.1-508-en.yaml and 2.5-edition-wcag-2.2-508-en.yaml from the GSA OpenACR catalog and count criteria per chapter:
| Catalog | Level A rows | Level AA rows | Total A/AA |
|---|---|---|---|
| VPAT 2.5 Revised Section 508 Edition (WCAG 2.0) | 25 | 13 | 38 |
| VPAT 2.5 WCAG 2.1 and Revised Section 508 Edition | 30 | 20 | 50 |
| VPAT 2.5 WCAG 2.2 and Revised Section 508 Edition | 32 | 24 | 56 |
The set difference between the first two is exactly 1.3.4, 1.3.5, 1.4.10, 1.4.11, 1.4.12, 1.4.13, 2.1.4, 2.5.1, 2.5.2, 2.5.3, 2.5.4 and 4.1.3, and nothing is dropped. The 2.2 catalog adds a further six on top of 2.1: 2.4.11, 2.5.7, 2.5.8, 3.2.6, 3.3.7 and 3.3.8. The non-WCAG chapters are identical across all three editions: 9 functional performance criteria, 55 hardware, 26 software and 5 support documentation and services rows. Changing WCAG version changes only the WCAG chapter. A reader can verify the whole table with three downloads.
The version-mismatch panel
| Evidence or artifact | The WCAG version it speaks to | A/AA rows it can populate | Rows left unevidenced for a Title II or Section 504 buyer |
|---|---|---|---|
| ICT Testing Baseline for Web v3.1 | WCAG 2.0 A and AA, mapped only to Section 508 and 2.0 | 38 | 12 |
| DHS Trusted Tester web package (v5.1.3) | WCAG 2.0 A and AA, plus 503.4, 503.4.1, 503.4.2 | 38 | 12 |
| ACR on VPAT 2.5Rev 508 edition | WCAG 2.0 | 38 rows exist in the template | The 12 rows are not in the document at all |
| ACR on VPAT 2.5 WCAG 2.1 and Revised 508 edition | WCAG 2.1 | 50 rows exist in the template | 0, if evidence exists behind all 50 |
| ACR on VPAT 2.5 WCAG 2.2 and Revised 508 edition | WCAG 2.2 | 56 rows exist in the template | 0, plus 6 rows beyond any current US requirement |
Two distinct failure modes fall out of that table. The 508-edition ACR does not contain the twelve rows, so the mismatch is visible on the cover page. The 2.1-edition ACR contains all fifty rows, so the mismatch is invisible, and the only way to find it is to ask which method produced which row.
GSA also gives buyers the vocabulary to challenge what fills those rows. “A vendor may state that their product ‘partially supports’ Section 508 … In other words, the product does not conform to Section 508 standards.” And on the other common filler: “A note of ‘not evaluated’ in an ACR indicates that the vendor has not conducted an assessment or evaluation … ‘not evaluated’ does not provide any assurance of accessibility and should prompt further inquiries and considerations.” A WCAG 2.0-scoped process leaves the twelve extra rows in one of those two states unless something else was run.
A worked example you can open right now
The clearest illustration is published by the federal government, about federal government software, so no supplier is being made an example of. GSA’s ACR Library lists nine products. Six carry a report date and a downloadable ACR in both HTML and OpenACR YAML; three are marked pending.
Take the ACR for the ACR Editor v1.0, report date 4/18/25, written on catalog 2.4-edition-wcag-2.1-508-en. Its Evaluation Methods Used field reads, in full: “ACR Editor is tested using Trusted Tester and User testing with assistive technology against Section 508 standards.”
Because the catalog is a WCAG 2.1 catalog, the report carries the twelve rows the Trusted Tester process does not cover. On the web component, six are answered “supports” (1.3.4, 1.3.5, 1.4.10, 1.4.12, 1.4.13, 2.5.3) and six “not applicable” (1.4.11, 2.1.4, 2.5.1, 2.5.2, 2.5.4, 4.1.3). Every one of the twelve has an empty notes field, on all four components the catalog carries.
The fair reading matters here. The report also cites user testing with assistive technology, so those rows may well have come from that, and the answers may be entirely correct. The point is narrower and it is the whole point of this article: the document does not say which method produced which row. That is precisely the question an acceptance reviewer asks, the file is machine-readable YAML, and a reader can reproduce the check in about a minute.
A contrast case from the same library shows the other half of the problem. Five of the six published ACRs are for GSA online training courses, four dated 4/24/2025 and one dated 4/18/2025, and all five fill Evaluation Methods Used with the identical string: “The course was testing using manual and automated tools including assistive technology used by people with disabilities. Tools included Axe, ANDI, JAWS, NVDA, VoiceOver, ZoomText and Dragon Naturally Speaking.” Real tools, real assistive technology, competent good-faith work. No test process identified, no scope statement, no page count, no test environment, and no tester credential recorded. Measured against the three things the Trusted Tester process says every ACR must carry, they answer none of them.
View the data as a table
| ACR Editor v1.0 report | Five GSA course reports | |
|---|---|---|
| Evaluation Methods Used says | Tested using Trusted Tester and user testing with assistive technology | Manual and automated tools: Axe, ANDI, JAWS, NVDA, VoiceOver, ZoomText, Dragon |
| Test process identified | Yes, Trusted Tester is named, on a WCAG 2.1 catalog | No test process identified, a tool list only |
| What the reviewer still cannot tell | Which method answered each of the twelve 2.1 rows; every notes field empty | No scope statement, no page count, no test environment, no credential |
What the evidence package has to state
The Trusted Tester process document dictates the minimum itself, and it applies just as well to a non-TT package:
Trusted Tester results must be provided at minimum following the Accessibility Conformance Report format from the IT Industry consortium. However, the ACR format must be supplemented with specific Trusted Tester test outcomes, which must then be aggregated to determine the “supported” and “not supported” outcomes for individual WCAG Success Criteria results. Each ACR must provide: Clear identification of the test process used to return conformance results. Clear indication of the scope of testing. Clear documentation of the test environment(s).
Note the vocabulary shift buried in that paragraph. The test outcomes are “PASS, FAIL, DOES NOT APPLY, or NOT TESTED.” The ACR speaks in supports, partially supports and does not support, with not applicable and not evaluated available too. Those are two different vocabularies, and something has to do the aggregation. If a report hands you raw test outcomes and calls itself an ACR, or hands you ACR verdicts with no underlying outcomes, one half of the artifact is missing. DHS builds the join itself: it “has developed the Accessibility Conformance Reporting Tool (ACRT) to collect tester results and generate a test report that includes results for each Test Condition, supporting screenshots and the results for all web requirements.” A package with no equivalent join is asking the reviewer to take the aggregation on trust.
The process document also says what to do when a test cannot be run, which is worth quoting to a supplier who has left blanks: “If a tester cannot complete a test, a note should be added to the test report indicating ‘This test could not be performed’, with a detailed explanation of the issue.” A blank is not an outcome.
Every VPAT edition also contains “an Evaluation Methods Used field to describe methods used to test the product’s accessibility” plus a Notes field for the report and for each table. Leaving those vague is a choice by the author, not a limitation of the template.
GSA’s Essential Elements guidance adds the rest of the checklist, and it is the thing to score a package against:
| Element the report must carry | Why the reviewer wants it |
|---|---|
| Product name and specific version | Ties the evidence to the build being bought |
| Tester names, organization, contact details | Someone answerable for the result |
| Tester credentials, if any, “such as Trusted Tester ID” | Optional trust signal, not an admission requirement |
| Report date, evaluation date, report version | Distinguishes a fresh test from a reissued document |
| Evaluation methods: tools, methodologies, operating system, browser and version | ”Be as specific as possible so others can use the methodologies and tools to replicate any defects noted” |
| Scope: what was tested, how many pages, what was omitted | The estate-coverage question, in writing |
| An outcome for every standard, including the ones that do not apply | No silent gaps |
Two further distinctions the same guidance draws. First, an ACR and a test report are different artifacts: “An Accessibility Conformance Report (ACR) provides an overview of a product’s conformance to Section 508. In contrast, a Section 508 test report offers a more detailed, developer-oriented document to assist product teams in enhancing Section 508 conformance.” If what you need is the detail behind a verdict, an ACR is the wrong document to ask for, and asking for “the ACR” will get you the overview.
Second, none of the above is about assistive technology. Across all 99 pages of the v5.1.3 process document the strings JAWS, NVDA and VoiceOver do not appear once. DHS itself calls the process “determining compliance with Section 508 standards through code inspection,” and describes it as providing “more accurate and consistent results than assistive technology tools or automated tools,” which is DHS’s own characterization of its own process rather than an independent finding. Either way, a buyer who needs assistive-technology pairing evidence has to ask for it as a separate deliverable, naming the specific assistive-technology pairings the evidence must cover.
The buyer’s side: make it a written deliverable before award
Section508.gov already publishes the ask, so a buyer does not have to draft it. For each Standard ICT item, which the guidance defines as “Commercial or government off-the-shelf (COTS/GOTS),” it requires the offeror to provide an ACR, and alongside it:
Supplemental Accessibility Report (SAR) - A written SAR containing: Description of evaluation methods used to produce the ACR, to demonstrate due diligence in supporting conformance claims.
The same guidance makes ACR completeness an award-eligibility matter, not a courtesy: “To be considered for award, the ACR must be complete, and submitted according to the instructions.” Its recommended list, one step below required, tells agencies to reserve a retest right: “State that the agency reserves the right, prior to making an award decision, to perform testing on some or all of the offeror’s proposed ICT items to ensure the accuracy of their response.” And for anything being built rather than bought off the shelf, the method is required in advance: for each Customized ICT item, an ACR “describing how the item(s) will fully address the accessibility requirements outlined in the solicitation; and a description of the evaluation methods the offeror will use to validate for conformance to the Revised 508 Standards.”
Four sentences to add to the solicitation or the supplier questionnaire, each of which is answerable from published material and none of which requires a credential argument:
- Name the test process used, and state which version of the ICT Testing Baseline it maps to, test component by test component.
- State the sample: how many pages, screens or documents, selected how, and what was excluded. Name the confidence tier you are claiming from Section508.gov’s Table 3.
- Name the catalog the ACR is written on, by filename, from GSA’s OpenACR catalog list, or, for a Word VPAT, the exact edition and template version. This settles the WCAG version before any testing is paid for.
- For every A/AA row outside the WCAG 2.0 set, state in the notes which method produced the answer.
That last one costs a supplier nothing if the work was actually done, and it is the only question that separates the two failure modes described above. Where those requirements need to survive past award, they belong in contract clauses and a QASP rather than in an evaluation memo. Scoring the returned document is a separate exercise, walked through row by row in how to score a vendor ACR.
What nobody can tell you
There is no published prediction available for whether a given reviewer will accept a given evidence package, and this article will not manufacture one. FAR subpart 39.2 contains no acceptance rule. GSA’s answer is to ask the agency’s own Section 508 program. The single published acceptance statement is the conditional Trusted Tester sentence, and it constrains one class of agency rather than forecasting outcomes. No published source was found stating how many agencies have formally adopted the Trusted Tester Process, and no agency other than DHS can be named as an adopter on published evidence.
What is knowable in advance is the whole of what this article covers: whether the method covers the 62 published test components, how much of the estate it looked at, whether the tester’s competence is attestable and how, and which WCAG version the resulting document speaks to. Those four facts are enough to price the gap instead of guessing at it, and enough to have the argument before the evidence is paid for rather than after it comes back.
Your next step
Open the ACR you are holding and find the Evaluation Methods Used field. If it names a tool list and no process, or names Trusted Tester on a WCAG 2.1 catalog with empty notes on 1.3.4, 1.3.5, 1.4.10, 1.4.11, 1.4.12, 1.4.13, 2.1.4, 2.5.1, 2.5.2, 2.5.3, 2.5.4 and 4.1.3, you have found the twelve rows before your reviewer does. Send the supplier item 4 above, in writing, and give them a date.
If the answer comes back thin and the deadline is April or May 2027, ADACP’s Section 508 testing defines the pages, templates and user flows in scope before testing starts and ties each finding to the criterion it fails, and its VPAT testing confirms the required VPAT edition at intake, which is what fixes the WCAG version, before the ACR is written on it.