Test the PDF form as a completed task, not a page of empty boxes

Inventory the controls and the information each must expose

List every intended field, its visible label, control type, allowed value and relevant required or read-only state. Distinguish separate choices from mutually exclusive choices and instructions from actual controls. Ask the designer to explain what the user should understand before entering a value rather than relying on the visual proximity of a label.

W3C’s PDF12 technique addresses programmatically available name, role, value and state. Its Acrobat example distinguishes the accessible name provided through the Tooltip property from the internal field Name, with a separate treatment for pushbuttons. That specific distinction makes a practical test essential: an internal identifier that looks correct to the author may not be the name announced to the reader.

Complete the form through the intended interaction paths

Use keyboard navigation and an appropriate assistive-technology check to complete a realistic task with synthetic data. Confirm that each field is identifiable in context, can receive the intended input and announces meaningful changes. Test moving backward as well as forward. Do not accept a tab sequence that jumps past an essential instruction or forces a reader to search visually for the current control.

Exercise the choices themselves. Can a single-choice group be changed, and does selecting one option leave an impossible combination elsewhere? Can a multiline response be reviewed without losing content beyond the visible area? Try values near the supported limits and verify the stated validation behavior. A required marker on the page should correspond to the actual workflow, not create a false assurance that every reader enforces the same rule.

Check independent fields, persistence and receiving output

Enter different invented values into fields that were copied during production. Check that an edit in one does not unexpectedly populate another because an internal identity was reused. Where mirroring is intentional, confirm that it is clearly understood. Then save a copy, close it and reopen it in the supported environment to establish what actually persists.

Inspect the completed artifact or approved test export as the receiving team would. A field value can be present in the file while appearing incorrectly in a preview or printed workflow. Document the supported reader and version combinations rather than claiming identical behavior in every browser viewer. If a required feature is unsupported, provide a clear approved route instead of asking readers to disable security protections or inventing a workaround with private data.

Keep submission and release boundaries explicit

If the form has a submit control, test it only through an approved non-production endpoint or another safe method chosen by the technical owner. Verify the destination, the data included and the difference between preparing a message and actually sending it. A successful button click is not proof of receipt. Do not use real applicant, customer or account details as convenient test material.

Keep the accepted source, final PDF and test record connected. Recheck copied controls, changed instructions and export transformations before replacing the live form. Make unresolved limitations visible to the publication owner and provide a usable alternative where needed. The release decision should describe a completed task that was tested, including saved and received output, rather than a green checklist based only on empty-field appearance.

Make the reasoning concrete.

A fictional conference publishes a fillable planning worksheet. Two copied text fields share an internal identity, so entering a company name also fills the dietary-notes field. The visible labels are different, and the author checked only the blank layout.

The producer fixes the unintended field coupling and retests the supported reader paths. No real attendee information is used, and no production submission is sent as part of the demonstration.

Take the questions into your next brief.

Use these prompts in your own notes. Nothing is submitted from this page.

1. Semantics

   What name, role, value and state does each control expose?

2. Navigation

   Can the complete task be performed through the intended keyboard path?

3. Identity

   Which fields are independent and which intentionally mirror?

4. Persistence

   What survives saving, reopening and the receiving workflow?

5. Delivery

   How will the destination be tested without sending real information?

Watch for the wrong conclusion.

• Confusing an internal field identifier with the accessible name.
• Approving copied controls without entering different test values.
• Treating a submit-button click as confirmed delivery.

Sources & scope

Workflows, worksheets and fictional examples are original editorial analysis. W3C techniques support the specifically attributed accessibility principles and are not a complete conformance assessment. No measured result, certification or named human reviewer is claimed.

• W3C WAI: PDF12, Providing name, role, value information for form fields in PDF documents →Primary accessibility technique guidance · Supports: Programmatic field semantics and the Acrobat-specific difference between Tooltip, internal Name and button-label treatment. The completion, persistence and safe-delivery tests are original editorial analysis.