Accessible PDF forms & reading order

A PDF looks finished long before it is accessible. What a sighted reader sees on the page — a heading, then a paragraph, then a row of form fields — is the visual layout. What a screen reader follows is something else entirely: the document’s tag tree, an ordered structure of <Document>, <H1>, <P>, <Form> and other tags that the author (or the export tool) created. When that tree is missing, out of order, or mislabelled, the form may be impossible to complete with assistive technology even though it looks perfect on screen.

This lesson works through the three defects that break tagged PDF forms most often. All three are properties of the tag tree and the field objects, not of the visible page, so they survive a casual proof-read and only surface when someone navigates the document non-visually. We show each as an escaped tag-tree or field-property sketch — nothing on this page is a live PDF — alongside the fix in a tool such as Acrobat Pro.

What you’ll learn

How to give every PDF form field a programmatic name through its tooltip (the TU property) so it isn’t announced as bare “edit text”; how to set the tag tree’s reading order to match the visual order so content is spoken in the sequence the author intended; and how to tag lists as <L> structures and data tables as <Table> with real header cells, so their relationships survive non-visual reading.

Standards this lesson maps to
Standard Criterion Level What it requires
WCAG 2.2 1.3.1 Info and Relationships A Structure and relationships — field labels, lists, table headers — are conveyed in the tags, not by visual layout alone.
WCAG 2.2 1.3.2 Meaningful Sequence A When sequence affects meaning, the tag tree presents content in a correct reading order.
WCAG 2.2 3.3.2 Labels or Instructions A Every form field has a label or instruction — for a PDF field, its tooltip.
WCAG 2.2 4.1.2 Name, Role, Value A Each field exposes a name and role; for a PDF widget the tooltip supplies the accessible name.
PDF/UA-1 ISO 14289-1 — The accessibility standard for PDF: a real tag tree, logical reading order, and labelled form fields are mandatory.
EN 301 549 10 (Non-web documents) — European harmonised standard; applies the WCAG criteria to documents such as PDF.
Section 508 504 (incorporates WCAG A & AA) — US federal electronic documents must meet WCAG 2.0 Level A and AA, including PDF forms.
ADA Title II WCAG 2.1 AA (DOJ rule) AA US state/local government documents, including PDFs, must conform to WCAG 2.1 AA.

The three problems we’ll fix

Each card below isolates one common PDF defect. For every issue you get a plain-language statement of the problem, a Bad example (shown as an escaped tag-tree or field-property sketch, never a live PDF), a Good example, the copyable Code, and an ordered fix you can carry out in a PDF authoring tool.

Form fields with no tooltip or label

WCAG 2.2 · 1.3.1 A 3.3.2 A 4.1.2 A PDF/UA-1 EN 301 549

In a PDF, the visible text that looks like a field’s label is usually just a line of page content sitting next to the field widget — there is no for/id relationship the way there is in HTML. A form field gets its accessible name from its tooltip, stored in the field object’s TU property. When the tooltip is empty, a screen reader announces the field as bare “edit text” or just “text field”, with no hint of what to type. The sighted caption is invisible to assistive technology, so the user is left guessing.

Bad

The text field has no tooltip. Its TU entry is empty, so the widget exposes no accessible name and is announced as “edit text”.

field-no-tooltip.txt 
Field object (text field)
  /FT /Tx           <!-- field type: text -->
  /T  (field_7)     <!-- internal name, not announced -->
  /TU ()            <!-- tooltip EMPTY → no accessible name -->

Visible on page:  "Email address"   <-- plain page text, NOT linked
Screen reader says: "Edit text, blank"

Good

The tooltip carries the field’s name. Its TU value matches the visible caption, so the widget is announced as “Email address, edit text”.

field-with-tooltip.txt 
Field object (text field)
  /FT /Tx
  /T  (email)
  /TU (Email address)   <!-- tooltip = accessible name -->

Screen reader says: "Email address, edit text"

Code

In Acrobat Pro, open Prepare Form, then set each field’s tooltip in its properties. Required state and instructions belong in the tooltip too, so they are announced with the field.

field-properties.txt 
Acrobat → Prepare Form → field Properties → General tab
  Tooltip: "Phone number (required, digits only)"

Resulting field object:
  /FT /Tx
  /TU (Phone number \(required, digits only\))
  /Ff 2          <!-- "Required" flag set -->

How to fix

  1. Open the form in a PDF authoring tool (for example Acrobat Pro’s Prepare Form mode) and select each field in turn.
  2. Set the field’s tooltip (the TU property) to match the visible caption — this becomes the field’s accessible name.
  3. Include any short instruction or required state in the tooltip so it is announced with the field, and set the “Required” flag where it applies.
  4. Run the accessibility checker and test with a screen reader; confirm each field is announced with its name and role, e.g. “Email address, edit text”.

Tag tree reading order doesn’t match the visual order

WCAG 2.2 · 1.3.2 A PDF/UA-1 EN 301 549 Section 508

