Guide

How to name PDF form fields so readers announce them

A 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.

About 10 minutes · moderate

What a screen reader announces

Tab into a form field with a screen reader running and you hear four things: the accessible name, the type, the state, and any instructions.

The accessible name comes from the field’s tooltip — /TU in the field dictionary. Not the visible label on the page, and not the field’s internal name. If /TU is absent, most readers fall back to the internal name /T, which is usually something like Text1, undefined_3 or fill_12.

A form of thirty such fields is thirty identical announcements. It is not difficult to use — it is impossible.

The three properties that matter

<< /Type /Annot /Subtype /Widget /FT /Tx
   /T  (dateOfBirth)                    % internal name — never announced
   /TU (Date of birth, day slash month slash year)   % accessible name
   /F  4                                % Print flag
>>

/T — the internal name. Must be unique across the form. Never announced. Do not try to make it readable; make it correct for your form logic.

/TU — the tooltip. This is the accessible name. Write it as the question you are asking, and put format guidance in it: “Date of birth, day slash month slash year” is far more useful than “DOB”.

/F 4 — the Print flag. A widget without it is condition 28-008. A form field that disappears on print is a filled form that prints blank.

Setting them in Acrobat Pro

All tools → Prepare a form, then double-click a field:

1. General tab → Tooltip. This is /TU. Write the accessible name here.
2. General tab → Name. This is /T. Leave it alone unless it collides.
3. General tab → Form Field: must not be Hidden.

Work through the tab order at the same time — Prepare a form → More → Set Tab Order → Order Tabs by Structure. Tab order follows the structure tree once you do that, which means fixing the reading order fixes the tab order too, and the two cannot drift apart.

Writing tooltips that work

Ask the question. “What is your full legal name?” beats “Name”. The reader has no visible context to fall back on.

Put the format in the tooltip. “National ID number, nine digits, no dashes”. A reader who fills the field wrongly and gets a validation error has to find the error, understand it, and come back — and validation errors in PDF forms are announced badly by nearly every reader.

Mark required fields in words. PDF has a required flag, and reader support for announcing it is inconsistent. “Email address (required)” costs nothing and works everywhere.

Name the option, not the group, on radios and checkboxes. A radio group’s kids each get their own tooltip: “Standard post”, “Courier”, “Collect in person” — not “Delivery method” three times.

Do not put instructions for the whole form in every field. “Please complete all fields marked with an asterisk” repeated forty times is forty repetitions.

Fields are not enough: the structure

A widget also needs a /Form structure element in the tag tree containing it, with an /OBJR pointing at the annotation. Without it the field works with a mouse and is missing from the document’s structure — the same split described for links.

Acrobat’s Prepare a form does not create these. The Tags panel does:

1. Tags panel menu → Find → Unmarked Annotations → Find.
2. Tag Element for each, type Form.

Then check the order: a field tagged in the wrong place is read in the wrong place, and a form read out of order is worse than a form read badly.

The label association problem

There is no for attribute in a PDF form. Nothing associates the text “Date of birth” printed beside the field with the field itself. A sighted user makes the association visually; a reader has only the tooltip.

This has one practical consequence worth stating plainly: the visible label and the tooltip must say the same thing. If the page says “Surname” and the tooltip says “Last name”, a screen-reader user and a sighted colleague filling the same form are looking at different documents. When someone reads a filled form back over the phone, that difference produces real errors.

Checking a form in five minutes

Put the mouse down. Tab from the top of the form to the bottom and listen — or, without a screen reader, watch the focus ring and read the tooltip that appears.

Three questions per field: Does the announced name tell me what to type? Is the order the order I would fill it in? Does focus ever land somewhere invisible, or skip a field entirely?

The last one catches hidden fields left in by the form designer, which are the single most confusing thing a reader can meet in a PDF form — focus lands somewhere with no announcement and no visible cursor, and there is no way to know what happened.

Related failure conditions

• 28-005 A form field has neither a TU entry nor an alternative description The /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 entry Any page carrying annotations must declare a tab order. PDF/UA-1 requires /Tabs /S — tab order follows the structure tree.
• 28-011 A link annotation is not nested within a Link tag A link annotation must be a child of a Link structure element containing the link's text, joined by an object reference (/OBJR).
• 09-001 Tags are not in logical reading order The order of elements in the structure tree does not match the order a human would read the page. This is the single most common substantive defect in tagged PDFs and the one Acrobat's own tooling handles worst.

Last updated 2026-09-10 .