Accessibility Conformance Report

GOVvpat against WCAG 2.1 Level AA

We review other people’s conformance reports for a living. This is ours, held to the same standard we apply to theirs: a conformance level for every criterion, the evidence behind each one, and an explicit account of what we did not test.

We target WCAG 2.1 Level AA — the standard the ADA Title II rule references for state and local government web content, and the one most of our customers are held to. Where WCAG 2.2 adds criteria at A and AA we treat those as in scope too. Reader preferences for text size, contrast, spacing, underlined links and reduced motion are built into the design tokens: we do not use an accessibility overlay, and we would advise you against vendors who do.

Machine-readable copy (OpenACR YAML)Validated against GSA’s OpenACR schema and the 2.5-edition-wcag-2.2-508-en catalog, and generated from the same source as this page so the two cannot disagree. Print this page for a PDF for the procurement file.

Product: GOVvpat
Version: Web application, 23 August 2026 build
Report date: 23 August 2026
Standard: WCAG 2.1 Level A and AA, with WCAG 2.2 additions reported separately
Scope: The GOVvpat public website, the signed-in application, the staff administration panel, and the documents the product generates — the PDF and CSV review exports that go into a procurement file.
Re-evaluation: Re-evaluated quarterly, and on any release that changes navigation, forms, dialogs, the upload path or the export documents.
Test environment: Chromium 140 (headless) on Linux, at 1280, 768, 767, 640 and 320 CSS pixels, in both the light and dark themes, and with forced-colors emulation for Windows High Contrast Mode. Generated PDFs validated with veraPDF 1.26 against PDF/UA-1. No other browser, no other operating system, and no assistive technology has been used.
Contact: sales@govvpat.com

How this was evaluated

Automated rule checking
axe-core 4.10.2 run in headless Chrome against the WCAG 2.1 A and AA rule set, across all fifteen public page templates and across the signed-in application and administration panel — dashboard, vendor vault, open items, reports, notifications, analyzer, search, account, team and staff sign-in — with the application running against a seeded database. Zero violations at the date of this report.
Reflow and zoom measurement
Every public template rendered at 320 CSS pixels (equivalent to 1280 at 400% zoom) and at 640 CSS pixels (200% zoom), checking that the page itself cannot be scrolled horizontally — and every page of the signed-in application at 640 and 320 pixels, plus 767 and 768 either side of the layout’s breakpoint, because a breakpoint layout can pass at 320 and 1280 and still fail in the band between. All pass.
Text-spacing measurement
The line-height, letter-spacing, word-spacing and paragraph-spacing values named in WCAG 1.4.12 applied to every page, checking for clipped or overlapping content. No clipping found.
Contrast computation
Every text and control colour computed against the background it actually renders on, in both the light and dark themes, using the WCAG relative-luminance formula — not sampled by eye, and not limited to what an automated checker reaches.
PDF validation
The review export the product generates was rendered and validated with veraPDF against PDF/UA-1 — a machine check of our own output rather than an inspection of our own source. It does not conform: at first run, 12 failed rules and 142 failed checks. Declaring the document language and asking viewers to display the title closed 3 rules and 55 checks; the remaining 9 rules and 87 checks are the missing structure tree and are recorded against 504.2.2.
Machine-readable validation
The OpenACR copy of this report is validated against GSA's own schema and the 2.5-edition-wcag-2.2-508-en catalog with their validator, not merely parsed back. That is what caught a chapter of invented criterion identifiers — 501.1 and a bare 502.3 do not exist in the catalog — and a component name that Section 508 chapters do not accept. A machine-readable copy whose identifiers do not line up with the catalog is worse than none.
Source review
Manual review of all sixty-eight interface components and every route, covering keyboard operability, focus management, accessible names, label association, landmark and heading structure, and live regions.

What this evaluation did not cover

A report listing no limitations is a report nobody tested. These are ours.

Testing with screen readers (JAWS, NVDA, VoiceOver or TalkBack), voice control, or switch access. No claim below rests on assistive-technology confirmation, and criteria that ultimately depend on it are marked accordingly.
Testing by people with disabilities.

This evaluation was carried out in-house and is not signed by a certified tester. It will be superseded once assistive-technology testing is complete.

Conformance by criterion

Where a criterion says a defect was corrected during this evaluation, that is what happened — the alternative was to fix it quietly and report only the result.

