Section 508 · PWS 3.5 · PRS#14
Accessibility conformance report
What was built for accessibility in this prototype, what was checked, and — just as importantly — what has not been evaluated and is therefore not claimed.
Scope of this report
This covers the prototype at this URL, assessed against WCAG 2.1 Level A and AA as incorporated by Section 508 and the HHS ICT accessibility standards. It is an accessibility conformance summary, not an ACR/VPAT. The ACR/VPAT and a remediation plan are contract deliverables due with the beta release (PWS 3.5, Section 8), and issuing one from a prototype would overstate what was tested.
- Supports
- 21
- Partially supports
- 0
- Not evaluated
- 1
- Not applicable
- 1
Criteria
| Criterion | Level | Conformance | Remarks |
|---|---|---|---|
| 1.1.1Non-text Content | A | Supports | The interface is text and form controls. Decorative glyphs (the dialog close ×) are aria-hidden with a visually hidden text label beside them. |
| 1.3.1Info and Relationships | A | Supports | Every control has a programmatically associated label. Radio and checkbox groups are fieldsets with legends. Tables use th with scope. The survey rating scale is a radio group, not styled buttons. |
| 1.3.2Meaningful Sequence | A | Supports | Reading order follows DOM order at every breakpoint; the three-column report layout collapses to a single column without reordering content. |
| 1.3.5Identify Input Purpose | AA | Supports | The reporter's own fields carry HTML autofill tokens — name, email, organization and address-level1 — so a browser or assistive tool can offer stored values. Patient fields deliberately carry none: the patient is often not the reporter, and 1.3.5 is scoped to information about the user. |
| 1.4.3Contrast (Minimum) | AA | Supports | Body text, form labels, error text and button text were checked against their backgrounds at 4.5:1 or better; large headings at 3:1 or better. |
| 1.4.4Resize Text | AA | Supports | Layout is built in relative units and reflows to 200% zoom without loss of content or horizontal scrolling of the page body. |
| 1.4.10Reflow | AA | Supports | Verified at 375×812 and 1280×800. Wide content (the data table, the record tables, the raw JSON) scrolls inside its own container; the page body never scrolls horizontally. |
| 1.4.11Non-text Contrast | AA | Supports | Input borders, focus rings and selected states meet 3:1 against adjacent colours. |
| 2.1.1Keyboard | A | Supports | The whole reporting flow — persona choice, every field, the progress rail, the assistant, upload, review, submit — is operable from the keyboard alone. |
| 2.1.2No Keyboard Trap | A | Supports | The survey dialog traps Tab deliberately while open, which is the required modal behaviour, and releases on Escape or Close with focus restored to the trigger. |
| 2.4.1Bypass Blocks | A | Supports | A skip link to #main is the first focusable element on every page. |
| 2.4.3Focus Order | A | Supports | Step changes move focus to the new step heading rather than leaving it on the pressed button, so a screen-reader user hears where they landed. |
| 2.4.6Headings and Labels | AA | Supports | One h1 per page; section headings describe their content; labels describe their control. |
| 2.4.7Focus Visible | AA | Supports | A visible focus ring is present on every interactive element, including the rating scale, whose real radio input is visually hidden but drives the focus style on its label. |
| 3.1.1Language of Page | A | Supports | lang="en" is set on the document element. |
| 3.2.2On Input | A | Supports | No control causes a change of context on input. Branching changes which questions are shown, on the same step, and the progress rail reflects it. |
| 3.3.1Error Identification | A | Supports | Errors are described in words, listed in an alert at the top of the step with links to the field, and associated with the field through aria-describedby. |
| 3.3.2Labels or Instructions | A | Supports | Every field has a label; help text and tooltips carry the instructions. |
| 3.3.3Error Suggestion | AA | Supports | Validation messages say what to do, not what failed — "the onset date cannot be before the vaccination date" rather than "invalid date". |
| 4.1.2Name, Role, Value | A | Supports | Custom widgets expose their state: the dialog is role=dialog aria-modal, tab lists use aria-selected, the tooltip disclosure uses aria-expanded. |
| 4.1.3Status Messages | AA | Supports | Upload results, filter counts, save confirmations and survey outcomes are in aria-live regions, so they are announced without moving focus. |
| 1.2.xTime-based Media | A | Not applicable | The prototype contains no audio or video. |
| AT testingAssistive technology test matrix | AA | Not evaluated | Formal testing with JAWS, NVDA and VoiceOver against a Government-defined matrix is a contract deliverable (PWS 3.5, 3.7), not a prototype one. It has not been performed. |
Known nonconformities and remediation plan
Assistive technology testing (PWS 3.7)
- Finding:
- No screen-reader or magnifier testing against a Government-defined device and AT matrix has been performed.
- Remediation:
- Run the matrix during the beta cycle and deliver the ACR/VPAT with the findings, per the Section 8 deliverables schedule.
- Target:
- With beta release.
How this was tested
- Keyboard-only traversal of every page and the complete reporting flow on both the public and provider paths, including the branch that suppresses all adverse-event fields.
- Reflow and zoom checks at 375×812 and 1280×800, confirming no horizontal scrolling of the page body at either size.
- Structural review of every interactive component for name, role and value, and of every status message for live-region announcement.
- Contrast checks on text, controls and state colours against their actual backgrounds.
What this does not cover
No testing with real assistive technology has been performed, and no user testing with people with disabilities has been conducted. Both belong to the contract’s test cycle (PWS 3.7) and both are named in the Section 8 deliverable schedule. They are listed above as nonconformities rather than omitted.
The wider accessibility approach — why the form is built the way it is — is described on the About page.