Matterhorn 24-001 · PDF/UA-1 UA1:7.14-1

Printed forms whose blanks carry no 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.

What a screen reader actually does

The reader announces a bare underline or an empty square with no indication that it is a field to fill in.

What the condition is about

A printed form is a page of prompts and blanks: Name: followed by a line, Date of birth: followed by eight little boxes, a row of squares to tick. On screen, an interactive form puts a field over each blank, and the field’s type and tooltip tell a reader what it is. A form meant for paper has no fields, so the information has to go somewhere else.

ISO 32000-1 provides that place: the PrintField attribute owner, used on a Form structure element that wraps the blank’s content:

/Form
  /A << /O /PrintField
        /Role /tv                         % a text-value field
        /Desc (Applicant's full name) >>
  /K [ 14 ]                               % the drawn line, or the underscores

Role takes rb, cb, pb or tv — radio button, check box, push button, text value. Desc is the field’s name. Matterhorn 24-001 is a non-interactive form with none of this.

What the user hears

The prompts, read as a run of short paragraphs — Name, Address, Date, Signature — and after each one, whatever its blank is made of.

If the line is typed underscores, a reader either skips it or reads it character by character, depending on its punctuation setting. If the line is drawn, there is nothing to read at all. Either way nothing says “text field”, and a row of tick boxes drawn as squares is silent. The listener gets a list of labels and has to infer that each one is a question.

Where it comes from

Word documents with typed blanks, exported to PDF. Name: ______________ is how a great many forms are made, and the export tags it as a paragraph containing underscores.

Layout applications where the blanks are drawn as rules and frames. The prompts are text and get tagged as text; the rules are graphics, and nothing about a graphic says it is a blank.

Scanned paper forms with OCR, where the blanks are part of the image and the prompts become text.

How to check it free

Look. This is a judgement, and the first question is the human one: is the document a form, and is it meant to be filled in on paper or on screen?

Acrobat Pro’s Tags panel (Show/Hide → Side Panels → Tags from the hamburger or View menu; Accessibility tags in the current interface). Turn on Highlight Content and select a blank on the page with Find Tag From Selection. A <P> that contains the prompt and its underscores, or no tag at all, means the blank is not described. A <Form> element whose attribute objects (Properties → Edit Attribute Objects on the Tag tab) include one owned by PrintField means it is.

Not the checkers. Acrobat’s Accessibility Checker rules for forms, Tagged form fields and Field descriptions, are about interactive fields (Adobe’s list of checks). veraPDF’s PDF/UA-1 rule set has no rule under clause 7.14.

How to fix it free, in Acrobat Pro

Decide first which kind of form it is, because the two fixes are different documents.

If it will be filled in on screen, make it interactive. Adobe documents this in Convert documents to PDF forms:

1. Choose All tools → Prepare a form, select the file, and choose Create form. Acrobat detects the blanks and puts fields over them.
2. Review the fields — add, delete or resize as needed.
3. Give each field a description: with a form tool selected, right-click the field → Properties → General → Tooltip. This is the checker’s Field descriptions rule, and condition 28-005.
4. Tag the fields: Adobe’s instruction for the Tagged form fields rule is All tools → Prepare for accessibility → Automatically tag PDF. Each widget has to end up inside a <Form> element, condition 28-010.

If it has to stay a printed form, describe each blank with the attribute-object dialog that Adobe’s Tags panel guide documents for table spans:

1. Select the blank on the page and, in the Tags panel, choose Create Tag From Selection with the type Form.
2. With the new <Form> selected, choose Properties, then Edit Attribute Objects on the Tag tab.
3. Select Attribute Objects and click New Item. Expand the new dictionary, select its owner entry (created as Layout), click Change Item and change it to PrintField.
4. Select the dictionary, click New Item, and add the key Role with the value tv — or cb, rb, pb — as a name. Add a second key, Desc, with the field’s name as text.

That is per blank, with no batch path. For a long printed form, the source document is the place to fix it, if its producer can write PrintField — check one exported blank with the steps above before relying on it.

Where Taggart differs

Taggart’s check is a heuristic for “this page looks like a printed form”. It runs only on a document with no interactive fields at all, and only if no structure element anywhere carries a Role attribute. Then, page by page, it looks for two kinds of evidence together:

• at least two fill-in prompts in the page’s text — name:, date:, signature, please print, fill in, check one, and their Hebrew equivalents; and
• at least two lines of text containing five or more underscore characters each.

The first page with both is reported, once for the document:

Page 1 looks like a printed (non-interactive) form — fill-in prompts plus 4 rule line(s) — but the document has no /PrintField attributes describing the controls.

The evidence lists the prompts it matched and the number of underscore lines.

Two limits matter. Only typed underscores count as blanks. A form whose lines are drawn as rules, or whose tick boxes are drawn squares, is not reported however many prompts it has — which leaves out every form whose blanks are drawn rather than typed. That falls short of what the condition covers, so for a form with drawn blanks a clean Taggart report says nothing about this condition — look at it yourself. And one PrintField attribute anywhere clears the whole document, so a form with one described blank and twenty undescribed ones passes.

There is no repair. The finding is a warning and goes to the review queue, where you record what you decided — fillable, described, or not a form at all — with who decided it and when.

How Taggart handles it

The protocol marks this condition as needing human judgement, so no validator can decide it outright. Taggart applies a heuristic to find the likely cases and reports each one as warning for you to settle in the review queue. A heuristic finds what it was built to find and can miss the rest; what this one looks for is described above.

Where this sits in the standards

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.

Related conditions

• 28-010 A widget annotation is not nested within a Form tagEvery form control must sit inside a Form structure element.
• 28-005 A form field has neither a TU entry nor an alternative descriptionThe /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.
• 25-001 File contains the dynamicRender element with value "required"A dynamic XFA form has no static PDF representation, so its content is invisible to anything but the XFA renderer. PDF/UA-1 forbids it.

Other conditions in checkpoint 24

Checkpoint 24 covers non-interactive forms. These are its other failure conditions; the ones without a link are in the rule set but do not have a written page yet.

Checked with Taggart on a generated file that fails this condition on 2026-10-02. The Acrobat steps follow Adobe’s documentation and were not walked through by hand. Last updated 2026-10-02.