What the conformance levels mean

Supports: The functionality meets the criterion without known defects.
Partially Supports: Some functionality does not meet the criterion, or the evidence does not yet establish that it does. The remark says which.
Does Not Support: The majority of the functionality does not meet the criterion.
Not Applicable: The criterion is not relevant to this product — usually because the product contains nothing the criterion governs.

Table 1: Success Criteria, Level A

Table 1: Success Criteria, Level A. Criterion, conformance level, and remarks.
Criterion	Conformance	Remarks and explanations
1.1.1Non-text Content	Supports	Decorative icons are marked aria-hidden or sit inside a control that carries its own name. The single content image has alt text. Numeric badges repeat their meaning in visually hidden text so a count is not announced as a list position.
1.2.1Audio-only and Video-only (Prerecorded)	Not Applicable	The product contains no audio or video.
1.2.2Captions (Prerecorded)	Not Applicable	No prerecorded media.
1.2.3Audio Description or Media Alternative	Not Applicable	No prerecorded media.
1.3.1Info and Relationships	Partially Supports	webSupports Headings, lists and data tables use native elements, and comparison tables carry a caption and th scope. Corrected during this evaluation: eighteen label elements across the upload panel, account settings, the team invite dialog, the new-organization dialog and staff sign-in had no htmlFor and were associated with nothing, and three search or filter inputs relied on a placeholder alone — five found only once the application was run and scanned. Not confirmed against a screen reader. electronic-docsDoes Not Support The generated review PDF has no structure tree, so its headings and tables carry no programmatic relationships at all: veraPDF reports 78 pieces of content neither tagged nor marked as artifact. See 504.2.2.
1.3.2Meaningful Sequence	Partially Supports	webSupports Reading order follows DOM order throughout; no CSS positioning reorders content away from its source sequence. electronic-docsDoes Not Support Being untagged, the PDF declares no reading order — what assistive technology receives is whatever order the content stream happens to be in. See 504.2.2.
1.3.3Sensory Characteristics	Supports	No instruction depends on shape, size, position or sound. Conformance ratings are named in text.
1.4.1Use of Color	Supports	Status, severity and conformance ratings carry a text label beside the colour. The current navigation item is now also exposed with aria-current, where previously it was distinguished by colour and weight alone.
1.4.2Audio Control	Not Applicable	Nothing plays audio.
2.1.1Keyboard	Supports	Two Level A defects were found and corrected during this evaluation. The report upload area — the product's primary action — was a click-only div with a display:none file input and could not be reached or fired from a keyboard at all; it now has a real button. Notification rows were clickable divs with no role, tab stop or key handling. Scrollable table regions were also given tab stops so their off-screen columns can be reached.
2.1.2No Keyboard Trap	Supports	The only component that holds focus is the modal dialog, which does so deliberately while open and releases on Escape or close.
2.1.4Character Key Shortcuts	Supports	The product implements no single-character key shortcuts.
2.2.1Timing Adjustable	Supports	The interface sets no time limit on reading or completing anything. A message component supporting auto-dismissal exists but is not used anywhere.
2.2.2Pause, Stop, Hide	Partially Supports	Nothing moves, blinks or scrolls. The unread-notification count does refresh every sixty seconds without a control to pause it. It does not move or obscure content, but the criterion covers auto-updating information and no pause mechanism is offered.
2.3.1Three Flashes or Below Threshold	Supports	Nothing flashes.
2.4.1Bypass Blocks	Supports	Corrected during this evaluation. A skip link existed on the public pages only; the signed-in application and admin panel repeat a twelve-item sidebar and a toolbar ahead of the content on every page and had none. Both now carry one, targeting a main landmark.
2.4.2Page Titled	Supports	Corrected during this evaluation. Public pages carried unique descriptive titles, but every page of the signed-in application and admin panel inherited one generic site title. All nineteen now set their own.
2.4.3Focus Order	Supports	Corrected during this evaluation. Modal dialogs declared aria-modal but never moved focus into the panel, kept it there, or returned it on close — a keyboard user tabbed through the page behind the overlay. Focus now enters on open, is trapped while open, and returns to the control that opened it.
2.4.4Link Purpose (In Context)	Partially Supports	webSupports Link text describes its destination; no bare "click here" or "read more" without context. electronic-docsDoes Not Support veraPDF clause 7.18.5: links in the PDF are not tagged as Link elements and carry no alternate description via their Contents key, so their purpose is not programmatically available.
2.5.1Pointer Gestures	Supports	No multipoint or path-based gestures. Drag-and-drop upload now has an equivalent single-pointer button, which it did not before this evaluation.
2.5.2Pointer Cancellation	Supports	Activation happens on the up-event via native button semantics throughout.
2.5.3Label in Name	Supports	Accessible names begin with the visible label text where a visible label exists.
2.5.4Motion Actuation	Not Applicable	No function is operated by device motion.
3.1.1Language of Page	Partially Supports	webSupports Every page sets lang="en" on the root element from the root layout. electronic-docsPartially Supports The PDF declared no natural language at all (52 failed checks under veraPDF clause 7.2). Corrected during this evaluation by declaring English on the document, but without a structure tree the declaration cannot be scoped to passages, so it is not a full claim.
3.2.1On Focus	Supports	Focusing a control never changes context.
3.2.2On Input	Supports	No field submits a form or changes context on change; filters require an explicit submit.
3.3.1Error Identification	Supports	Errors are described in text, not by colour alone, and are now announced — see 4.1.3.
3.3.2Labels or Instructions	Supports	Every input, select and textarea has a programmatically associated label after the corrections described at 1.3.1, verified both by scanning the source for label elements that neither carry htmlFor nor wrap their control, and by running the application and scanning it. Placeholders are no longer used as the only label anywhere.
4.1.1Parsing (obsolete)	Not Applicable	Removed in WCAG 2.2 and declared always satisfied by the WCAG 2.1 errata, so it is reported here for completeness rather than assessed. For the record, markup is generated by React and element ids are unique.
4.1.2Name, Role, Value	Partially Supports	webSupports Several defects corrected during this evaluation: unlabelled search and filter inputs; four unassociated labels; an icon-only key-revocation button with neither an aria-label nor a title; notification rows exposed as static text; a dialog with no accessible name; and a tab pattern that declared role="tab" without panels, roving focus or arrow keys, now described accurately as toggle buttons. Current navigation is exposed with aria-current. Not confirmed against a screen reader. electronic-docsDoes Not Support With no structure tree, nothing in the PDF exposes a name, role or value — including its links (veraPDF 7.18.5) and its annotations (7.18.1). See 504.2.2.

