VPATs and ACRs: What Procurement Officers Read, and What Bashin Means for Yours

The Document Your Client's Procurement Officer Reads

When your municipal client's procurement officer opens your ACR, they don't read it. They check it against a list.

In Massachusetts, that list is published. The EOTSS Accessibility Conformance Report Review Checklist is eight binary yes/no items long, and every "No" is a concern. Is the report dated within the last twelve months? Yes or no. Does it identify the specific product version proposed? Yes or no. Was it completed by someone with documented accessibility expertise? Yes or no. Did it include both manual and automated testing, with assistive technologies named? Yes or no. Are the Remarks columns populated with specifics — locations, criteria, target dates? Yes or no.

Eight checks. Most submitted VPATs fail at least three.

In Virginia, the checklist is shorter and harder. Va. Code § 2.2-3501, as amended by HB 2541 (2025), requires that the ACR be completed by a digital accessibility subject matter expert with significant product-evaluation experience, or by a qualified neutral third party. Self-attestation by an in-house developer who watched a screen-reader tutorial on YouTube is not, on its face, what the statute asks for. Colorado, Minnesota, Washington, and California each have their own variant. The federal government has GSA's Solicitation Review Tool and a developing governmentwide ACR Repository.

The VPAT is no longer a marketing document. It is a regulated procurement deliverable, evaluated against published criteria, and — after Bashin v. Conduent — a litigation artifact. This post is the contractor's working guide to filling it out properly.

Last week we walked through the contract clauses that obligate the ACR. This week we open the document itself.

Vocabulary: VPAT vs. ACR

The two terms get used interchangeably and shouldn't be. A VPAT — Voluntary Product Accessibility Template — is the blank ITI template. An ACR — Accessibility Conformance Report — is the completed document filed against a specific product. When an RFP asks for "a VPAT," it almost always wants a completed one. Read the solicitation literally; if it says "current ACR," it means a completed report dated within whatever window the buyer requires. Massachusetts is twelve months. Most other states default to the same.

This matters because some procurement officers reject submissions on the vocabulary mismatch alone. "Vendor submitted a VPAT, not an ACR" is a real disqualification reason in some procurement workflows.

VPAT 2.5 and the Four Editions

The current stable version is VPAT 2.5, published by the Information Technology Industry Council in November 2023 and updated March 2025. The 2025 update aligned the template with WCAG 2.2, added a dedicated explanation column to each conformance row, and noted that WCAG success criterion 4.1.1 Parsing is now obsolete in 2.2 (it auto-passes). There is no VPAT 2.6 as of mid-2026, and ITI has signaled the next trigger would be WCAG 3.0 or a major Section 508 revision — neither imminent. Plan on 2.5 being the standard through at least 2027.

ITI publishes four editions of the template. Each is a separate file:

• 508 Edition — Revised Section 508 standards. Use for U.S. federal procurement and federally funded entities.
• WCAG Edition — WCAG 2.0, 2.1, and 2.2 tables. This is your default for state and local municipal web work.
• EU Edition — EN 301 549, for the European market.
• INT Edition — all three combined, for vendors hedging across multiple buyer types.

The practical move for a solo contractor: download the WCAG Edition from itic.org/policy/accessibility/vpat. Inside, you'll find three separate tables — WCAG 2.0, 2.1, and 2.2. ITI's own rule is to keep the table for the version your buyer requires and remove the others. Do not fill in all three. It creates ambiguity about which standard you're actually attesting to, and procurement reviewers read multi-standard ACRs as either confused or evasive.

The conformance target matters. WCAG 2.1 AA is the floor for ADA Title II and for most state laws (Colorado, Minnesota, current Massachusetts EOTSS minimum). Washington moves to WCAG 2.2 AA on July 1, 2026. California already references 2.2 in current AB 434 certifications. Read your RFP and match it. If the buyer doesn't specify, default to 2.1 AA and note it explicitly in the Applicable Standards section.

A pre-2.5 ACR — especially 2.4 or earlier — is increasingly rejected. VPAT 1.x (2001–2017) referenced the original 1998 Section 508 standards and should never appear in a 2026 procurement file. If a third-party component vendor sends you an ACR built on an old template, treat that as a refresh trigger before you incorporate the document into your own submission.

The Four Conformance Ratings

Every WCAG criterion in the report gets one of four ratings. The official ITI definitions, paraphrased:

• Supports — at least one method meets the criterion without known defects.
• Partially Supports — some functionality does not meet the criterion.
• Does Not Support — the majority of functionality does not meet the criterion.
• Not Applicable — the criterion is not relevant to the product.

