Guide
How to make a PDF form accessible
Tooltips, tab order, structure placement and the printed-form case. Forms are transactions, which makes them the highest-consequence documents you own.
About 12 minutes · moderate
Four things, in order
1. Every field needs an accessible name.
Tools → Prepare Form → double-click a field → Properties → General → Tooltip. That is the /TU entry, and it is what a screen reader announces.
Write what the field is, expanded to stand alone. If the visible label is Date under a heading Date of birth, the tooltip is Date of birth — the reader hears it without the heading. The condition →
2. Tab order must follow structure.
In the Fields pane: Options → Order Tabs by Structure. This writes /Tabs /S on each page. Without it, Tab follows the order the fields were created in, which on a two-column form is chaos. The condition →
3. Widgets must be in the structure tree.
Every field belongs inside a <Form> element, in the right place in the reading order. Acrobat’s Accessibility → Reading Order tool will tag an untagged field; getting it into the right position in the tree is a drag in the Tags panel. The condition →
4. Required fields and errors must be announced.
Mark required fields in the field properties, and make sure validation messages are text rather than only a colour change or a beep. A form that signals an error with app.beep() alone tells a deaf user nothing.
The printed-form case
Plenty of “forms” are not forms: they are boxes and rules drawn on the page, meant to be printed and filled in with a pen.
A screen reader encounters an underline and a square with no indication that anything is expected. PDF/UA covers this through /PrintField attributes describing each control, which Acrobat cannot set through its interface at all.
The better answer is almost always to convert it into a real form. Tools → Prepare Form will detect most drawn fields and offer to create widgets, and a form that can be completed on screen is more accessible than one that can only be printed — for a great many people, not only screen reader users.
Where Taggart fits
Taggart reports each field by name and type, so you can work through them without hunting:
Form field
'dateOfBirth'(/Tx) has no /TU tooltip and no /Alt on an enclosing structure element, so it has no accessible name.
Tab order and structure placement are mechanical and ship in “Fix All Safe”. Tooltips need your input — or the useFieldNames option, which derives a first draft by humanising the field name and marks every one it fills as derived from the field name — review the wording, so it never reads as a decision a person made.
Frequently asked questions
Does the visible label count as the field's name?
No. Text printed beside a field is ordinary page content with no connection to the widget. The accessible name comes from /TU on the field, or /Alt on the enclosing structure element. Nothing else is consulted.
What about a printed form with no real fields?
Boxes and rules drawn on the page are not form fields. They need /PrintField attributes describing what each control is, which is condition 24-001 — or, better, convert them into real form fields.
How do I check tab order?
Press Tab through the form and watch where focus goes. If it jumps around the page rather than following the reading order, the page is missing /Tabs /S. In Acrobat: Prepare Form, then in the Fields pane, Options → Order Tabs by Structure.
Related guides
- How to fix PDF reading orderA working method for finding and repairing reading order, free in Acrobat and faster in Taggart, including the two-column case that costs the most time.
- How to name PDF form fields so readers announce themA field with an internal name and no tooltip is announced as Text1. The three properties that matter, and how to set them across a whole form.
- How to make PDF links and annotations accessibleA link annotation is not a link. What has to exist in the structure tree, why bare URLs are hostile, and how to fix a document full of them.
- How to check if a PDF is accessible: four free checkersCheck PDF accessibility free, online or on your own machine: four checkers against PDF/UA and WCAG, what each catches, and the failures none of them see.
Related failure conditions
- 28-005 A form field has neither a TU entry nor an alternative descriptionThe /TU tooltip is the accessible name of a PDF form field. Without it the field has no name at all — the visible label printed next to it is not connected to the control.
- 28-008 A page containing an annotation does not contain a Tabs entryAny page carrying annotations must declare a tab order. PDF/UA-1 requires /Tabs /S — tab order follows the structure tree.
- 28-010 A widget annotation is not nested within a Form tagEvery form control must sit inside a Form structure element.
- 24-001 Non-interactive forms are not tagged with the PrintField attributeA printed form — checkbox squares, signature rules, fill-in lines drawn on the page rather than implemented as widgets — needs /PrintField attributes so a reader can describe the control.
Check your own file. Taggart's validator is free and unlimited — no page cap, no watermark, and no account at all up to 60 pages.
Last updated .