Accessibility
A payment nobody can complete isn't a payment channel
Government has a higher obligation here than most sectors, and the population paying a water bill or a citation is the whole population. Accessibility is a design requirement in our payment experiences, not a remediation project.
What we design and test against
Keyboard operable end to end
Every step of a payment — search, selection, form entry, confirmation — is completable without a mouse, with a visible focus indicator at all times.
Screen reader structure
Semantic headings, labelled form controls, described errors, and landmark regions so assistive technology can navigate the page rather than read it linearly.
Contrast that survives sunlight
Text and interface controls meet WCAG 2.2 AA contrast requirements — which matters as much on a phone at a counter as it does for low-vision users.
Error recovery, not error messages
Validation explains what is wrong and how to fix it, is announced to assistive technology, and never discards what the payer already entered.
No motion requirement
Animation is decorative and respects the operating system's reduced-motion preference. Nothing essential is conveyed by movement alone.
Multiple ways to pay
Accessibility is also channel choice. A resident who cannot use a web form can pay through the bilingual IVR line, at a counter, or with help from our support team.
What this looks like on a payment page
Standards are abstract. These are the specific decisions that follow from them.
- Every form field has a persistent visible label, not a disappearing placeholder
- Required fields are marked in text as well as by color
- Fee disclosure is text, readable by a screen reader, not an image
- Session timeouts warn before they expire and can be extended
- Receipts are available as accessible text, not only as a PDF
- Search results are announced, including when there are none
- Interactive targets are large enough for imprecise pointing
- The page works at 200% zoom without horizontal scrolling
Read our accessibility statement.
What we won't claim
Accessibility is a continuous obligation, not a certificate. Any vendor telling you their product is permanently and completely compliant is describing an aspiration.
Our position
We design and build against WCAG 2.2 AA and include accessibility testing in design, development and QA. Where an issue is found, we treat it as a defect and fix it.
If your jurisdiction has a specific conformance requirement, an accessibility policy or a procurement standard we need to meet, bring it to the requirements session. It shapes configuration decisions and it is far cheaper to accommodate before launch than after.
If you encounter a barrier on a Government Window payment page, tell us — that report is the most useful accessibility input we receive.