Accessibility Conformance Report

Based on VPAT^® Version 2.5 — Revised Section 508 edition · Report date: 12 August 2026

Summary

Name of product: AgencyDoc — An Administrative and Human Resource Management Tool
Product version: Build 2026-08-12c
Product description: A web application for fire departments and public-safety agencies: writing, adopting, distributing and acknowledging policies and procedures, plus job descriptions, collective bargaining reference, discipline documentation and testing.
Vendor: Public Safety Training and Development
Standards this report covers: WCAG 2.1 Level A and Level AA (W3C Recommendation, 5 June 2018)
Revised Section 508 (36 CFR Part 1194, Appendix A, C and D) — Chapters 3, 4, 5 and 6
Evaluation methods: Described in full under How this was tested. In short: an automated axe-core 4.13 audit across ten application screens; a scripted keyboard and assistive-technology walkthrough in a real browser measuring focus order, focus-indicator contrast, live regions, landmarks and reflow at 320 CSS px; a line-by-line source review against each criterion; and colour measurement by relative-luminance calculation rather than visual judgement.

Read the verdicts as written. Every WCAG 2.1 Level A criterion is met. Fourteen criteria are marked Partially Supports, and the remarks say exactly what is missing in each — a report with nothing but "Supports" in it has usually not been tested. Every "Supports" below refers to behaviour that was measured in a browser or read in the source, not assumed. The largest caveat is not in the tables at all: see How this was tested.

How to read the conformance column

Supports: The functionality meets the criterion, on everything evaluated.
Partially Supports: Some functionality meets the criterion and some does not. The remarks say which.
Does Not Support: The majority of the functionality does not meet the criterion.
Not Applicable: The criterion is not relevant to this product.

Table 1 — WCAG 2.1 Level A

Criterion	Conformance	Remarks and explanations
1.1.1 Non-text Content	Partially Supports	All nine images in the application carry an `alt` attribute; decorative department logos use `alt=""` so they are not announced on every screen. A drawn signature names its signer. The signature canvas has an accessible name and fallback text pointing to the equally valid typed alternative. Exception: documents an agency uploads are the agency's own files — a scanned PDF with no text layer cannot be read aloud. AgencyDoc can transcribe such a document with AI, which usually resolves it, but the original file's accessibility is outside our control.
1.2.1–1.2.5 Time-based Media	Not Applicable	The product contains no audio or video content.
1.3.1 Info and Relationships	Supports	Landmarks (`header`/`nav`/`main`/`aside`) on every screen; one `h1` per screen with no skipped levels (verified in-browser across twelve screens); all twenty data tables carry an accessible name; form controls have programmatic labels rather than placeholder text alone.
1.3.2 Meaningful Sequence	Supports	Reading order follows DOM order. The exported manual was corrected so it opens with the cover page rather than the running page footer.
1.3.3 Sensory Characteristics	Supports	The one instruction that identified a control by shape and position ("look for the • marker") now names it in words instead.
1.4.1 Use of Color	Supports	Status indicators pair colour with text. The pending-update dot carries hidden text. Diff insertions are underlined as well as tinted, so a tracked change survives both colour blindness and a monochrome printout.
1.4.2 Audio Control	Not Applicable	No audio.
2.1.1 Keyboard	Partially Supports	Every navigation item, control and form field is reachable and operable by keyboard; an automated sweep for pointer-only controls across twelve screens returned none. Exception: drawing a signature freehand on the canvas requires a mouse or touchscreen. A typed signature is offered alongside it, carries identical legal weight in the product, and is announced as the alternative.
2.1.2 No Keyboard Trap	Supports	No trap found. The assistant panel can be left by Tab and closes on Escape.
2.1.4 Character Key Shortcuts	Supports	The product defines no single-character shortcuts.
2.2.1 Timing Adjustable	Supports	An authenticated session lasts 12 hours. Ten minutes before it ends the user is warned by a modal that says how long is left, states that unsaved work would be lost, and offers a single "Keep me signed in" action that extends the session for a further full period. The criterion asks for at least twenty seconds' warning and at least ten extensions; this gives ten minutes and ten extensions. The dialog is an `alertdialog` so it is read immediately rather than queued, focus moves to the extend button, focus is trapped while it is open, and Escape dismisses it. Session length, warning lead time and the extension cap are all configurable per deployment.
2.2.2 Pause, Stop, Hide	Supports	No auto-updating, blinking, scrolling or auto-advancing content. A reduced-motion preference is honoured.
2.3.1 Three Flashes	Supports	Nothing flashes.
2.4.1 Bypass Blocks	Supports	A skip link is the first focusable element on every screen and on the public site. This matters here more than usual: the sidebar carries the department's whole manual, roughly 300 links, ahead of the page content.
2.4.2 Page Titled	Supports	The application is a single page, so the title is set per view — twelve screens verified to report distinct titles. An exported manual is titled after the department rather than after the product, so the resulting PDF is named usefully.
2.4.3 Focus Order	Supports	Focus order follows visual order; no positive `tabindex` anywhere. Navigation moves focus into the new content region rather than dropping it to the top of the document. Closing the assistant returns focus to the control that opened it. A long operation that must disable its own button restores focus when it finishes. A background refresh caused by a colleague's edit deliberately does not move focus — it restores the user's position and announces the change politely.
2.4.4 Link Purpose (In Context)	Supports	Link text plus its context identifies the destination.
2.5.1 Pointer Gestures	Supports	The only path-based gesture is freehand signing, which has a typed alternative.
2.5.2 Pointer Cancellation	Supports	Actions fire on the up-event.
2.5.3 Label in Name	Supports	Accessible names contain their visible label text.
2.5.4 Motion Actuation	Not Applicable	No motion-actuated functionality.
3.1.1 Language of Page	Supports	`lang="en"` on every page.
3.2.1 On Focus	Supports	Focus alone changes no context.
3.2.2 On Input	Partially Supports	The role selector in Manage Users saves to the server on change rather than on an explicit submit. The change is announced and is reversible from the same control, but it is a change of context on input. Under review.
3.3.1 Error Identification	Partially Supports	Errors are described in text and are announced — sign-in failures interrupt via `role="alert"`; other outcome messages are polite live regions. Not every failing field is yet tied to its message with `aria-describedby` and `aria-invalid`. Improvement scheduled.
3.3.2 Labels or Instructions	Partially Supports	Every control has a label and forms carry explanatory text. Required fields are not yet marked with `required`/`aria-required`; the product validates on submit and explains what is missing. Improvement scheduled.
4.1.2 Name, Role, Value	Supports	All six file inputs, the assistant controls and the score-sheet row controls have accessible names. State is programmatic, not merely visual: `aria-current` on the open document and active navigation, `aria-pressed` on toggle pairs, `aria-expanded` on the assistant. Verified in-browser.

