Matterhorn 28-005 · PDF/UA-1 UA1:7.18.1-4
PDF form field with no accessible name (missing TU)
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.
The condition, as the protocol states it. “A form field does not have a TU entry and does not have an alternative description (in the form of an Alt entry in the enclosing structure element).”
Matterhorn Protocol 1.1, checkpoint 28, index 28-005, section UA1:7.18.1-4. Software can decide this one on its own.
How PAC and Acrobat report it
If you came here from another checker's report, these are its lines for this condition.
- PAC 2024, PDF/UA › Alternative text: “Form field has TU key”
- PAC 2024, detailed results: “Alternate field name entry missing in form field”
- Acrobat Accessibility Checker, Forms: “Field descriptions”
What a screen reader actually does
The reader announces "edit text, blank" with no indication of what to type.
What is in the file
A form field is an annotation of subtype /Widget, and its accessible name is the /TU entry — “tool tip”, though nothing about it is optional decoration:
17 0 obj
<< /Type /Annot
/Subtype /Widget
/FT /Tx
/T (dateOfBirth) % technical field name — not an accessible name
/TU (Date of birth) % accessible name — this is what is announced
/Rect [ 200 685 450 705 ]
/F 4
/P 3 0 R
>>
endobjPDF/UA-1 clause 7.18.1 accepts either /TU on the field or /Alt on the structure element that encloses it. In practice /TU is the one to use: it is what every reader looks at first, it is what Acrobat’s own UI edits, and it survives round-tripping through form tools.
Condition 28-005 fires when neither is present.
What the user hears
Nothing useful. NVDA in forms mode announces the role and the value:
edit, blank
JAWS may fall back to the /T name, which is how users end up hearing:
txt_dob_1 edit
The visible word Date of birth printed two centimetres to the left is not part of that announcement and never will be, because nothing in the file relates the two.
The consequence is not inconvenience. A form is a transaction. A field whose purpose cannot be determined is a transaction the user cannot complete, and on a government form that is often the entire point of the document.
How to fix it free, in Acrobat Pro
Tools → Prepare Form. Acrobat lists every field.- Double-click a field → Properties → General tab.
- Type into Tooltip. That is the
/TUentry. - Repeat for every field. Tab moves between fields on the page, and the Properties dialog stays open if you tick Locked off and use the Fields pane — that is the fastest way through a long form.
- While you are there, check the Tab Order: in the Fields pane,
Options → Order Tabs by Structure. That fixes conditions 28-008 and 28-009 at the same time.
Acrobat’s Accessibility → Form Field Properties wizard walks you through the fields one at a time and is less clicking, though it skips fields not already in the tag tree.
The upstream route works too: in Word, a content control’s Title exports as /TU. In LiveCycle or an XFA-based workflow the field’s tooltip property maps to the same place.
The related failures that travel with it
A form that is missing tooltips almost always has three other things wrong, and fixing only the tooltips leaves it unusable:
- 28-010 — the widget is not inside a
<Form>structure element, so it has no position in the reading order. The reader announces it somewhere arbitrary, or not at all. - 28-008 / 28-009 — the page has no
/Tabs /S, so Tab moves through fields in the order they were created rather than the order they are read. On a two-column form this is chaos. - 24-001 — parts of the “form” are printed rules and boxes rather than real fields, and carry no
/PrintFieldattributes at all.
Where Taggart differs
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.
The fix requires your input, because the tool cannot know what a field means. Supply the tooltips and Taggart writes them. There is also a useFieldNames option that derives a first draft by humanising the /T name — dateOfBirth becomes Date of birth — and every field it fills that way is flagged in the change log as derived from the field name — review the wording, so it never looks like a decision a person made.
Tab order and structure placement are mechanical and land in “Fix All Safe”: Taggart sets /Tabs /S on every page carrying annotations and wraps orphaned widgets in <Form> elements, noting in the report that the new elements are appended at the end of the tree and need placing in the reading-order editor.
How Taggart handles it
Taggart checks for this condition automatically and reports it as a blocker, with where in the file it found it.
The fix is Add form field tooltips. It changes what the document means, so Taggart proposes it and waits for your approval rather than applying it unattended.
Whatever Taggart changes, the page still looks identical. Fixes edit the PDF object model, not the content streams, and every remediation is re-rendered and compared against the original at structural similarity ≥ 0.999 before you get the file back. A tool that quietly reflows your document is worse than no tool.
Frequently asked questions
Isn't the visible label enough?
No. The text printed beside a field is ordinary page content. Nothing in the file connects it to the widget. A screen reader in forms mode reads the field's own accessible name, which comes from /TU — or, failing that, from /Alt on the enclosing structure element. Text sitting nearby is not consulted.
What about the field name in /T?
/T is the field's technical name — the key your form data comes back under. Some readers fall back to it, which is why users hear 'txt_dob_1 edit'. It is not an accessible name and PDF/UA does not accept it as one.
What should the tooltip say?
What the visible label says, expanded to stand alone. If the label is 'Date' under a heading 'Date of birth', the tooltip should be 'Date of birth'. If the field is one of several in a row — day, month, year — each needs its own: 'Date of birth, day'. The reader hears the tooltip out of context, so it has to carry the context.
Do radio buttons and checkboxes need one each?
Each widget needs a name that identifies the choice, and the group needs a name that identifies the question. In practice: set /TU on each kid to the option text, and make the group's purpose clear through the enclosing structure. A set of radio buttons all tooltipped 'Choose one' is no better than none.
Where this sits in the standards
| Standard | Reference |
|---|---|
| Matterhorn Protocol 1.1 | Checkpoint 28 (Annotations), index 28-005 |
| PDF/UA-1 (ISO 14289-1) | Clause 7.18.1-4 |
| WCAG 2.1 | 4.1.2 Name, Role, Value — Level A |
| WCAG 2.1 | 3.3.2 Labels or Instructions — Level A |
| EN 301 549 / Section 508 / ADA Title II | All three point at WCAG 2.1 Level AA for non-web documents, so a Level A or AA criterion here is in scope for each of them. |
Guides that cover it
- How to make a PDF form accessibleTooltips, tab order, structure placement and the printed-form case. Forms are transactions, which makes them the highest-consequence documents you own.
- 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 get PDF headings and bookmarks rightHeading levels are how a screen-reader user navigates a long document. Skipped levels, fake headings and empty bookmarks, and how to fix each.
Related conditions
- 28-010 A widget annotation is not nested within a Form tagEvery form control must sit inside a Form structure element.
- 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-004 An annotation has neither a Contents entry nor an alternative descriptionEvery non-widget annotation needs an accessible description, either in its own /Contents or in the /Alt of the structure element that encloses it.
- 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.
Other conditions in checkpoint 28
Checkpoint 28 covers annotations. These are its other failure conditions; the ones without a link are in the rule set but do not have a written page yet.
- 28-001 An annotation is not in correct reading orderThe annotation's position in the structure tree does not match where it appears on the page.
- 28-002 An annotation is not a direct child of an Annot structure elementNon-widget, non-link annotations must sit inside an Annot structure element so they have a place in the reading order.
- 28-003 An annotation is used for visual formatting but is not tagged according to its semantic functionA Square or Line annotation used to draw a box round a callout is decoration and should be artifacted, or tagged for what it actually means.
- 28-004 An annotation has neither a Contents entry nor an alternative descriptionEvery non-widget annotation needs an accessible description, either in its own /Contents or in the /Alt of the structure element that encloses it.
- 28-006 An annotation with subtype undefined in ISO 32000 does not meet 7.18.1A custom annotation subtype still has to be placed in the structure tree and described.
- 28-007 An annotation of subtype TrapNet existsTrapNet annotations are prepress artefacts and are forbidden in PDF/UA-1.
- 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-009 A page containing an annotation has a Tabs entry with a value other than S/Tabs is present but set to /R (row order) or /C (column order) rather than /S (structure order).
- 28-010 A widget annotation is not nested within a Form tagEvery form control must sit inside a Form structure element.
- 28-011 A link annotation is not nested within a Link tagA link annotation must be a child of a Link structure element containing the link's text, joined by an object reference (/OBJR).
- 28-012 A link annotation does not include an alternate description in its Contents entryLink annotations need /Contents describing where the link goes.
- 28-013 An IsMap entry is true but the functionality is not provided in some other wayA server-side image map requires pointing at a pixel, which is not possible without a mouse.
- 28-014 CT entry is missing from the media clip data dictionaryThe media clip's content type (/CT) is required so a processor knows what it is being asked to play.
- 28-015 Alt entry is missing from the media clip data dictionaryMedia clips require an /Alt array giving a text description.
- 28-016 File attachment annotations do not conform to 7.11The file specification referenced by a FileAttachment annotation must carry both /F and /UF.
- 28-017 A PrinterMark annotation is included in the logical structureCrop marks and registration targets are production artefacts and must not appear in the structure tree.
- 28-018 The appearance stream of a PrinterMark annotation is not marked as ArtifactThe content inside a PrinterMark's appearance stream must itself be artifacted.
Check your own file. Taggart’s validator is free and unlimited — 75 of the 87 Matterhorn conditions software can decide, with the other 12 listed for you to confirm; no watermark, no expiry, and no account needed up to 60 pages.
Verified against a real document on . Last updated .