The Form Is the Service: Making Public Applications Actually Usable

Almost everything a resident actually needs from a public agency arrives as a form. Renew a licence. Apply for assistance. Register a child for school. Request an accommodation. Appeal a decision. Report a downed line. The homepage is a signpost; the form is the service.

Which is why an inaccessible form is a different order of problem from an inaccessible brochure. A brochure that fails is information someone did not receive. A form that fails is a benefit someone did not get, a deadline someone missed, an appeal that was never filed. And it is the one page type where a single overlooked detail can stop the process completely.

Which requirements actually govern a form?

The standard behind all three of the current regimes — the ADA Title II rule for state and local government, the Section 504 rule for recipients of HHS funding, and Section 508 procurement through 36 CFR Part 1194 — is WCAG. The criteria that decide whether a form works are a small, specific set.

1.3.1 Info and Relationships (A). Every field is programmatically associated with its visible label. Not placed near it — associated with it. Groups of related controls, like a set of radio buttons for a benefit type, are grouped so the question is announced with the options.

3.3.2 Labels or Instructions (A). Fields have labels, and where a format is required, it is stated up front — not revealed only when the submission fails.

3.3.1 Error Identification (A). When something is wrong, the field in error is identified in text. Colour alone does not identify anything.

3.3.3 Error Suggestion (AA). Where you know how to fix it, say so. “Invalid date” is identification. “Enter the date as MM/DD/YYYY” is a suggestion.

3.3.4 Error Prevention (Legal, Financial, Data) (AA). For submissions with legal or financial consequences — most of what an agency collects — the user can review, correct and confirm before committing, or reverse it afterwards.

4.1.2 Name, Role, Value (A). Every control exposes what it is, what it is called, and its current state. This is where custom widgets built out of divs fail hardest.

2.1.1 Keyboard (A) and 2.4.7 Focus Visible (AA). The entire form is operable without a mouse, and you can always see where you are.

2.4.6 Headings and Labels (AA) and 2.5.3 Label in Name (A). Labels describe their purpose, and the accessible name contains the visible text — so someone using voice control can say what they see.

1.4.11 Non-text Contrast (AA). Field borders and focus indicators are visible, not a whisper of grey on white.

WCAG 2.2 adds three that fit forms unusually well: 3.3.7 Redundant Entry (A), which stops you demanding the same information twice in one process; 3.3.8 Accessible Authentication (Minimum) (AA), which prohibits cognitive-function tests such as puzzle CAPTCHAs as the only way through a login; and 2.4.11 Focus Not Obscured (Minimum) (AA), which keeps a focused field from being hidden behind a sticky header or cookie banner. The current rules are written against WCAG 2.1 AA, so 2.2 is not what you are measured against today — but these three describe real barriers residents hit, and we cover the additions in what changed in WCAG 2.2.

The failures we find over and over

Very few forms fail because a team ignored accessibility. They fail on a handful of recurring patterns.

The placeholder-as-label. Grey text inside the box that disappears when typing starts. There is now no label, low contrast while it is there, and nothing to re-read when checking the answer.

The asterisk with no explanation. A red * marks required fields, with the legend either missing or announced as “star”. Mark required fields in the accessible name, not with a symbol and a colour.

The error summary nobody hears. The page reloads, twelve errors are listed at the top in red, and focus stays at the bottom. A screen-reader user hears nothing change. Move focus to the summary, link each item to its field, and put the error count in the page title.

The timeout with no warning. Sessions expire mid-application. Anyone using a screen reader, switch access, or simply reading carefully takes longer — and loses everything. WCAG 2.2.1 requires warning and the ability to extend.

The custom control that is a div. Date pickers, address lookups, file uploaders and multi-selects rebuilt from scratch, with no role, no state, no keyboard support. The native HTML element is nearly always the better engineering decision.

The CAPTCHA at the end. After twenty minutes of work, an image puzzle. This blocks people with visual and cognitive disabilities outright, and for a government service it is often the single hardest barrier on the page.

The PDF escape hatch. The online form is inaccessible, so the page offers “download the PDF instead” — and the PDF is untagged. Two inaccessible routes are not an alternative. If the fallback matters, it has to be remediated too, which is the ground covered in our PDF remediation guide.

What happens when the form is translated?

This is where public-sector forms diverge from commercial ones, and where most guidance stops being useful.

Agencies serving multilingual communities publish the same application in five, ten, sometimes twenty languages. Each translated version is a separate form with its own accessibility state, and several problems appear only in translation:

Labels and error messages are often left in English. The visible text is translated; the aria-label, the validation string, the confirmation message and the required-field indicator are hardcoded in the template. A Spanish-speaking screen-reader user gets a Spanish page read with English announcements interleaved.

The language attribute is not switched. The Vietnamese version still declares lang="en", so a screen reader applies English pronunciation to Vietnamese text and produces nothing usable. That is WCAG 3.1.1, and per-passage switching is 3.1.2.

Text expands. Spanish runs roughly 20–25% longer than English; German longer still. Labels that fit in a fixed-width field in English wrap, truncate, or overlap — and truncated labels are a genuine failure, not a cosmetic one.

Right-to-left forms need restructuring, not mirroring. Arabic, Farsi and Urdu forms need the layout, the field order and the tag tree to agree. We deal with this in Arabic and right-to-left PDF accessibility.

Machine-translated forms fail twice. An auto-translate widget bolted onto an English form usually translates visible text while leaving accessible names untouched — and it does not touch the legal accuracy problem either. For a form with legal consequences, that is not language access. Title VI of the Civil Rights Act requires meaningful access, and a form a resident cannot correctly complete is not meaningful. Our Title VI language access plan post covers how agencies decide which languages they owe.

A test you can run this afternoon

Pick your highest-volume form and complete it — genuinely complete it, through to the confirmation screen — under each of these conditions:

1. Keyboard only. Hands off the mouse. Can you reach every field, see where you are, open every picker, and submit?
2. Deliberately wrong. Submit it with errors. Are they announced, identified in text, and reachable from the summary?
3. Zoomed to 200%. Does anything overlap or disappear?
4. In your busiest non-English version. Are the errors, buttons and required markers in that language too?
5. Slowly. Leave it open for half an hour. Does the session survive, and does it warn you first?

Anything that stops you will stop a resident.

Have a form that has to work? Send us the URL — or the PDF, in every language you publish it in — and request a quote. Tell us how many forms are in scope and which languages they run in, and we will come back with what each one needs to be operable and correctly tagged in every language. Start with our ADA website accessibility page for how we approach the online side.