Taggart
Check a PDF free

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

Form fields outside a Form tag have no reading order

Blocker Checkpoint 28: Annotations WCAG 4.1.2 (A)

Every form control must sit inside a Form structure element.

The condition, as the protocol states it. “A widget annotation is not nested within a <Form> tag.”

Matterhorn Protocol 1.1, checkpoint 28, index 28-010, section UA1:7.18.4-1. Software can decide this one on its own.

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.

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

Acrobat says my form is accessible. Why does a validator disagree?

Acrobat's Accessibility Check tests whether fields have tooltips and whether the tab order is set to structure. It does not test whether each widget sits inside a Form element in the structure tree. A form can pass Acrobat's check with every field outside the tree entirely.

Is the Form tag the same as the form field?

No, and the naming is unhelpful. The field is a form field in the AcroForm dictionary. The widget is its on-page annotation. The Form element is a structure element whose only job is to hold an OBJR pointing at that widget, so the control has a position in the reading order. All three exist for one visible box.

What about a field that appears on several pages?

A single field with several widgets — the same signature block on every page, for instance — needs one Form element per widget, because each widget is at a different place in the reading order. They all reference the same field.

Do I need a Form element for a button?

Yes. Push buttons are widget annotations like any other, and a submit button that a screen reader user meets out of context is exactly the failure this condition is about.

Where this sits in the standards

StandardReference
Matterhorn Protocol 1.1 Checkpoint 28 (Annotations), index 28-010
PDF/UA-1 (ISO 14289-1) Clause 7.18.4-1
WCAG 2.1 4.1.2 Name, Role, Value — 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.

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.

Check your own file. Taggart’s validator is free and unlimited — every machine-checkable Matterhorn condition, no page cap, no watermark, no account needed.

Check a PDF free

Verified against a real document on . Last updated .