There is a fifth rating, Not Evaluated, but it may only be used for WCAG Level AAA criteria. You may never mark a Level A or Level AA criterion "Not Evaluated." That is a hard rule, and procurement reviewers spot the violation immediately.

The retired rating. Earlier VPATs included "Supports with Exceptions." It was retired in VPAT 2.4 (2020) at the request of the U.S. Access Board, and replaced by "Partially Supports." Why does this history matter? Because old template files and lazy authors still use the retired term, and procurement reviewers read "Supports with Exceptions" as evasive — "exceptions" implies edge cases, while "Partially Supports" is honest about the fact that some things work and some don't. If you see "Supports with Exceptions" on an inherited ACR, the document is outdated and the evaluator was sloppy.

Common rating errors:

• Marking everything "Supports" without manual testing. The cardinal sin.
• Using "Not Applicable" for criteria that actually apply. If your site has video and you mark 1.2.2 Captions as "Not Applicable," that's a misrepresentation.
• Marking Level A or AA criteria "Not Evaluated." Only AAA may be.
• Marking criteria "Supports" because an automated tool returned no errors. Automated tools fully test only about thirty percent of WCAG 2.1 A/AA criteria — the rest require manual review.

The single highest-leverage habit in honest VPAT authoring: when in doubt between "Supports" and "Partially Supports," choose "Partially Supports" and explain the doubt in Remarks. Procurement reviewers — and post-Bashin, plaintiff attorneys — score a vendor who identifies flaws above a vendor who claims perfection without evidence.

Writing Remarks That Hold Up

Whenever a criterion is "Partially Supports" or "Does Not Support," the Remarks column is mandatory. Procurement reviewers read these line by line. A strong Remarks entry names four things:

1. The gap — the specific function or feature where the issue appears. "The date picker on the permit-application form…"
2. The criterion connection — the actual WCAG success criterion involved. "…fails 4.1.2 Name, Role, Value because the calendar day-buttons lack accessible names."
3. The user impact — who is affected and how. "…screen-reader users cannot determine which date is currently focused."
4. The remediation plan — when it will be fixed. "Scheduled for the Q3 2026 release; tracked in issue PMT-481."

Compare that to what most procurement officers actually receive: "Tested and works." Or worse: "Our product is committed to accessibility." Both are unactionable, both raise red flags, and both — if the rating is "Supports" — invite the reviewer to scrutinize every other "Supports" claim in the document.

The Remarks column is where your credibility lives. Treat it as the procurement officer's reading lane.

The Anatomy of the Template

A VPAT/ACR has two parts: a Product Information block at the top, and the success-criteria tables below.

The Product Information block is where the procurement officer makes most of their pass/fail decisions before they read a single conformance rating. It must include:

• Report title in the exact format "[Company Name] Accessibility Conformance Report."
• A note indicating the template version (e.g., "Based on VPAT® Version 2.5").
• Product name and version. Be specific — which build did you test?
• Report date (month and year minimum).
• Product description.
• Contact information — ideally the person who actually did the evaluation, with a real email address and phone number.
• Evaluation Methods Used — the most important field in the entire document for litigation defense (see the Bashin section below).
• Applicable Standards/Guidelines table (which WCAG levels are covered, yes/no for each).
• Terms (the conformance-level definitions).

The success-criteria tables follow the four POUR principles — Perceivable, Operable, Understandable, Robust — and split into Level A, Level AA, and Level AAA tables. For state and local work you report A and AA. AAA is optional and usually excluded from the document entirely; if you include AAA, that's the only place "Not Evaluated" is permitted.

For pure WCAG municipal web work — the typical scope of a state/local site or portal — you only have the WCAG tables. The 508 chapters (Chapter 3 Functional Performance Criteria, Chapter 4 Hardware, Chapter 5 Software, Chapter 6 Support Documentation, Chapter 7 Connectivity) appear in the 508 Edition and the INT Edition. If you used those editions and a chapter doesn't apply (no hardware, no installed software), ITI allows you to remove or summarize the section — provided you explain in a summary note why it doesn't apply. Silently deleting sections without explanation is a procurement-officer red flag.

Where Third-Party Evaluation Is Required

This is the operational fork in the road. Some states allow self-attestation if the methodology is documented and the evaluator is named. Others require external authorship. Read the solicitation, but here's the map as of mid-2026 — and for the broader state-law backdrop, the May 18 state-laws guide is the companion.

