Accessible PDF forms: AcroForm vs XFA, field names and tooltips, tab order, and what WCAG expects

Forms are where document accessibility becomes a transaction: a person who cannot complete the form cannot get the benefit, the licence, or the appointment. They are also the document type with the most moving parts, because a fillable PDF combines a tag tree, a set of interactive field objects, and page-level navigation settings that all have to agree. This guide starts with the choice of form technology, then works through what each field needs, and ends with the question of whether the form should be a PDF at all.

AcroForm or XFA: the decision that precedes everything

PDF has two form technologies. AcroForm is the form model defined in the PDF specification itself and used by every mainstream tool. XFA, XML Forms Architecture, was an Adobe technology carried inside a PDF wrapper, popular for dynamic government forms in the 2000s. PDFlib's summary of PDF 2.0 states it plainly: "XFA forms are no longer part of PDF 2.0", and adds that the vast majority of PDF software never supported XFA. XFA is also not permitted in PDF/A, so an XFA form cannot be archived under that standard, and browser viewers such as Chrome's and Firefox's either flatten XFA to a static image or refuse to open it. PDF/UA-1 is explicit too: Matterhorn failure condition 25-001 fails any file that "contains the dynamicRender element with value 'required'", which is the definition of a dynamic XFA form. Any organisation still publishing XFA forms should treat migration to AcroForm, or to HTML, as the first accessibility task, because nothing else in this guide can be applied to a form that assistive technology cannot open.

What each field needs

An accessible name

A screen reader reading a field announces its name, role, and value. WCAG technique PDF12 covers name, role, and value for form fields; technique PDF10 covers labels. In practice the name comes from the field's tooltip, stored as the TU entry, so every field needs one that matches the visible label and includes any instruction the label does not carry, such as "Date of birth, DD MM YYYY". Section508.gov's electronic signature guidance says the same for signature fields: "add tooltips that match the label or instruction". Matterhorn condition 11-005 additionally requires that the tooltip's language be determinable, which the document language normally covers.

A place in the structure tree

Each field's widget annotation must be a child of a Form structure element positioned where the field falls in reading order, so that a screen reader in reading mode encounters the field between the right paragraphs. Acrobat's checker reports untagged fields under Tagged annotations, and PDF/UA-1's checkpoint 28 covers annotations in reading order (28-001, "An annotation is not in correct reading order"). Fields added to a PDF after tagging are the usual cause of a form whose fields are announced in a block at the end of the document.

A tab order that follows the structure

Keyboard users move between fields with Tab. WCAG technique PDF3 and Acrobat's Tab order rule both require the order to parallel the document structure; the fix is per page, under Page Properties > Tab Order > Use Document Structure. Section508.gov's guidance for PDF forms adds that they "must be designed to enable keyboard (non-mouse) users, ensure navigation follows a logical tab order, and provide the instructions and cues necessary to complete the form".

Required fields, errors, and submission

• PDF5 describes indicating required form controls, both visibly in the label and in the field's required flag.
• PDF22 covers telling the user when input falls outside the required format or values, so validation messages must be exposed to assistive technology rather than only shown visually.
• PDF15 covers submit buttons with the submit-form action, which matters for forms submitted electronically rather than printed.
• PDF23 covers providing interactive form controls in the first place, as opposed to drawn boxes that cannot be filled. PDF/UA-1 separately requires print-and-fill forms to carry the PrintFields attribute (Matterhorn 24-001).

Radio buttons, checkboxes, and groups

Radio buttons in a group share a field name and differ by export value; a screen reader should announce the group's question and each option's own label. The common defect is a group whose tooltip is the option text ("Yes") with no question, or every option carrying the same tooltip. Give the group a tooltip that states the question and each option a distinct export value, and check with a screen reader that the option labels are announced.

Signature fields

A signature field is a form field and needs the same name and tab position. Section508.gov also addresses the scanned handwritten signature that ends up in many documents: mark the entire signature block as a figure and put all of its text in the alternative text, especially where the signature overlaps document text. How signing platforms handle tags, and why remediation must happen before signing, is covered in e-signatures and accessible PDFs.

Legal scope: forms are never "old documents"

Public bodies sometimes assume an old PDF form is covered by the ADA Title II rule's exception for preexisting documents. It is not. The exception in 28 CFR 35.201(b) excludes conventional electronic documents that were posted before the compliance date "unless such documents are currently used to apply for, gain access to, or participate in the public entity's services, programs, or activities", which describes every live form. The UK regulations have the same carve-out for pre-2018 documents that users need to use a service. See the Title II exceptions for documents.

When the form should be HTML

A fillable PDF is the right choice when the form must be printed, signed by hand, or kept as a fixed record. For a form that most people will complete on a phone, an HTML form is easier to make accessible (native labels, error messages, and focus handling), works in every browser without a PDF viewer, and is easier to change. GOV.UK's guidance for public bodies says to present information as HTML wherever a document can be avoided, and the U.S. federal policy cited by Section508.gov is to prioritise HTML and use PDFs only when necessary. DocAccessible's remediation options page compares hosted HTML with a rebuilt PDF for this decision.

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. PDFlib knowledge base: PDF 2.0 deprecated features . XFA forms are no longer part of PDF 2.0.
2. Datalogics: XFA forms deprecated, what it means and what to do . XFA not permitted in PDF/A; browser and mobile viewer support.
3. W3C WAI: WCAG 2.2 Techniques, PDF techniques PDF3, PDF5, PDF10, PDF12, PDF15, PDF22, PDF23
4. Section508.gov: Electronic Signatures . Tooltips matching labels, logical tab order, keyboard use, and scanned signature blocks as figures.
5. PDF Association: Matterhorn Protocol 1.1 (PDF) . Failure conditions 11-005, 24-001, 25-001, and 28-001.
6. eCFR: 28 CFR 35.201, Exceptions
7. GOV.UK: Understanding accessibility requirements for public sector bodies