VPAT 2.5 Rev
The standard document procurement teams request to verify product accessibility, in the current VPAT 2.5 format.
Here is what you get. The core deliverable is the conformance report procurement asks for, in the standard VPAT format. The add-ons below are what your developers work from. All of it describes your product as of the day the audit closes.
The standard document procurement teams request to verify product accessibility, in the current VPAT 2.5 format.
Digital accessibility report format accepted by the GSA (General Services Administration) and other federal procurement systems. Required for many government contracts.
Public disclosure on the W3C WAI model, ready for your site: what was tested, what conforms, what does not yet. Harbor gives no legal advice; ask counsel before publishing.
Each finding includes plain-English impact and a recommended fix. These examples highlight issues that automated scanners typically miss.
SC 4.1.2, Name, Role, Value · Level A · WCAG 2.2 AA
Plain-English Impact
A keyboard-only user opens a confirmation dialog they cannot escape. The close button has no accessible name, so screen reader users hear only “button” when focus lands on it.
Recommended Fix
- <button onClick={onClose}>
- <span className="icon icon-close" />
- </button>
+ <button type="button" onClick={onClose}
+ aria-label="Close dialog">
+ <span className="icon icon-close"
+ aria-hidden="true" />
+ </button>SC 1.1.1, Non-text Content · Level A · WCAG 2.2 AA
Plain-English Impact
A revenue chart in the dashboard uses generic alt text, technically present, so automated scanners report it as passing. A screen reader user hears only “chart” with no access to the data the visualization represents. Automated tools check whether alt text exists; only a human can evaluate whether it communicates the same information.
Recommended Fix
- <img src="revenue-chart.png"
- alt="chart" />
+ <img src="revenue-chart.png"
+ alt="Monthly revenue: Jan $42K,
+ Feb $47K, Mar $51K, 21%
+ growth" />
+ <details>
+ <summary>View as data table</summary>
+ <!-- data table alternative -->
+ </details>SC 2.4.3, Focus Order · Level A · WCAG 2.2 AA
Plain-English Impact
When a user submits a search form, results appear below the form but keyboard focus stays on the submit button. A sighted user sees the results immediately. A screen reader user has no indication that content changed and must manually navigate the page to find what appeared. Automated tools detect the DOM update but cannot evaluate whether focus was moved appropriately.
Recommended Fix
const handleSearch = async () => {
const results = await fetchResults(query);
setResults(results);
- // focus stays on submit button
+ resultsRef.current?.focus();
};
- <div className="results">
+ <div className="results" ref={resultsRef}
+ tabIndex={-1} role="region"
+ aria-label="Search results">Prioritized fix plan with effort estimates, broken down for your engineering team.
Code patch files showing exactly what to change in your codebase to fix each finding. Minimal, focused changes.
CSV-ready issue backlog with pre-filled WCAG labels, components, and remediation checklists.
Engagements are priced per project. The documents come with it. Reach out and we’ll scope the right combination together.
A VPAT is only useful if the right people can find it. Here is where to put it, and how long it stays good for.
Both documents from a real, anonymized audit, in full and with nothing behind a form. The conformance report is the one procurement asks for. The remediation plan is how your developers close it out: every finding, severity rating, and the exact code change.
The client’s name and domain are withheld.