Virginia — SME or qualified third party REQUIRED. Va. Code § 2.2-3501 (as amended by HB 2541, 2025 c. 571) requires the ACR be completed by a digital accessibility subject matter expert with significant product-evaluation experience, or by a qualified neutral third party. VITA's Mandatory Core Contractual Terms, effective April 24, 2026, incorporate this for all RFPs and contracts negotiated or renegotiated on or after that date. Virginia has not published a formal certification list defining "qualified neutral third party"; the operative test is the evaluator's documented expertise and independence. When in doubt, confirm acceptance with the procuring agency before you commit.

Massachusetts — manual + automated required, self-attestation accepted. EOTSS does not strictly require third-party authorship. A self-attested ACR is acceptable if it was completed by knowledgeable personnel and includes both manual and automated testing with assistive technologies named. The ACR must be no more than twelve months old. The EOTSS review checklist (see next section) is the operative standard.

Colorado — self-attestation accepted, third-party testing reservable by the state. Colorado OIT requires WCAG 2.1 AA and asks bidders to demonstrate conformance. The state's standard contract reserves the right to have compliance determined by a third party of the state's choosing — meaning Colorado can commission an audit at any time and tag you with the bill under the HB 25-1152 indemnification machinery we covered last week.

Minnesota. MNIT requests an ACR using the ITI VPAT for COTS products and allows self-assessment or third-party authorship. MNIT's own guidance is direct: a vendor who identifies specific accessibility issues and plans to fix them is more credible than one claiming full compliance without evidence.

Washington. WaTech's Digital Accessibility Standard USER-01-01-S requires WCAG 2.1 AA now and WCAG 2.2 AA by July 1, 2026. Procurement and contracting activities must include accessibility. The federal DOJ's April 2026 extension does not move Washington's state deadline.

California. Government Code §§ 7405 / 11135 / 11546.7 plus AB 434 biennial certification. Current state references are WCAG 2.2 AA. California is also where Bashin happened — see below.

Federal context. GSA's Solicitation Review Tool and the developing governmentwide ACR Repository signal where state and local practice is heading. Federal solicitation language reserves the government's right to test the product and require remediation if conformance claims overstate what's actually provided. State and local procurement officers increasingly borrow the federal posture.

Budget for the third-party path. Realistic small-firm pricing for a single municipal site as of mid-2026: roughly $1,250 to $2,750 for a WCAG 2.1/2.2 AA audit, plus $350 to $950 for VPAT/ACR authoring on top, at the budget end. Enterprise firms (Deque, Level Access, TPGi, Allyant, Bureau of Internet Accessibility) typically quote only by sales call and run $25,000–$100,000+ for full enterprise engagements. Audit turnaround is typically two to four weeks; the full cycle including remediation and issuing the ACR is closer to four to eight weeks. Line up the evaluator before you bid into a Virginia RFP, not after award — the timeline doesn't survive a tight delivery schedule otherwise.

One warning: avoid overlay vendors (accessiBe, UserWay, AudioEye, EqualWeb) as your evaluator. The same overlay products the FTC has acted against and the plaintiffs' bar has criticized do not produce a defensible ACR. We covered the overlay problem in detail in the January post; the short version is that a VPAT signed by an overlay vendor carries no procurement weight.

The Massachusetts Checklist (and What Every Reviewer Looks For)

The Massachusetts EOTSS Accessibility Conformance Report Review Checklist is the single best window into how a procurement officer evaluates an ACR. It is publicly posted and it is shorter than most contractors expect. Eight binary checks:

1. Report Date — is the ACR no more than twelve months old?
2. Product and Version — is it specific to the product and version being proposed (not a generic company-level ACR)?
3. Report Creator — was it completed by knowledgeable personnel with accessibility expertise, or by a reputable third-party firm? If internal, the reviewer may contact the named person to ask about their title and expertise. A blank or generic author name is a red flag.
4. Accessibility Standards — does it measure WCAG 2.1 or 2.2 Levels A and AA? A WCAG 2.0-only or 508-only report fails this check.
5. Evaluation Method — did the testing include both automated and manual methods, including assistive technologies (NVDA, JAWS, VoiceOver), keyboard-only navigation, and color-contrast checking? A blank Evaluation Methods field or an automated-only methodology fails.
6. Scope of Testing — does the report identify which specific pages, screens, or functions were tested, and which interface (admin vs. end-user)?
7. Conformance Level Terms — are the standard ITI terms used (Supports, Partially Supports, Does Not Support, Not Applicable), not vendor-invented terms like "Pass" or "Fail"?
8. Remarks Provided — are detailed explanations including violation locations and remediation plans populated for every "Partially Supports" and "Does Not Support" entry, with at least summary examples for "Supports"?