A screen reader, and PDF reflow, follow the order of the tag tree, not the position of content on the page. Multi-column layouts, sidebars, and content placed by an export tool in creation order rather than visual order all produce a tag tree that reads out of sequence: a label can be spoken after its field, the right-hand column can be read before the left, or a caption can land paragraphs away from its field. The page looks correct, but the spoken sequence is scrambled, so meaning that depends on order is lost.

Bad

The visual order is label then field, twice. The tag tree, however, lists both labels first and both fields after, so the reader hears the questions and answers detached from each other.

tag-order-bad.txt 
Visual order on page:
  "First name" [____]   "Last name" [____]

Tag tree (reading order) — WRONG:
  <P> First name
  <P> Last name
  <Form> (first-name field)
  <Form> (last-name field)

Heard: "First name. Last name. Edit text. Edit text."

Good

The tag tree is reordered so each label is immediately followed by its field, matching the visual reading order. Now each question is heard with its answer field.

tag-order-good.txt 
Tag tree (reading order) — CORRECT:
  <P> First name
  <Form> (first-name field)
  <P> Last name
  <Form> (last-name field)

Heard: "First name, edit text. Last name, edit text."

Code

Fix order in the Tags tree (drag tags into sequence) or with the Reading Order tool. The Order panel reflects the same sequence; don’t rely on the Content panel’s draw order, which is separate.

reorder-tags.txt 
Acrobat → View → Show/Hide → Navigation Panes → Tags
  1. Open the Tags tree and the document side by side.
  2. Drag each tag so the sequence matches the visual flow.
  3. Tools → Accessibility → Reading Order to fix regions.
  4. Re-check with Read Out Loud and a screen reader.

How to fix

  1. Open the Tags tree and read it top to bottom — this is the order assistive technology will follow.
  2. Reorder tags by dragging them so the sequence matches the visual reading order, keeping each label immediately before its field.
  3. Use the Reading Order tool to redefine regions in multi-column or sidebar layouts so columns are read in the right order.
  4. Verify with Read Out Loud and a real screen reader that content, labels, and fields are spoken in the intended sequence (1.3.2).

Lists and tables not tagged as lists and tables

WCAG 2.2 · 1.3.1 A PDF/UA-1 EN 301 549 Section 508

Bullet points and grid layouts often look like lists and tables but are tagged as a flat run of <P> paragraphs. A screen reader then can’t announce “list, 5 items” or move cell by cell, and — worst of all — a data table read as loose paragraphs loses the link between each value and its row and column headers. A list must be a <L> structure of <LI> items, and a data table a <Table> of <TR> rows with <TH> header cells scoped to rows or columns.

Bad

A two-column rate table is tagged as plain paragraphs. The header row is just more text, so a cell value is read with no header context.

table-bad.txt 
Tag tree — WRONG (flat paragraphs):
  <P> Plan
  <P> Monthly
  <P> Basic
  <P> $9
  <P> Pro
  <P> $19

Heard: "Plan. Monthly. Basic. 9 dollars. Pro. 19 dollars."
(no row/column relationships)

Good

The same content tagged as a real table. Header cells use <TH> with a scope, so each price is announced with its plan and column.

table-good.txt 
Tag tree — CORRECT:
  <Table>
    <TR> <TH Scope="Column">Plan</TH> <TH Scope="Column">Monthly</TH>
    <TR> <TH Scope="Row">Basic</TH> <TD>$9</TD>
    <TR> <TH Scope="Row">Pro</TH>   <TD>$19</TD>

Heard at $19: "Pro, Monthly, 19 dollars."

Code

A list must be an <L> tag containing <LI> items, each with a label and body. Don’t fake bullets with a leading “•” character in a paragraph.

list-good.txt 
Tag tree — list:
  <L>
    <LI> <Lbl>•</Lbl> <LBody>Bring photo ID</LBody>
    <LI> <Lbl>•</Lbl> <LBody>Bring proof of address</LBody>

Heard: "List, 2 items. Bullet, Bring photo ID. ..."

Acrobat → Reading Order → select rows → "Table",
then Table Editor to set TH cells and Scope.

How to fix

  1. Find content that is visually a list or table but tagged as <P> paragraphs, using the Tags tree or the accessibility checker.
  2. Re-tag lists as an <L> structure with one <LI> (label plus <LBody>) per item.
  3. Re-tag data tables as <Table> with <TR> rows, and use the Table Editor to mark header cells as <TH> with the correct row or column scope.
  4. Verify a cell value is announced with its row and column headers, and that a list announces its item count (1.3.1).

Recap

  • Give every form field a tooltip (TU) so it has a programmatic name and isn’t announced as bare “edit text” (1.3.1, 3.3.2, 4.1.2).
  • Set the tag tree’s reading order to match the visual order, so content is spoken in the sequence the author intended (1.3.2).
  • Tag lists as <L> structures and data tables as <Table> with real <TH> header cells, so their relationships survive non-visual reading (1.3.1).

The same fixes satisfy WCAG, PDF/UA-1, EN 301 549, Section 508, and ADA Title II at once — tag the document correctly and you meet them all.