PDF Form Accessibility

For reference only -- not part of a11ybot's automated checks.

What It Is

An interactive PDF form is a set of form field annotations overlaid on a page. The PDF spec defines four field types via the /FT entry: /Tx (text), /Btn (button, radio, checkbox), /Ch (choice list / combo), and /Sig (signature). In an AcroForm document these annotations are collected in the document catalog's /AcroForm dictionary; each field carries a /T partial field name (Text1, Text2, ...) and, for accessibility, a /TU entry -- the tooltip -- which is what a screen reader announces as the accessible name[1]. A form field without TU falls back to T, and T is almost never a human label.

For a PDF form to be accessible under EN 301 549 clause 10 and ISO 14289-1 (PDF/UA-1)[2][1], each field must have:

  • A TU tooltip that matches the visible label text -- this is the programmatic accessible name.
  • A logical tab order that matches the visual reading order. Set this in Acrobat Pro via Page Properties → Tab Order → Use Document Structure, which binds tab sequence to the tag tree rather than to field creation order.
  • A tagged link between the field annotation and the surrounding label text, via an OBJR (object reference) inside a <Form> structure element nested under the <Lbl> / <LBody>.
  • Required-field semantics: the Ff (field flags) bit for Required set, plus a visible asterisk or the word "required" in the label so the requirement is not conveyed by color alone.
  • Format help (date format, phone format, max length) spelled out in the TU tooltip, not only in a separate instructions paragraph.

Why It Matters

Forms are how people claim benefits, file taxes, apply for services, and submit complaints. The failure mode that breaks them is mechanical: a fillable PDF generated by scanning a paper form and letting Acrobat auto-detect fields inherits TU = T = Text1, Text2, Text3... because the auto-detector has no visible label to copy. A screen-reader user tabs through the form and hears "Text1 edit, Text2 edit, Text3 edit" with no idea which field is "Last name" and which is "Date of birth." The separate failure mode is the flat PDF that looks fillable -- an exported scan with form-shaped rectangles drawn on top but no /AcroForm dictionary at all. Keyboard users cannot focus the boxes because there are no field annotations to focus. The "print, fill in by hand, scan back" workaround is not an alternative for a user who cannot hold a pen or cannot see the paper.

How It Relates to WCAG

The PDF form-accessibility requirements map directly onto three WCAG success criteria, imported into PDF territory through PDF/UA and clause 10 of EN 301 549[3][2]:

  • 1.3.1 Info and Relationships[4] -- the programmatic association between a field annotation and its label text, expressed as the OBJR inside the <Form> element in the tag tree.
  • 3.3.2 Labels or Instructions[5] -- the visible label and the format hint ("MM/DD/YYYY") are present, and the format hint is duplicated into TU so screen-reader users get it on focus, not only when they read past the field.
  • 4.1.2 Name, Role, Value[6] -- the field has a role (from /FT), an accessible name (from TU), and a value that assistive technology can read and set.

Error-handling criteria also apply once the form is submitted -- 3.3.1 Error Identification[7] and 3.3.3 Error Suggestion[8] -- but PDF forms rarely implement inline validation the way HTML forms do, so the practical guidance is to surface format requirements up front in the tooltip rather than rely on post-submit error text.

Practical Implications

  • Build the source in InDesign (or a tagged-PDF-aware tool) with named form fields whose names match the visible labels, then tag in Acrobat Pro. Auto-detect on a scanned paper form is the mechanism that produces Text1, Text2, Text3 -- avoid it.
  • Generate accessible PDFs directly from HTML forms where possible. A well-formed <label for> in HTML survives the export as TU = label text, and the tag tree falls out of the DOM.
  • Set tab order to Use Document Structure on every page. The default Row or Column order is geometric and breaks on multi-column layouts.
  • Group radio buttons under a shared parent field (same /T) so the group relationship is programmatic, not visual.
  • Never flatten after signing. Flattening converts field annotations to static page content -- the /AcroForm dictionary vanishes and the document stops being a form at all.
  • Test with NVDA plus Acrobat Reader: tab through the form and confirm that what is announced on each field matches the visible label. If the reader says "Text1 edit" the TU entry is missing.

Related Clauses

Sources

  • ETSI EN 301 549 v3.2.1, clause 10
  • ISO 14289-1 (PDF/UA-1)
  • WCAG 2.2 Success Criteria 1.3.1, 3.3.1-3.3.3, 4.1.2