That's it. Eight checks. Harvard's HUIT accessibility team uses an almost identical informal checklist. Section508.gov and the GSA federal review process use a comparable structure. If your ACR survives the Massachusetts checklist, it survives almost every procurement office in the country.

The green flags that pass review: current date; correct product and version; named, credentialed evaluator or reputable firm; WCAG 2.1 or 2.2 AA target; documented manual plus automated plus assistive-technology testing; explicit scope; honest "Partially Supports" entries with specific dated remediation remarks; and a roadmap for the gaps.

The red flags: an empty Remarks column; an ACR claiming "Supports" on nearly every criterion; an evaluator who can't be reached; testing methodology limited to "automated scanning"; a date older than twelve months; a WCAG 2.0 report submitted into a WCAG 2.1 or 2.2 procurement. Any one of these is fixable. Three or more is a rewrite.

The Bashin Warning — Why the Test Record Is the Whole Ballgame

We covered Bashin v. Conduent at length last week — the $2 million-plus settlement against the developer of ReserveCalifornia.com under California's False Claims Act and the Unruh Act. What matters here, in the VPAT context, is the mechanics of how the case turned.

The legal theory was that Conduent made knowingly false representations to the California Department of Parks and Recreation about accessibility — and those representations were material to the state's decision to pay invoices. Reporting on the case indicates Conduent told the state it had run automated checkers with zero errors, while the underlying site had missing page titles, missing headings, and unlabeled controls. Even basic automated checkers flag those issues. The inference plaintiffs drew — and the court allowed to proceed — was that accessibility testing had been deferred and short-changed, and the representations to the client outran the actual test record.

Where do contractors make those representations? In the VPAT.

A VPAT is a set of representations to a government client. When you sign a VPAT marking criteria "Supports" based on an automated-only test plan, and a blind user later cannot use the site, the gap between your VPAT and the test record is the fraud allegation. An automated-only VPAT is not a defense; it is the evidence against you. Conversely, an honest VPAT — "Partially Supports, here's the gap, here's the date" — backed by a documented manual and assistive-technology test record is genuinely protective. It shows you didn't knowingly misrepresent.

This is why the Evaluation Methods Used field in the Product Information block is the most important sentence in the entire document. Treat it as the field that has to hold up in deposition. Name everything:

• Specific tools — "axe DevTools 4.10, WAVE, Color Contrast Analyzer 3.x, Lighthouse 12."
• Specific assistive technologies and versions — "NVDA 2024.x on Firefox 125, JAWS 2024 on Chrome 124, VoiceOver on Safari 17 and iOS 18."
• Specific methods — "keyboard-only navigation, screen-reader testing, 200% and 400% browser zoom, color-contrast measurement against background images."
• Specific scope — "tested the public permit-application workflow (six pages), the payment confirmation flow (three pages), and the homepage template."
• Specific user roles — "end-user interface and administrator interface tested separately."
• Specific dates — "evaluation conducted May 5–9, 2026."

That paragraph is your Bashin defense in writing. The contractor who can produce that document — plus the underlying test artifacts (scan exports, screen-reader recordings, keyboard navigation notes) — has a defensible posture. The contractor with a blank methodology line and an axe-core export does not.

The DHS Trusted Tester certification. The Department of Homeland Security runs a free certification — the Trusted Tester for Web program, currently version 5.1.x — that teaches a repeatable, manual conformance test process aligned with the federal ICT Testing Baseline. The coursework runs about seventy hours. Federal agencies that adopt the program only accept results from certified Trusted Testers. For a solo state and local contractor, you are not legally required to be a Trusted Tester — but the certification is the single most credible way to signal that your manual testing is real, and naming a Trusted Tester methodology in your Evaluation Methods section carries weight with sophisticated reviewers. At minimum, going through the coursework disciplines you out of automated-only habits.

The Ten Most Common Self-Attested VPAT Errors

A compact list of what procurement reviewers see week after week. Any one of these is fixable; any three together is a rewrite.

