Matterhorn 28-010 · PDF/UA-1 UA1:7.18.4-1

Form fields outside a Form tag have no reading order

Every form control must sit inside a Form structure element.

What a screen reader actually does

The control has no place in the reading order, so it is announced out of context or missed.

What is in the file

A form control in a PDF is three objects that must all agree.

The field, in the document’s /AcroForm /Fields array. It has the name, the value, the type, and the /TU tooltip that is what a screen reader actually announces.

The widget annotation, in the page’s /Annots. It has the rectangle, the appearance streams, the border and background.

The Form structure element, in the structure tree, containing an OBJR that points at the widget:

/Document
├── /P     "Name of applicant"
├── /Form
│   └── /OBJR → 31 0 R        ← the widget
├── /P     "Date of birth"
└── /Form
    └── /OBJR → 32 0 R

This condition fires when the widget exists and that third object does not — or exists but is not a Form.

What the user hears

The widget still exists, so the control is still reachable by Tab. What it has lost is its place.

In a correctly structured form the reader moves through the document in structure order and meets each control immediately after the text that labels it: “Name of applicant, edit, blank”. With no Form element the control is not in that sequence. Depending on the reader and the page’s /Tabs setting, the user gets one of:

• Every field at the end. The document is read as continuous prose — every label, every instruction, every heading — and then a run of unlabelled controls with nothing between them.
• Fields in annotation order, which is creation order, which is the order the form designer happened to draw the boxes in. On a two-column form this interleaves the columns.
• Nothing. Some configurations skip unstructured widgets when reading the document, and the user finds the controls only by tabbing, with no way to know what any of them is for beyond the tooltip.

The tooltip is doing all the work in every one of those cases, which is why forms with good /TU values and no structure feel nearly usable and are exhausting to complete.

Where it comes from

Fields added after tagging. The normal production order — lay out the document, export the PDF, tag it, then add form fields in Acrobat — produces this condition every time. Acrobat’s Prepare Form creates widgets and does not create structure elements for them.

Auto-detected fields. Prepare Form’s field detection finds boxes and lines and creates widgets from them. It never touches the structure tree.

LiveCycle and XFA-derived forms flattened to AcroForm.

Word and InDesign do not produce interactive form fields at all, so every form field in a PDF from either was added downstream.

How to check it free

Acrobat Pro, Tags panel. Select a field on the page with the Select Object tool, then in the Tags panel use Find Tag from Selection. If nothing is selected in the tree, the widget is not in it.

Order panel. View → Show/Hide → Navigation Panes → Order. Correctly structured fields appear in the order list. Unstructured widgets do not appear at all, which makes this the fastest visual check on a long form.

veraPDF reports it against clause 7.18.4 and lists each widget.

How to fix it free, in Acrobat Pro

Per field, and there is no batch route in the interface:

1. Open the Tags panel and the Content panel side by side.
2. In the Tags panel, select the element after which the control should be read — usually the P holding its label.
3. Options → New Tag → type Form.
4. Select the widget on the page with the Select Object tool.
5. Tags panel → Options → Create Tag from Selection, or drag the annotation’s entry from the Content panel into the new Form element.

Then set the tab order to follow structure: Page Thumbnails panel → select all pages → right-click → Page Properties → Tab Order → Use Document Structure. Without that step the structure is correct and the tab order still ignores it, which is condition 28-009.

On a thirty-field form this is thirty repetitions of a five-step process, and it is why forms are the most expensive documents to remediate by hand.

Where Taggart differs

annotation-structure is a safe fix. Creating a Form element around an existing widget adds a structure element and an object reference; it changes no appearance, no field value, no page content. The appearance gate confirms the rendering is identical, and Taggart runs it in the batch.

The part that needs judgement is where in the reading order each control goes, and that is what Taggart computes rather than guesses. For each unstructured widget it finds the text whose baseline and column position place it immediately before the widget’s rectangle — the label, in almost every real form — and inserts the Form element directly after that element’s position in the tree. Right-to-left forms are handled by the same code that handles right-to-left reading order generally, so a Hebrew form’s labels sit to the right of their fields and the order still comes out correct.

Where no label can be located — a bare box in a table cell, a checkbox in a grid — Taggart says so per field rather than placing it somewhere plausible, and the remediation report lists which controls were placed automatically and which were positioned by a person.

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 Place annotations in the structure tree. It is mechanical, so “Fix All Safe” applies it in bulk with a diff and a single undo.

Where this sits in the standards

Related conditions

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

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

Verified against a real document on 2026-09-12 . Last updated 2026-09-12 .