Table 2: Success Criteria, Level AA

Table 2: Success Criteria, Level AA. Criterion, conformance level, and remarks.
Criterion	Conformance	Remarks and explanations
1.2.4Captions (Live)	Not Applicable	No live media.
1.2.5Audio Description (Prerecorded)	Not Applicable	No prerecorded media.
1.3.4Orientation	Supports	Nothing restricts the view to a single orientation.
1.3.5Identify Input Purpose	Supports	Fields collecting the user's own information declare autocomplete tokens. The organization field on the quote form was missing one and was corrected during this evaluation.
1.4.3Contrast (Minimum)	Supports	Every text colour was computed against the background it actually renders on, in both themes. Five failures were corrected during this evaluation: quote-form hint text at 4.09:1 and its placeholder at 2.23:1, a sign-in helper line at 4.46:1, analyzer body text at 2.43:1, and secondary sidebar text at 3.58:1.
1.4.4Resize Text	Supports	Verified by rendering at 640 CSS pixels, the equivalent of 200% zoom on a 1280 viewport, with no loss of content or function and no horizontal page scrolling — on the public templates and, separately, on every page of the signed-in application. The signed-in pages were originally only measured at 320 and the gap argued away on the grounds that 320 subsumes 640, which is not true of a breakpoint layout: passing at 320 with a mobile stack engaged and at 1280 on desktop says nothing about the band between, and this shell changes behaviour at exactly that boundary. It was measured instead, at 640 and on both sides of the breakpoint at 767 and 768.
1.4.5Images of Text	Partially Supports	webSupports All interface text is live text. The only rendered images of text are social share cards, which are not page content. electronic-docsPartially Supports PDF text remains real text, not images of text. However veraPDF clause 7.21.4.1 reports the fonts are not embedded, so rendering depends on substitution by the reader's system, which we do not control.
1.4.10Reflow	Supports	Corrected during this evaluation, in two places. On the public site the homepage comparison table added roughly 280 pixels of horizontal scrolling to the page at 320 CSS pixels. In the signed-in application the whole shell failed: the sidebar was a fixed 240-pixel column at every width, so every page pushed its content off-screen and scrolled sideways by 100 to 150 pixels. The sidebar now becomes a horizontal strip below the medium breakpoint and is unchanged above it. Every public and signed-in page now reflows at 320 pixels with no horizontal page scrolling; wide tables scroll inside their own labelled, keyboard-reachable region.
1.4.11Non-text Contrast	Supports	Corrected during this evaluation in two places, neither reported by any automated tool. Form-control borders measured between 1.24:1 and 1.66:1 against their surfaces in both themes while being the only thing identifying a field as a field; a dedicated control-border token now measures 3.86:1 light and 3.85:1 dark. Separately, the focus indicator measured 5.34:1 on white and 8.19:1 on the dark surface but only 2.85:1 against the navy hero bands that carry the marketing call-to-action buttons; it now carries a page-ground halo that reads 15.25:1 against that band, so one component of the ring always clears 3:1. That halo is a box-shadow, and forced-colors emulation confirmed the browser discards box-shadow in Windows High Contrast Mode — where the hero band, being a gradient rather than a background colour, is not necessarily replaced. A forced-colors rule now paints the ring in the system Highlight colour, so the indicator stops depending on our palette.
1.4.12Text Spacing	Supports	Verified by applying the criterion's own spacing values to every page and checking for clipped or overlapping content. None found. A reader preference also offers roomier spacing without needing a user stylesheet.
1.4.13Content on Hover or Focus	Supports	There is no author-styled hover or focus content. The few native title tooltips are drawn by the browser and are outside the scope of this criterion.
2.4.5Multiple Ways	Supports	Pages are reachable through the main navigation, the footer, an article index, a jurisdiction search and an XML sitemap.
2.4.6Headings and Labels	Supports	One h1 per page with a descriptive hierarchy beneath it; labels describe what they ask for.
2.4.7Focus Visible	Supports	A 2px focus-visible outline with 3px offset is applied globally, and every control that suppresses the default outline substitutes a visible ring. Verified across the whole source: no control removes its focus indicator without replacing it. A high-contrast reader preference thickens it further.
3.1.2Language of Parts	Supports	All content is in English; there are no passages in another language.
3.2.3Consistent Navigation	Supports	Navigation appears in the same place and the same order on every page of each surface.
3.2.4Consistent Identification	Supports	The same function is labelled the same way throughout.
3.3.3Error Suggestion	Partially Supports	Errors are identified in text and describe what is wrong, and field-level constraints are stated before submission. Not every message suggests a specific correction — an upload rejected for its file type says so, but does not always name the accepted alternative.
3.3.4Error Prevention (Legal, Financial, Data)	Supports	Corrected during this evaluation. Two irreversible actions — revoking an API key and removing a team member — executed immediately on a single click of a small icon, with no confirmation and no undo. Both now require a confirmation that names exactly what will be lost.
4.1.3Status Messages	Supports	Corrected during this evaluation. Flash messages announcing a save, an upload or a failure were plain elements and were never announced at all. They now carry role="status" or role="alert", with errors interrupting and confirmations waiting for a pause.