Table 2 — WCAG 2.1 Level AA

Criterion	Conformance	Remarks and explanations
1.3.4 Orientation	Supports	No orientation lock.
1.3.5 Identify Input Purpose	Supports	Identity fields declare their purpose: `autocomplete="username"`, `current-password`, `name`, `organization`. These had previously been set to `off`, which defeated the criterion.
1.4.3 Contrast (Minimum)	Supports	Text meets 4.5:1 (3:1 for large text) throughout, measured by relative-luminance calculation. One trap worth naming: a caption carrying `opacity:.7` rendered at 2.97:1 even though its declared colour passed — contrast must be measured on what is actually painted, so the fade was removed.
1.4.4 Resize Text	Supports	Text scales to 200% without loss of content or function.
1.4.5 Images of Text	Supports	Text is text. The only image of text is a customer's own uploaded logo.
1.4.10 Reflow	Supports	All ten application screens verified at 320 CSS px with no two-dimensional scrolling. The sidebar and top bar stack below 860 px. Genuinely wide data tables scroll in one direction inside their own container, which the criterion allows.
1.4.11 Non-text Contrast	Supports	Control boundaries, drop zones, the signature canvas outline, meter tracks and the focus indicator all measure at least 3:1 against every surface they appear on. Interactive boundaries use a token separate from the decorative divider colour, so meeting this criterion did not require darkening the entire interface.
1.4.12 Text Spacing	Partially Supports	Content survives the required spacing overrides. Long uploaded filenames truncate at narrow widths; the full name remains available. Improvement scheduled.
1.4.13 Content on Hover or Focus	Supports	The product uses native `title` tooltips, which the criterion exempts. No custom hover popovers.
2.4.5 Multiple Ways	Supports	Full-text search and a navigable directory tree.
2.4.6 Headings and Labels	Partially Supports	Headings and labels are descriptive, and an accessibility-tree walkthrough of the main journeys found no unnamed, glyph-only, vague or duplicated control names. Two wording issues remain, both cosmetic rather than blocking. First, around twenty headings and buttons begin with a decorative emoji, which is spoken before the words that matter. Second, form labels and table headers are capitalised with CSS `text-transform`; the underlying text is normal case, but the browser exposes the transformed string, and some screen readers spell all-capital words out letter by letter. Both are on the list.
2.4.7 Focus Visible	Supports	A 3 px indicator measured at 4.13:1 on the page, 3.99:1 on the dark top bar and 3.81:1 on the sidebar, offset so it is drawn on the background rather than on a control's own fill. Previously the product defined no indicator of its own and inherited the browser default, which measured 1.15:1 on the dark top bar — effectively invisible. All 284 tab stops re-verified.
3.1.2 Language of Parts	Supports	Content is in English throughout.
3.2.3 Consistent Navigation	Supports	Navigation is in the same place and order on every screen.
3.2.4 Consistent Identification	Supports	The same function is named the same way throughout.
3.3.3 Error Suggestion	Partially Supports	Most messages say how to correct the problem. Coverage is not yet uniform across every form.
3.3.4 Error Prevention (Legal, Financial, Data)	Partially Supports	Destructive actions are confirmed, and a snapshot is taken immediately before any reset. Acknowledging a policy — which records a compliance signature — commits on a single click with no confirmation step. Under review.
4.1.3 Status Messages	Supports	The product previously contained no live region at all, which mattered because AI operations can run 60–90 seconds: a non-visual user got silence and no way to tell working from broken. There are now two regions — polite for progress, assertive for failure — plus a live conversation log with speaker attribution, and every outcome container announces. Verified in-browser on every screen.