1. Marking everything "Supports" without manual testing.
2. Blank or marketing-language Remarks ("our product values accessibility").
3. Submitting a pre-2.5 VPAT version.
4. Marking AA criteria as "Not Evaluated" (only AAA may be).
5. Failing to refresh after major product releases.
6. Including only automated test results in the methodology.
7. Conflating WCAG 2.0, 2.1, and 2.2 tables in one report.
8. "Not Applicable" misuse — claiming criteria don't apply when they actually do.
9. Not naming the evaluator, or naming a generic "team."
10. Submitting a VPAT older than twelve months — an automatic "No" on the Massachusetts checklist.

The Solo Contractor Workflow

The path from "I just won a Virginia bid that requires a VPAT" to "I have a defensible ACR in hand," in eight steps:

Step 1 — Read the solicitation, not the internet. Find the exact requirement. Does it say "VPAT" or "ACR"? Does it specify WCAG 2.1 AA or 2.2 AA? Does it require third-party or SME authorship (Virginia) or accept a self-attested document with manual testing (Massachusetts)? Does it demand a remediation roadmap for gaps (Virginia, Massachusetts)? The solicitation overrides every general rule.

Step 2 — Decide: self-attest or hire out. Self-attest only if (a) the jurisdiction allows it, (b) you can do real manual and assistive-technology testing, and (c) you're confident in your WCAG knowledge. Hire a third-party evaluator when the law requires it (Virginia), when the contract is high-value, when the system is complex, or when you cannot credibly test with a screen reader. The Bashin math makes a $1,250–$2,750 audit look cheap against a $2M-plus settlement.

Step 3 — Get the right template. Download VPAT 2.5 WCAG Edition from itic.org/policy/accessibility/vpat. Word format is standard. Don't alter the ITI service mark.

Step 4 — Test for real. Pair automated scanning (axe DevTools, WAVE, Lighthouse) with manual review of every criterion: keyboard-only navigation, screen-reader testing (NVDA, JAWS, or VoiceOver), zoom, color contrast. The scanner is your starting point, not your evaluation. The minimum to support a "Supports" rating on any given criterion is that you actually verified at least one method meets it with no known defects — for interactive criteria that means keyboard and screen-reader verification, not a green checkmark from a scanner.

Step 5 — Handle scope honestly. Decide what you're attesting to. If you built the platform but it embeds third-party components — a payment iframe, a maps widget, a chat tool — you are responsible for the integrated user experience even where you don't own the code. This is where the four-step inheritance playbook from May 25 becomes operational. Get the component vendor's ACR, evaluate it, document the gap, disclose. State clearly in your Scope of Testing what you tested versus what you inherited from a third party. Never silently absorb a third-party component's claims into your own "Supports" entry — that is exactly the misrepresentation Bashin turned on.

Step 6 — Write defensible Remarks and a roadmap. For every gap, name the criterion, the function, the user impact, and a target date. If the jurisdiction requires it (Virginia, Massachusetts), produce a separate Vendor Accessibility Roadmap as a companion document.

Step 7 — Refresh on a schedule. The Massachusetts twelve-month rule is the anchor: no ACR older than twelve months should go to procurement. Beyond that, refresh after any major release, any redesign, any new workflow, and whenever the standard the buyer requires changes (e.g., a Washington client moving to 2.2 AA after July 1, 2026). Annually at minimum; more often if the product ships frequent changes.

Step 8 — Store the test artifacts. This is the step solos skip and regret. Keep, alongside the ACR itself, the evidence that backs every rating — automated scan exports, screen-reader test notes, screenshots and recordings of keyboard navigation, contrast-checker results — all dated, all tied to the product version. If a Bashin-style question is ever asked, your defense is the test record, not the VPAT itself. This is exactly the kind of documentation the audit defense log structure from February was designed to hold. Don't store it in a developer's Downloads folder.

What Comes Next

The series began in January with the regulatory deadline. It worked through procurement language, overlay liability, lawsuit data, audit defense logs, demand-letter response, accessibility statements, third-party inheritance, indemnification clauses, and now the VPAT itself. The remaining gaps for the rest of 2026: the Vendor Accessibility Roadmap as a standalone deliverable (the document Virginia and Massachusetts require alongside the ACR); accessibility in mobile app contracts (which carry their own VPAT rules under the WCAG2ICT mapping); and a year-end retrospective on what the IFR comment period (closed June 22 for DOJ, July 6 for HHS) actually produced.

Bookmark the Massachusetts checklist. Download VPAT 2.5 from ITI before your next bid. And keep the test record — every scan, every screen-reader pass, every keyboard walkthrough — alongside the ACR you sign your name to.

The procurement officer reads eight items. The plaintiff's attorney reads one — the gap between what you said and what you tested. Write the VPAT for both.