Table 3: WCAG 2.2 additions (Level A and AA)

Table 3: WCAG 2.2 additions (Level A and AA). Criterion, conformance level, and remarks.
Criterion	Conformance	Remarks and explanations
2.4.11Focus Not Obscured (Minimum)	Supports	Measured, and the first measurement was wrong. The harness originally centred each control before focusing it, which is what a test does rather than what a browser does — native Tab scrolls a control to the nearest edge, which is exactly how one ends up under a sticky header, so centring manufactured a pass by avoiding the geometry the criterion exists to catch. Re-run letting the browser scroll naturally, sampling three points per control and treating any painter as an obstruction regardless of DOM relationship, it found the scrollable criterion tables on this very page clipped by the sticky marketing header. Corrected with scroll-margin-top reserving the header's height. Now clean on both counts: nothing entirely hidden (2.4.11) and nothing partially clipped (2.4.12, which is AAA and not otherwise claimed).
2.5.7Dragging Movements	Supports	The only dragging interaction is drag-and-drop upload of a conformance report, and it now has a single-pointer equivalent — a Browse files button added during this evaluation, which was also what fixed 2.1.1.
2.5.8Target Size (Minimum)	Supports	Measured across the marketing pages, the dashboard, account and team screens. The icon-only controls flagged as a risk — revoking an API key and removing a team member — are 26 by 26 CSS pixels (a 14-pixel icon in 6 pixels of padding), above the 24-pixel minimum. The remaining targets under 24 pixels are inline links inside a sentence, which the criterion exempts, and none of them fails the 24-pixel spacing test.
3.2.6Consistent Help	Supports	The public pages carry an FAQ link and a support address in the footer, in the same relative order on every page. The signed-in application presents no help mechanism, so the criterion is not engaged there — which is itself worth fixing, but is not a conformance failure.
3.3.7Redundant Entry	Supports	The only multi-step flow is the two-step analyzer, and the second step does not ask again for anything entered or selected in the first.
3.3.8Accessible Authentication (Minimum)	Partially Supports	The sign-in surfaces we control require no cognitive function test: email and password only, no CAPTCHA, no puzzle, no transcription step. Paste is not blocked anywhere in the product and the fields declare autocomplete tokens, so a password manager completes them. The organization sign-in is delegated to a third-party identity provider whose hosted flow may present a verification-code step we neither control nor have evaluated, which is why this is not a full claim.

