PDF Forms Best Practices: AcroForm, XFA, and Accessible Field Design
A poorly designed PDF form frustrates users and breaks accessibility. This guide covers AcroForm vs XFA, field tab order, validation scripts, digital signature fields, and how to make form elements accessible to screen readers — from initial design to final distribution.
PDF forms are everywhere: tax returns, insurance claims, onboarding paperwork, building permit applications, academic enrolment forms. When designed well, a PDF form is a seamless experience — users tab through fields, validate their entries, sign, and submit. When designed poorly, the form is an exercise in frustration: fields that skip the wrong way, validation messages that appear without explanation, and forms that look perfect in Acrobat but break in Preview on Mac.
This guide covers the principles and practical techniques behind well-designed PDF forms — from the choice of form technology (AcroForm vs XFA) through field types, tab order, accessible labelling, validation, and signature fields, to distribution and submission workflows.
AcroForm vs XFA: which technology to use
PDF forms exist in two fundamentally different technologies:
**AcroForm** (introduced in PDF 1.2): The original and universally supported form model. AcroForm fields are PDF objects within the document's interactive forms dictionary. They render natively in all PDF readers that support forms, are supported by the PDF specification, and will continue to work for the foreseeable future.
**XFA** (XML Forms Architecture): An XML-based form engine embedded inside a PDF wrapper. Developed by Adobe's JetForm acquisition and supported in LiveCycle Designer. XFA forms can have dynamic behaviour (showing/hiding fields, calculating values, reflowing layout), but require Adobe Reader/Acrobat to render correctly. Most non-Adobe readers (PDF.js, Preview, Chrome's viewer) cannot render XFA forms — they either show a blank page or display an error message.
**Recommendation**: Use AcroForm for all new forms. XFA was deprecated in PDF 2.0 (ISO 32000-2) and is being phased out. If you need dynamic form behaviour, implement it with AcroForm JavaScript actions or use an HTML form instead.
Field types and when to use them
AcroForm supports the following field types, each defined in ISO 32000:
**Text fields** (/Tx): Single-line or multi-line text input. Use multi-line for addresses, notes, and descriptions. Set maximum length where appropriate to prevent database overflow.
**Checkbox fields** (/Btn with pushbutton=false): Boolean on/off choices. Use for independent options (multiple selections allowed). Do not use for mutually exclusive choices.
**Radio button groups** (/Btn with radio=true): Mutually exclusive choices within a group. All buttons in a group share the same field name; each has a distinct export value.
**Dropdown lists** (/Ch with combo=true) and **list boxes** (/Ch with combo=false): Present a predefined list of options. Dropdowns save space; list boxes allow multiple selection.
**Signature fields** (/Sig): Reserved areas for digital or ink signatures. Should be placed at the end of the form and locked after signing.
**Button fields** (/Btn with pushbutton=true): Trigger JavaScript actions (submit, reset, calculate). Use for form submission and field reset.
Tab order and keyboard navigation
Tab order determines the sequence in which fields receive focus when the user presses Tab. A logical tab order follows the reading order of the document — top to bottom, left to right within each row. Illogical tab order is one of the most common usability failures in PDF forms.
AcroForm tab order is set at the page level via the /Tabs entry in the page dictionary. The options are:
- /R (row order): fields ordered by their vertical position on the page, then horizontal
- /C (column order): fields ordered by horizontal position, then vertical
- /S (structure order): fields ordered according to the document's logical structure tree (best for tagged PDFs)
- Explicit order: specified in the /Kids array of the AcroForm's field tree
In Acrobat Pro, use Forms > Edit Form > Tab Order to manually set the order. For complex multi-column forms, always verify the tab order by tabbing through the form after export.
Field labelling and accessibility
W3C WCAG 2.1 Technique PDF12 requires that form fields have accessible names — labels that a screen reader can announce when the field receives focus. Without an accessible name, a screen reader user hears only "text field" or "checkbox" with no indication of what information is requested.
AcroForm fields support three label mechanisms:
1. **Tooltip** (/TU): The primary accessible name. Appears as a tooltip in visual viewers and is read by screen readers. Always set this.
2. **Partial field name** (/T): The internal name used in JavaScript and data extraction. Should be meaningful (e.g. "firstName", not "field1").
3. **Alternate description** (/Alt): Additional accessibility description.
For fields preceded by visible label text in the document, also ensure the structure elements correctly associate the label with the field using /Label structure elements. Acrobat's accessibility checker verifies label associations.
JavaScript validation and calculation
AcroForm supports JavaScript actions at the field level for validation, formatting, calculation, and keystroke handling. Common uses include:
**Validation**: Reject non-numeric input in number fields, validate email format with a regex, enforce minimum/maximum values. Use the field's Validate action (triggered when the field loses focus).
**Formatting**: Format a telephone number as (555) 555-5555 as the user types. The keystroke action fires on each keypress; the format action fires on blur.
**Calculation**: Auto-populate a total field from quantity × unit price. Calculation order matters — Acrobat evaluates calculations in the tab order by default. For complex calculations, set explicit calculation order in Acrobat Pro.
**Caution**: JavaScript actions in PDFs are a historic attack vector for malware delivery. Many enterprise environments disable PDF JavaScript. Do not rely on JavaScript for security validation — always re-validate data on the server. See the annotation security guide for context on PDF script risks.
Digital signature fields and document locking
Signature fields should be placed at the end of the form and should be the last fields in the tab order. After a document certification signature is applied, any changes to the document invalidate the signature — so the form must be completely filled before signing.
For forms requiring multiple signatories, use separate signature fields for each signer. Define signature field lock dictionaries to specify which fields can be filled after each signature is applied, allowing sequential signing without signature invalidation.
For forms distributed to users without Acrobat Pro, consider enabling "Extended Document Rights" (Reader Extensions) so that Adobe Reader users can save a filled copy — without this, Reader users can fill but not save the form. This requires a commercial Adobe licence for widespread distribution.
A well-designed PDF form is invisible to the user — they move through it naturally, receive clear validation feedback, and complete it without confusion. Achieving this requires deliberate choices at every stage: field type selection, logical tab order, accessible labels, validation scripts, and correct signature field configuration.
Use our PDF form filling tool to fill and download AcroForm PDFs directly in the browser. For adding new fields to an existing PDF, our editor supports form field placement.
Frequently asked questions
Why does my PDF form look correct in Acrobat but broken in Chrome or Preview?
If the form was created with XFA (Adobe LiveCycle Designer), it will only render correctly in Adobe Acrobat/Reader. Chrome's PDFium viewer and macOS Preview do not support XFA. Convert the form to AcroForm using Acrobat Pro (Forms > More Form Options > Convert Existing Form) or recreate the form from scratch in Acrobat Pro's form editor. For a free conversion option, some third-party PDF services can flatten XFA to a static PDF, though this loses interactivity.
Can users fill a PDF form without Adobe Acrobat?
Yes, if the form uses AcroForm (not XFA). AcroForm fields can be filled in Chrome's built-in viewer, Firefox (via PDF.js), macOS Preview, and many third-party PDF readers. However, saving the filled form requires a reader that supports saving form data — Chrome and Firefox allow "Print to PDF" as a workaround. For forms requiring saving, either distribute as AcroForm with Reader Extensions enabled (requires Adobe licence) or use a server-side form submission approach.
How do I make a PDF form field required?
In AcroForm, the "Required" flag is set on the field (the /Ff field flags bit 2 = required). In Acrobat Pro, right-click the field > Properties > General tab > check "Required". Required fields display with a red border in Acrobat. Note that enforcement of the required flag is client-side only — it prevents Acrobat's built-in Submit action from submitting until the field is filled, but a user can still save the PDF unfilled. For enforced required fields, add a JavaScript validation action that checks the field is non-empty on blur.
How do I flatten a PDF form after filling?
Flattening converts interactive form fields into static page content — the filled values become part of the page and can no longer be edited. In Acrobat Pro: File > Print > Print to PDF (this method flattens during the print operation). Programmatically: pdf-lib can flatten fields by iterating the field widgets and drawing their appearance streams as page content, then removing the AcroForm dictionary. qpdf with --flatten-annotations=screen also works. Our form fill tool includes a flatten option on download.
Can I add form fields to an existing PDF without Acrobat Pro?
Yes — several free tools support adding AcroForm fields to an existing PDF. Our browser-based PDF editor supports form field placement. LibreOffice Writer can open and edit PDF forms on some PDF types. Programmatically, pdf-lib (JavaScript) supports adding text fields, checkboxes, radio buttons, dropdowns, and signature fields to any PDF. Python's reportlab and pypdf libraries offer similar functionality.
Try it yourself
Everything in this article can be done directly in the free PDFTheGuide editor — no account required.