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.
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 detects this condition automatically. It is reported as a blocker, with the page, the structure path and the object id of every occurrence.
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. |
Related conditions
- 28-010 A widget annotation is not nested within a Form tag Every form control must sit inside a Form structure element.
- 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-004 An annotation has neither a Contents entry nor an alternative description Every 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 attribute A 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 order The 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 element Non-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 function A 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 description Every 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.1 A custom annotation subtype still has to be placed in the structure tree and described.
- 28-007 An annotation of subtype TrapNet exists TrapNet annotations are prepress artefacts and are forbidden in PDF/UA-1.
- 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-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 tag Every form control must sit inside a Form structure element.
- 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).
- 28-012 A link annotation does not include an alternate description in its Contents entry Link annotations need /Contents describing where the link goes.
- 28-013 An IsMap entry is true but the functionality is not provided in some other way A 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 dictionary The 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 dictionary Media clips require an /Alt array giving a text description.
- 28-016 File attachment annotations do not conform to 7.11 The file specification referenced by a FileAttachment annotation must carry both /F and /UF.
- 28-017 A PrinterMark annotation is included in the logical structure Crop 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 Artifact The content inside a PrinterMark's appearance stream must itself be artifacted.
Check your own file. Taggart’s validator is free and unlimited — every machine-checkable Matterhorn condition, no page cap, no watermark, no account needed.
Verified against a real document on . Last updated .