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.
- Product
- GOVvpat
- Version
- Web application, 24 August 2026 build
- Report date
- 24 August 2026
- Standard
- WCAG 2.1 Level A and AA
- Scope
- The GOVvpat public website, the signed-in application, and the staff administration panel.
- 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 320 pixels. All pass at both widths.
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.
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.
Table 1: Success Criteria, Level A
| 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 | Supports | Headings, lists and data tables use native elements; 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 of those were found only once the signed-in application was run and scanned — a source-level sweep had missed them. Not yet confirmed against a screen reader. |
| 1.3.2Meaningful Sequence | Supports | Reading order follows DOM order throughout; no CSS positioning reorders content away from its source sequence. |
| 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) | Supports | Link text describes its destination; no bare “click here” or “read more” without context. |
| 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 | Supports | lang="en" is set on the root element of every page from the root layout. |
| 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 | Supports | Markup is generated by React and is well-formed; element ids are unique, including where the same field appears in two modes of the upload panel. |
| 4.1.2Name, Role, Value | Supports | 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 yet confirmed against a screen reader. |
Table 2: Success Criteria, Level AA
| 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 every public template at 640 CSS pixels, the equivalent of 200% zoom on a 1280 viewport. No content or function is lost and the page does not scroll horizontally. |
| 1.4.5Images of Text | Supports | All text is live text. The only rendered images of text are social share cards, which are not page content. |
| 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, and the finding no automated tool reported: form-control borders measured between 1.24:1 and 1.66:1 against their surfaces in both themes, while the border was the only thing identifying a field as a field. A dedicated control-border token now measures 3.86:1 in the light theme and 3.85:1 in the dark. |
| 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. |
Chapter 3: Functional Performance Criteria
| 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 yet been tested with a screen reader, so we do not claim this as established. |
| 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 6: Support Documentation and Services
| Criterion | Conformance | Remarks and explanations |
|---|---|---|
| 602.2Accessibility and Compatibility Features | Supports | This report and the accessibility statement document the conformance level, the evaluation methods and the known gaps, and are published openly rather than sent on request. |
| 602.3Electronic Support Documentation | Supports | Support documentation is delivered as pages of this website and conforms to the same level reported here. |
| 603.2Information on Accessibility Features | Supports | Support staff can answer questions about the features described here; the contact route is published on the accessibility statement. |
| 603.3Accommodation of Communication Needs | Supports | Support is offered by email, which does not require speech or hearing. We aim to respond within two business days. |
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.