Chapter 3: Functional Performance Criteria

Chapter 3: Functional Performance Criteria. Criterion, conformance level, and remarks.
Criterion	Conformance	Remarks and explanations
302.1Without Vision	Partially Supports	The interface is built to be operable without sight — semantic structure, accessible names, keyboard operability throughout, live regions for status — and the defects that would have prevented it have been corrected. It has not been tested with a screen reader, so we do not claim this as established. This is deliberately graded lower than the success criteria beneath it: an individual criterion such as 1.3.1 or 4.1.2 is verifiable from markup and automated rules, whereas a functional performance criterion asks whether a whole task can be completed without sight, and that question is only answered by running the task with assistive technology.
302.2With Limited Vision	Supports	Verified at 200% and 400% zoom with no loss of content or horizontal scrolling, with computed contrast in both themes, and with built-in text-size, contrast and spacing preferences that adjust the design tokens rather than overlaying the page.
302.3Without Perception of Color	Supports	No information is conveyed by colour alone.
302.4Without Hearing	Not Applicable	No audio content.
302.5With Limited Hearing	Not Applicable	No audio content.
302.6Without Speech	Not Applicable	No function requires speech.
302.7With Limited Manipulation	Supports	Every function is operable from the keyboard alone. Drag-and-drop has a button equivalent, and no function requires a path-based or multipoint gesture.
302.8With Limited Reach and Strength	Supports	No timed interactions and no sustained input; controls are reachable in a linear tab order.
302.9With Limited Language, Cognitive and Learning Abilities	Partially Supports	Plain language, consistent structure, explicit field instructions and confirmation on destructive actions. No formal readability testing has been carried out, and some of the subject matter is unavoidably technical.

Chapter 4: Hardware

Chapter 4: Hardware. Criterion, conformance level, and remarks.
Criterion	Conformance	Remarks and explanations
402–415All hardware requirements	Not Applicable	GOVvpat is web software delivered through a browser. It includes no hardware, no closed functionality and no peripheral of its own, so every requirement in this chapter is out of scope. Reported as a chapter-level statement rather than 55 identical rows; the machine-readable copy omits the chapter entirely, which is how OpenACR expresses the same thing.

Chapter 5: Software

