PDF form validation: required fields, errors, and recovery

Test PDF form validation by deliberately leaving required fields empty, entering invalid values, and correcting the resulting errors with a keyboard. A form that works only when every answer is perfect has not been adequately reviewed. Readers need to know what is required, understand what went wrong, locate the relevant control, and continue without losing valid information.

Define the completion contract before writing rules

Use a fictional event registration form with a name, email address, session choice, and optional access requirements. Document which fields are necessary and why. Avoid making a field required merely because it exists in a template. State any format expectation next to the relevant control, and make the instructions understandable without relying on color or an unexplained symbol.

Separate collection from delivery. A PDF may be saved and uploaded elsewhere, emailed through an approved process, printed, or submitted through a supported action. State the intended route and test it. A button labeled 'Submit' is misleading if the expected viewer cannot perform its action or if the user receives no useful indication of the outcome.

Check required state and accessible names

W3C technique PDF5 explains identifying required controls in PDF forms and the underlying field flags used by authoring tools. A visible asterisk alone does not demonstrate that the required state is exposed appropriately. Review the visible instruction and the programmatic field properties together.

W3C technique PDF12 distinguishes the accessible name from an editor's internal field name. In Acrobat's documented text-field workflow, the Tooltip value supplies the accessible name through TU; the internal T name is a different property. Inspect what the reader actually hears rather than judging a field by its convenient developer identifier.

For the event example, 'Email address, required' is useful context, while 'Text3' is not. Keep the accessible name consistent with the visible label. Test radio groups and checkboxes separately, including whether the user can identify the choice and its current state. Do not assume that a readable text field proves every control type is usable.

Make errors specific and correctable

W3C technique PDF22 addresses input outside a required format or value and describes textual error notification. The reader should be able to identify the error and correct it. Focus movement needs care: after an alert, the next keyboard action should be understandable rather than unexpectedly moving to an unrelated part of the form.

Validate only constraints the process genuinely needs. Overly narrow rules can reject legitimate names or addresses. Keep examples illustrative rather than turning them into the only accepted values. Where validation occurs in another system after upload, distinguish that later response from the PDF's own checks and review the full correction journey.

Test the difficult states in the intended viewer

1. Complete the form using a keyboard, checking labels, states, instructions, and focus order.
2. Trigger each required and format rule separately, then try more than one error together.
3. Read the error, return to the relevant control, correct it, and retry the completion action.
4. Save and reopen the form through the supported workflow to check the values that should persist.
5. Repeat the essential tasks in each supported viewer and record unsupported scripting or submission behavior.

Use synthetic details in tests and a controlled destination for submissions. Do not send test applications into a live processing queue. Record viewer and assistive-technology versions, the exact PDF revision, and the expected outcome of each case. A visual red border is not sufficient evidence that an error was announced or that recovery worked.

Provide a usable route when the PDF cannot support the task

If a necessary interaction is unreliable in the distribution environment, evaluate an accessible web form or another supported completion route. Explain the option before a reader invests time filling the PDF. Keep the data requirements and instructions consistent across routes, and test the alternative rather than assuming that changing format resolves every issue.

Use the AcroForm and XFA guide to understand format differences, the screen-reader guide for repeatable review, and the embedded-viewer guide when the form appears inside a web page.

Frequently asked questions

Sources

The statements above rest on the primary sources below. Where a source is a law or standard, the version and date named in the text are the ones checked on the review date. This guide is general information, not legal advice.

1. W3C PDF5: Required form controls
2. W3C PDF12: Name, role, and value
3. W3C PDF22: Input format and value errors