Accessible PDF forms: field labels, tab order, tags and XFA

An accessible fillable PDF form lets someone find, understand and complete every field using only a keyboard or a screen reader. Each field needs a name the screen reader announces (in Acrobat, the field's Tooltip, stored in the PDF as its TU entry), a tab order that follows the form's structure, and a Form tag in the tag tree. The form also needs visible labels and instructions, required fields marked in words, and error messages that say how to fix the problem. Dynamic XFA forms can't meet PDF/UA, so rebuild them as standard forms.

Why forms come first

Forms are how people apply for permits, register for programs, request records and enroll in classes. If a form doesn't work with assistive technology, someone may not be able to get a service at all.

Forms also matter under the ADA Title II rule. The preexisting documents exception doesn't cover documents that are currently used to apply for or access a service, so a form people still use needs to be accessible no matter when it was posted. See Title II exceptions explained (general information, not legal advice).

What an accessible PDF form needs

Write good field names

The tooltip is the field's accessible name: it's what a screen reader says when someone tabs into the field. When it's missing, some screen readers read out the internal field name, so people hear something like "Text 14, edit".

• Match the visible label, so sighted and screen reader users are talking about the same thing.
• Add what people need to know: the format and whether it's required. For example, "Date of birth (MM/DD/YYYY), required".
• Name every field, including checkboxes, dropdowns, signature fields and buttons.
• Radio buttons and checkboxes need both the question and the option. In Acrobat, radio buttons in a group share one field name. Put the question in the tooltip and set each button's choice to the option's label. Then test with a screen reader, because announcements vary.

Make a fillable form accessible in Acrobat Pro

Required fields, instructions and error messages

• Mark required fields in words, such as "(required)", in the visible label and in the tooltip. Also check Required in the field properties, so software knows too. Don't rely on color or an asterisk alone.
• Put instructions before the fields they apply to, not at the end. Start with what people will need (an account number, a photo ID) and how to submit or get help.
• Give format hints in the label, such as "Phone number (10 digits)".
• Write specific error messages. Acrobat can alert people when an entry doesn't match the format you set. Say what's wrong and how to fix it: "Enter the date as MM/DD/YYYY", not "Invalid entry". Not every PDF reader runs form scripts, so the label and tooltip should give the format as well.

Form tags and widget annotations

Each field's clickable box on the page is called a widget annotation. For PDF/UA, every widget must be inside a Form tag in the tag tree, linked to the field, and placed in reading order next to its label. Every page that has fields or links must also tell readers to tab through them in structure order.

These are the requirements behind some of the most common checker messages:

• PAC's widget annotations in Form tag means fields are missing from the tag tree.
• Acrobat's tagged form fields and Field descriptions rules check tagging and tooltips.
• Acrobat's tab order rule checks the page setting.

The XFA warning

Some government forms were built as dynamic XFA forms, an older Adobe format created in tools such as Adobe LiveCycle Designer. They can grow and change layout as you fill them in, which is why they were popular. But:

• PDF/UA doesn't allow dynamic XFA forms, and the format was deprecated in PDF 2.0.
• Many PDF readers can't open them. Browser viewers, phone apps and Mac Preview often show only a "please wait" message instead of the form.
• Assistive technology support is poor, even where they open.

If you have XFA forms, plan to rebuild them as standard PDF forms (sometimes called AcroForms), or replace them with accessible web forms. There's no reliable one-click conversion for dynamic XFA.

Consider a web form

For forms people submit online, an accessible web form is often easier for everyone: it works on phones, supports autofill, can check entries as people go, and doesn't need a download. A PDF form still makes sense when people need to print, sign or mail it. Either way, the form must be accessible.

Test your form

Fix it automatically

Includoc tags every form field in reading order and sets each page's tab order to follow the structure. It writes a name for each field from the printed label next to it, and you confirm those names on the review screen. It flags dynamic XFA forms, which it can't fix, and fields whose instructions a person should check. It doesn't create new fields on flat or scanned forms, so add those in Acrobat first. For high-stakes forms such as applications, our human-verified tier tests each form with a screen reader.

Standards

Sources

• W3C: PDF10: Providing labels for interactive form controls in PDF documents (opens another website)
• W3C: PDF12: Providing name, role, value information for form fields in PDF documents (opens another website)
• W3C: PDF5: Indicating required form controls in PDF forms (opens another website)
• W3C: PDF22: Indicating when user input falls outside the required format or values in PDF forms (opens another website)
• W3C: PDF3: Ensuring correct tab and reading order in PDF documents (opens another website)
• W3C: Understanding 3.3.2 Labels or Instructions (opens another website) and Understanding 4.1.2 Name, Role, Value (opens another website)
• ISO: ISO 14289-1:2014, PDF/UA-1 (opens another website)
• Adobe: Change form field settings (opens another website), Field properties for form components (opens another website) and Set form field navigation (opens another website)