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 → PropertiesGeneralTooltip. 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 failure conditions

Check your own file. Taggart's validator is free and unlimited — no page cap, no watermark, no account.

Check a PDF free

Last updated .