Tell users when PDF form input is invalid
When a PDF form validates input, the error has to come back as text that names the field and describes the problem, not as a beep or a red border. Acrobat form fields validate through format settings or scripts and raise an alert dialog, and the message should say what is wrong and what the field expects. W3C publishes PDF22 as a sufficient technique, and it asks for two things rather than one. The required format has to be stated in the field's label before anyone types, and the error has to be spoken when they get it wrong. A form that only does the second half does not meet the technique. Where a form can produce several errors at once, W3C points to a summary approach instead of a stack of dialogs.
How we find it in an audit
We read the labels first and check whether each validated field says what format it wants. Then we type invalid input with a screen reader running, move off the field, and listen to what comes back, because these fields validate on exit rather than at submission. A spoken alert naming the field and the expected format passes. A color change or a silently cleared field fails, and so does a message that only says the input is invalid.
How affected users experience it
Silent validation is a trap. The user types a date, the field quietly clears or turns red, and the form refuses to submit for reasons never spoken. On tax and benefits forms this ends sessions. The user cannot find which of forty fields is the problem, let alone what format it wants.
Passes vs. fails
Passes
The label reads "Gross income, numbers only, no commas", and typing a comma and tabbing away raises an alert the screen reader speaks. "Gross income. Enter a number without commas, for example 1200.50".
Fails
A tax form rejects "1,200.50" in the income field by turning it red and wiping it. No message, no announcement, and the label never said what format it wanted.
How this gets tested
The W3C publishes test rules that define what a checker looks for here.
- Error message describes invalid form field valueA tool finds candidates, you decide
Other ways to satisfy this rule
13 guides on this site are filed under 3.3.1 Error Identification. W3C lists this one as sufficient for that rule on its own. Implement it correctly, in a way your readers' software actually supports, and the rule is met.
- ARIA18sufficientRaise blocking errors in an alert dialog
- ARIA19sufficientAnnounce form errors with role=alert
- ARIA21sufficientFlag invalid fields with aria-invalid
- G83sufficientTell users which required fields they missed
- G84sufficientExplain when input is not an allowed value
- G85sufficientExplain format errors and show the fix
This guide is our interpretation of W3C technique PDF22: Indicating when user input falls outside the required format or values in PDF forms. W3C publishes its techniques as guidance rather than as the standard, and says so on every one of them. The success criterion is what conformance is measured against, and a technique is one documented way to meet it.