Widget annotations in Form tag

Widget annotations in Form tag is a PDF/UA check in PAC, the free PDF Accessibility Checker. It fails when a fillable form field's widget, the visible box, checkbox or button you click, isn't placed inside a Form tag in the document's structure. Without that tag, screen readers can't find the field in the reading order, so people may never reach it.

What this means

Every fillable field in a PDF has one or more widgets, which are annotations: the parts of the field you see and click. A text box has one widget. A group of radio buttons has one widget per button. PDF/UA, the ISO standard for accessible PDFs, requires each widget to sit inside a Form tag in the tag tree, linked through an object reference (OBJR). The usual pattern is one Form tag per widget, placed right after the field's printed label, so a screen reader hears the label and then the field.

People often search for this message with the words "PDF/UA annotations". Most failures come from how forms are made. A document is written in Word, exported as a tagged PDF, and then the fields are added in Acrobat's Prepare Form tool. Word's PDF export doesn't create fillable fields, so every field is added after the document was tagged, and those new fields usually aren't added to the tag tree unless someone tags them.

Why it matters

Forms are how people apply for permits, benefits, jobs and classes. A screen reader user moving through the document may skip right past an untagged field, or hear it far away from its label. Keyboard users can lose the logical order too, because tab order that follows the document structure can only include fields that are in the structure. This affects WCAG 2.1 success criteria 1.3.1 Info and Relationships and 4.1.2 Name, Role, Value.

How to fix it in Acrobat Pro and re-check in PAC

Older versions of Acrobat also had an Autotag Form Fields command. If yours does, it can save time, but check where it puts each tag afterward.

Fix it in the source file

Word and most word processors can't export fillable PDF fields, so plan for fields to be added and tagged in the PDF. You can make that easier in the source:

• Put a clear printed label next to every field, including any format, such as "Date of birth (MM/DD/YYYY)".
• Lay the form out with a simple structure, and avoid floating text boxes.
• Don't use rows of underscores or dots to draw blanks. Screen readers read every character, and they get in the way of the real fields.
• Mark required fields in words, not only with color or an unexplained asterisk.

After the fields are added in Acrobat, tag them as above before you publish.

Fix it automatically with Includoc

Includoc fixes this automatically. We tag every field in reading order, each in its own Form tag, and set the tab order of every page with fields to follow the structure.

Labels need a person's check, so our AI writes each field's tooltip from the nearby printed label and you confirm them on the review screen. For forms people use to apply for services, the human-verified tier tests the form with a screen reader. We can't fix dynamic XFA forms, an older Adobe format; convert those to a standard PDF form first.

Standards

Related errors

• Tagged form fields and Field descriptions – Failed: Acrobat's version of this check, plus field tooltips.
• Tab order – Failed: keyboard order for fields and links.

For a complete walkthrough, read Forms in PDFs, or check a PDF free to find every untagged field.