Table 3 — Revised Section 508 chapters

Provision	Conformance	Remarks
302 Functional Performance Criteria	Partially Supports	302.1 without vision, 302.2 with limited vision and 302.3 without perception of colour are supported for the workflows evaluated, with the two exceptions named above (freehand signing, and uploaded files an agency supplies). 302.4–302.6 (hearing, speech) are not applicable: the product has no audio and requires no speech. 302.7–302.9 (limited manipulation, reach and strength) are supported — everything is keyboard-operable and no action requires simultaneous keys or sustained pressure.
Chapter 4 — Hardware	Not Applicable	AgencyDoc is web software. It supplies no hardware.
501–504 Software	Partially Supports	The product is a web application accessed through the customer's own browser and inherits its platform accessibility features (zoom, high contrast, screen readers). It overrides no platform setting and honours a reduced-motion preference. Conformance follows Tables 1 and 2.
602.2 Accessibility and Compatibility Features (documentation)	Partially Supports	The 132-page user manual documents every feature. It does not yet contain a dedicated accessibility chapter describing keyboard operation and the typed-signature alternative. Scheduled.
602.3 Electronic Support Documentation	Partially Supports	Documentation is supplied as a Word document and PDF. It carries heading structure and is readable with assistive technology, but has not been through a formal tagged-PDF conformance check.
603 Support Services	Supports	Accessibility questions and requests for an alternative format go to the same support channel as any other request, and are answered there. Contact details are on the accessibility statement.

How this was tested

Four methods, because no one of them is sufficient:

Automated rule checking. axe-core 4.13 (wcag2a, wcag2aa, wcag21a, wcag21aa) driven by Playwright over ten screens, signed in so administrative consoles were reachable. Result: zero violations.
Scripted keyboard and assistive-technology measurement in a real browser. Tab order walked stop by stop with the computed focus indicator read at each one; a sweep for controls that respond to a pointer but cannot be reached by keyboard; landmark, heading and page-title inventory per screen; live-region count; and layout measured at 320 CSS px.
Source review against each criterion, covering states an automated pass never reaches — panels that are closed, errors that have not happened yet, and what occurs during a 90-second wait.
Colour measured, not judged. Every colour decision was made with a relative-luminance calculator against the actual surface, and the ratio recorded.

The limit of all of this, stated plainly. Automated testing detects roughly a third of accessibility problems, and the scripted checks above extend that but do not close it. None of it establishes whether a real person using a real screen reader can complete a real task — adopt a policy, file a discipline case, print a manual. A full manual walkthrough with JAWS, NVDA and VoiceOver has not been completed, and this report does not claim otherwise. That work is the next step, and its findings will be published here.

Known gaps, in priority order

Every WCAG 2.1 Level A criterion is now met. What follows is Level AA and documentation work.

Manual assistive-technology walkthrough of the core journeys.
Field-level error association (aria-describedby, aria-invalid) and required-field marking (3.3.1, 3.3.2, 3.3.3).
Confirmation step before acknowledging a policy (3.3.4).
Emoji removed from screen headings (2.4.6).
Tagged-PDF structure for exported manuals, and an accessibility chapter in the user manual (602.2, 602.3).

Contact

If you meet a barrier, or need something in a different format, tell us and we will help — and fix it. Please include the screen you were on and the assistive technology you were using, because that is what makes a problem reproducible. Contact your AgencyDoc administrator, or Public Safety Training and Development directly.