Chapter 5: Software. Criterion, conformance level, and remarks.
Criterion	Conformance	Remarks and explanations
502.2.1User Control of Accessibility Features	Not Applicable	Not platform software; it exposes no platform accessibility features to control.
502.2.2No Disruption of Accessibility Features	Supports	Runs in a browser tab and disrupts no platform accessibility feature. It honours the platform's colour-scheme and reduced-motion settings rather than overriding them.
502.3.1Object Information	Partially Supports	Exposed through standard HTML and ARIA rather than a custom control layer, so the browser's own accessibility API carries it. Graded with 302.1 and the other 502.3.x rows: whether it reaches assistive technology is a question only assistive technology answers, and none was used.
502.3.2Modification of Object Information	Partially Supports	Editable objects are native form controls, which assistive technology modifies through the platform. Not confirmed with assistive technology.
502.3.3Row, Column, and Headers	Partially Supports	Data tables use native table markup with caption and th scope, so row and column headers are programmatically associated. Not confirmed with assistive technology, and the PDF export carries no table structure at all — see 504.2.2.
502.3.4Values	Partially Supports	Current values are the native values of native controls. Not confirmed with assistive technology.
502.3.5Modification of Values	Partially Supports	Values are set through native controls, which assistive technology drives through the platform. Not confirmed with assistive technology.
502.3.6Label Relationships	Partially Supports	Every control is now programmatically associated with its label — eighteen were not at the start of this evaluation. Not confirmed with assistive technology.
502.3.7Hierarchical Relationships	Partially Supports	Structure is conveyed by native headings, lists and landmarks. Not confirmed with assistive technology, and absent entirely from the PDF export.
502.3.8Text	Partially Supports	All interface text is live text in the DOM. Not confirmed with assistive technology.
502.3.9Modification of Text	Partially Supports	Editable text lives in native inputs and textareas. Not confirmed with assistive technology.
502.3.10List of Actions	Partially Supports	Actions are native buttons and links, so the platform enumerates them. Not confirmed with assistive technology.
502.3.11Actions on Objects	Partially Supports	Every action is executable from the keyboard — two that were not are recorded at 2.1.1. Not confirmed with assistive technology.
502.3.12Focus Cursor	Partially Supports	Focus is tracked by the browser and always visibly indicated; the indicator's contrast is recorded at 1.4.11. Not confirmed with assistive technology.
502.3.13Modification of Focus Cursor	Partially Supports	Focus is settable through the platform; nothing traps or overrides it except the modal dialog, deliberately and reversibly. Not confirmed with assistive technology.
502.3.14Event Notification	Partially Supports	State changes that happen without a page change are announced through live regions, added during this evaluation — see 4.1.3. Not confirmed with assistive technology.
502.4Platform Accessibility Features	Not Applicable	Not a platform or a platform-level assistive technology.
503.2User Preferences	Supports	Honours the platform's colour-scheme and reduced-motion preferences, and adds text size, contrast and spacing controls that adjust design tokens rather than overlaying the page.
503.3Alternative User Interfaces	Not Applicable	Provides no alternative user interface that would need to expose itself as assistive technology.
503.4.1Caption Controls	Not Applicable	No audio or video content.
503.4.2Audio Description Controls	Not Applicable	No audio or video content.
504.2Content Creation or Editing	Partially Supports	GOVvpat does not author conformance reports, but it does generate documents — a PDF and a CSV of each completed review. The CSV is plain text and carries no accessibility semantics to lose. The PDF does not conform; the detail is at 504.2.2.
504.2.1Preservation of Information Provided for Accessibility	Partially Supports	The review's structure — criterion, level, conformance, remarks — is preserved as visible text and as columns in the CSV, but the PDF discards its programmatic form because it is untagged. Nothing an author supplied is lost from the CSV.
504.2.2PDF Export	Does Not Support	Measured, not asserted. The generated review PDF was validated with veraPDF against PDF/UA-1 and is non-compliant: no MarkInfo/Marked entry, no structure tree, and 78 pieces of page content neither tagged nor marked as artifact. Links are untagged and carry no alternate description; fonts are not embedded. Corrected during this evaluation: the document now declares its natural language and asks viewers to display its title, which closed 3 rules and 55 checks of the original 12 and 142. The remainder cannot be fixed in the current engine — TCPDF emits no structure tree — so conformance means changing the generator or offering an HTML review document that conforms at the same level as the rest of the product. This is the most significant open defect in this report.
504.3Prompts	Not Applicable	Does not author web content on a user's behalf, so there is nothing to prompt for.
504.4Templates	Not Applicable	No templates are offered for creating content.

Chapter 6: Support Documentation and Services

Chapter 6: Support Documentation and Services. Criterion, conformance level, and remarks.
Criterion	Conformance	Remarks and explanations
602.2Accessibility and Compatibility Features	Supports	This report documents the conformance level, the evaluation methods and the known gaps, and is published openly at /accessibility rather than sent on request. It is the accessibility statement — the two were separate documents and were merged, so there is one place to look and nothing to keep in step.
602.3Electronic Support Documentation	Supports	Support documentation is delivered as pages of this website and conforms to the same level reported here.
602.4Alternate Formats for Non-Electronic Support Documentation	Not Applicable	All support documentation is electronic; none is published on paper.
603.2Information on Accessibility Features	Supports	Support staff can answer questions about the features described here. The contact address is published at the end of this report.
603.3Accommodation of Communication Needs	Partially Supports	Support is offered by email, which does not require speech or hearing and does not impose a time limit on composing a request. It is currently the only channel, so someone who cannot use email has no alternative route; a published telephone and relay option is outstanding.

Revision history

An undated conformance report is indistinguishable from one generated the night before a submission. This is what has changed and when.

Version 1.323 August 2026
- Corrected a contradiction this report introduced and then published: 1.3.1, 1.3.2 and 3.1.1 carried remarks reading "graded down because the PDF export is in scope" while still declaring Supports. The justification was written and the value was never changed, so both the page and the machine-readable copy asserted full support for criteria the same sentence said were not met.
- Criteria that differ between the web surfaces and the generated documents are now reported per component — web and electronic-docs — rather than as one blended figure, which is what OpenACR's component mechanism is for. 1.3.1, 1.3.2, 3.1.1, 1.4.5, 2.4.4 and 4.1.2 all carry both.
- veraPDF's untagged-link and non-embedded-font findings now reach the criteria they bear on (2.4.4, 4.1.2, 1.4.5) instead of living only under 504.2.2.
- OpenACR copy: version now increments per revision instead of emitting a constant 1; dates are ISO; feedback points at a reporting route rather than back at this document; the revision history is carried in notes.
- Fixed cross-references to 504.2 that should have been 504.2.2, and a note citing the bare identifier 502.3 — which this report's own methods section names as one of the invented ones GSA's validator rejected.
Version 1.223 August 2026
- Scope widened to the generated review exports, and 1.3.1, 1.3.2 and 3.1.1 graded down accordingly — the scope named the PDF while the tables still described only the web surfaces.
- Generated PDF validated with veraPDF against PDF/UA-1 rather than by reading our own source. Document language and title display corrected; the missing structure tree recorded against 504.2.2.
- 2.4.11 re-measured after finding the method unsound: the harness centred each control before focusing it, which avoided the sticky-header geometry the criterion exists to catch. The honest re-run found a defect on this page; it is fixed.
- 1.4.4 evidence for the signed-in application replaced with a measurement at 640px and at the breakpoint boundary, in place of an argument that 320px subsumes 640px — which is not true of a breakpoint layout.
- 502.3 graded down to match 302.1, both being questions only assistive technology answers.
- Focus indicator checked under forced-colors emulation; the halo is discarded in High Contrast Mode, so the ring now uses the system Highlight colour.
- Chapter 5 rebuilt against GSA's catalog. The previous version used identifiers that do not exist (501.1, a bare 502.3) and omitted 504.2.2 PDF Export, which is the criterion a Section 508 reviewer looks for first given what this product generates. 602.4 added to Chapter 6.
- The OpenACR copy now validates against GSA's schema and catalog with their own validator, which is how the invented identifiers were found.
Version 1.123 August 2026
- WCAG 2.2 additions reported. The introduction had claimed 2.2 was in scope while neither table contained a single 2.2 criterion.
- Section 508 Chapters 4 and 5 added; their absence read as incomplete rather than inapplicable.
- Terms table added defining the four conformance levels.
- 603.3 graded down: email is the only support channel.
- Focus-indicator contrast added to 1.4.11 — the ring measured 2.85:1 against the navy hero bands.
Version 1.023 August 2026
- First publication, replacing the accessibility statement that had promised a conformance report and withheld it.
- That statement claimed exports were produced as tagged documents. They were not, and the claim did not survive this evaluation.

Tell us where this is wrong

If you find something this report gets wrong, we want the specific thing — the page, what you were using, and what happened. Email sales@govvpat.com. A correction to this report is a better outcome for us than an unchallenged claim, and we will say plainly whether it is something we will fix and when.

That is a monitored shared inbox rather than an accessibility@ alias, by choice: role addresses that nobody has been assigned to bounce, and a bounce on the page someone reads because they cannot use the site is worse than an address a person actually reads.