Accessible PDF Forms: AcroForm Tagging, Tab Order, and Error Identification Done Right

In 2023 I spent six billable hours fixing a single client intake form for a Texas law firm. It had 41 AcroForm fields, zero tags, and a tab order that jumped from “Last Name” to “Emergency Contact Phone” before circling back to “First Name.” A screen reader user would have abandoned it in under a minute. The form itself took 20 minutes to build in Acrobat. The remediation took a day. That ratio, 20 minutes to create the problem, a day to fix it, is the entire reason this post exists.

Why Fillable PDF Forms Fail Accessibility Checks So Often

Most accessible PDF failures are not exotic. They are mundane: untagged form fields, no tooltips, a tab order that follows the order fields were drawn instead of the order they were meant to be read. I run pre-remediation audits on client PDFs every week, and in my logs roughly 7 out of 10 fillable forms have at least one of these three problems.

The root cause is that Acrobat makes it trivially easy to add form fields. The toolbar invites you to drop text boxes on a page, and nothing in that workflow tells you the fields are invisible to assistive technology until you run an accessibility check or a real user with a screen reader tries to fill the form.

The good news: AcroForm fields, when tagged correctly, work well with JAWS, NVDA, and VoiceOver. A tagged form field exposes its name (from the tooltip), its role, its state, and its value. Getting there takes discipline, not budget.

The stakes went up when the U.S. Department of Justice published its Title II web accessibility rule (28 CFR Part 35, Subpart H), requiring state and local government web content and mobile apps, including downloadable PDF forms, to meet WCAG 2.1 Level AA. Public entities face statutory compliance deadlines of April 26, 2027 (for jurisdictions of 50,000+) and April 26, 2028 (for smaller entities). Small businesses selling into those agencies now inherit the same expectations through contract language, and Section 508 already binds federal PDFs at section508.gov.

What AcroForm Tagging Actually Does

A PDF has two separate layers that matter for forms. The first is the AcroForm layer: the interactive fields themselves, stored in the document’s form dictionary. The second is the tag tree: the logical structure that assistive technology reads. A form field can exist in the AcroForm layer and be perfectly clickable for a mouse user, yet be completely absent from the tag tree. That is the failure mode that catches most people.

Tagging a form field does three things:

• It places the field into the reading order at the right position, so a screen reader announces it where a sighted user would expect it.
• It associates the field with its visible label through the tooltip and, ideally, the tag structure.
• It lets the field participate in PDF/UA and WCAG conformance checks, which an increasing number of procurement contracts and legal settlements require.

For a deeper grounding in how these standards stack together, see our overview of WCAG conformance tiers and how Section 508 maps onto them.

The tooltips deserve special attention. Acrobat auto-generates them from whatever text happens to be near the field, which is why I have seen tooltips reading “Click here” or a raw phone number with no label at all. I set every tooltip manually, usually to the exact visible label plus format hints, like “Date of birth, MM/DD/YYYY.”

Setting Tab Order That Matches Reading Order

Tab order is where most forms I audit fall apart. Acrobat defaults to tab order by row: it walks the page in rows regardless of column grouping. On a two-column layout, that means a user pressing Tab bounces between the left and right columns in a way that makes no sense.

My standard process in Acrobat Pro:

1. Open Prepare Form and select Fields in the right-hand panel.
2. Use the Tab Order dropdown and switch from “Order by Row” to “Order by Structure” once tagging is in place.
3. Before tagging exists, drag fields in the Fields panel into true reading order: top to bottom, left to right within visual groups.
4. Test with keyboard only: Tab through every field, then Shift+Tab backward, and log any jump that skips a field or lands somewhere unexpected.

On that law firm form I mentioned, switching to structure-based tab order cut the remediation time in half, because the tag tree I built already encoded the correct sequence.

Tagging Your AcroForm Fields Step by Step

Here is the workflow I use in Acrobat Pro:

1. Run the accessibility check first. View > Accessibility > Full Check. Save the report. It tells you which fields are untagged.
2. Tag the document if the tag tree is empty: View > Accessibility > Add Tags to Document.
3. Open the Tags panel and find each <Form> element. Untagged fields appear as annotations outside the structure. Use Find Element from Selection to match field to tag.
4. Verify each field’s type. Text fields become <Form>, checkboxes and radio buttons need their checked/unchecked states exposed, and combo boxes need their option lists reachable.
5. Set tooltips in Prepare Form: right-click a field, Properties, General tab, Tooltip field. Never leave this on auto.
6. Set tab order per the section above.
7. Re-run the full check and resolve every form-related error before delivery.

Radio button groups are the fiddliest part. Each radio button in a group shares the same name, but each needs its own tag so the screen reader announces “Yes, radio button, 1 of 2” correctly. Acrobat usually handles the group binding; Foxit sometimes splits groups into separate fields, which breaks the either/or logic. When that happens, I rebuild the group from scratch rather than patch it.

If your remediation queue is large, our notes on practical PDF remediation cover batch workflows and when it is cheaper to rebuild a form in HTML instead. For organizations that sell into government or enterprise buyers, the accessibility documentation expectations from procurement teams tie directly into VPAT obligations, so alignment matters early.

Error Identification and Instructions in PDF Forms

WCAG 3.3.1 (Error Identification) and 3.3.2 (Labels or Instructions) apply to PDFs just as they do to web pages. PDF forms cannot run live JavaScript validation the way HTML forms can, but they can still fail users badly when errors exist.

What I require on every client form:

• Format instructions in the tooltip and the visible label. “Tax ID, 9 digits, no dashes” beats a rejection after submission.
• Required fields marked in the tag, not just with a red asterisk a screen reader may never announce. In Acrobat, set the field to required in Prepare Form; the tooltip should also say “required.”
• A contact path on the form itself for users who hit a barrier. For a downloadable form that will be printed, emailed, or uploaded, an inaccessible error state with no human fallback is a Section 508 finding waiting to happen.
• Validation scripts used sparingly. Acrobat supports JavaScript on fields, and I use it only for simple format checks, like enforcing a date pattern, with the error message written in plain language. Complex scripting across a form is a maintenance and compatibility liability.

One real failure mode: a state agency form I reviewed in 2024 used a validation script that cleared the entire form when one field failed. The error alert was a system dialog with no text alternative. We rebuilt it with format hints up front and a single confirmation dialog. Complaints to their accessibility coordinator dropped to zero over the next quarter, though I will note they never had a formal complaint count before, so the baseline was soft.

Tooling, Costs, and When to Use HTML Instead

A quick comparison of the tools I actually use:

Tool	Approx. cost	Best for	Weak spot
Adobe Acrobat Pro	~$240, three-year term	Tag editing, tab order, full checks	Subscription UI clutter, steep learning curve
Foxit PDF Editor	~$130-160/yr	Cheaper remediation at volume	Radio groups, complex tag trees
axesPDF (axes4)	Annual subscription, vendor quote	Fast fixes on deadline	Windows only, narrow feature set
PAC 2024 / 2026 (free)	$0	PDF/UA validation, screen reader simulation	Checker only, not an editor

PAC is the checker I trust most because it tests against PDF/UA-1 and flags things Acrobat’s built-in check misses, like incorrect field role mapping. It is free from the PDF Accessibility Checker site, built on the PDF Association’s Matterhorn Protocol checkpoints. In our PDF accessibility checkers benchmark, we examined the structural division between syntactic checkers and true screen reader validation across PAC, axesCheck, and Acrobat.

One timing note that matters for procurement: PDF/UA-2, published as ISO 14289-2:2024, aligns the standard with WCAG 2.1 and adds requirements around annotations and form structure. Most contracts still cite PDF/UA-1, but RFPs increasingly ask for PDF/UA-2, so I validate against both when the deliverable is long-lived.

When an organization hosts thousands of legacy interactive forms, manual tag repairs become a serious financial liability. Tools like RemediatePDF automate document restructuring and generate accessible twin web transcripts to keep published archives compliant without destructive source file edits, which we integrate across our compliance solutions.

My honest advice for small businesses: if the form is new and the audience is web-based, build it in HTML. A coded form with proper <label> elements, aria-describedby for hints, and live region error announcements is cheaper to maintain and easier to test. I put the decision threshold at about five forms per year. Below that, PDFs are fine if tagged correctly. Above it, the HTML route pays for itself in avoided remediation hours. Our walkthrough of AI-assisted accessibility auditing covers how automated tooling fits alongside manual screen reader testing.

What Most Guides Get Wrong

Three things I see repeated constantly, all wrong in practice:

• “Acrobat’s accessibility check passing means the form is accessible.” No. Acrobat’s checker tests a subset of PDF/UA. I have seen forms score a clean bill from Acrobat’s Full Check and still fail PAC on field role mapping or missing document language. Run both, every time.
• “Auto-tagging fixes forms.” Acrobat’s Add Tags to Document is trained on text documents. On forms it routinely tags fields as generic <P> content or dumps every field at the end of the tag tree, which preserves the tab-order problem while hiding it. Tags on forms need human placement.
• “The tooltip is enough labeling.” A tooltip helps screen reader users, but PDF/UA expects the visible label text to be present in the tag structure too. A field whose label exists only as floating artwork, with the real label living in a tooltip, is a common PDF/UA failure that costs minutes per field to fix later.

Final Checklist Before You Ship a Fillable PDF

Run this list on every form before it leaves your hands:

1. Full accessibility check passes with zero form errors.
2. Every field has a manually written tooltip matching its visible label.
3. Tab order matches reading order, verified by keyboard-only testing.
4. Required fields are flagged in both the tooltip and the field properties.
5. Radio groups announce position (“1 of 3”) and group label.
6. Format instructions appear before the field, not after a rejection.
7. PAC or equivalent PDF/UA check passes.
8. Tested end-to-end with at least one screen reader: NVDA (free) on Windows, VoiceOver on Mac.
9. A human contact path is printed on the form.
10. The document metadata (title, author, language) is set; a missing document language is one of the most common PDF/UA failures.

Conclusion

Accessible fillable PDF forms are not a specialty skill reserved for consultants. They are a sequence of boring, checkable steps: tag the fields, write real tooltips, fix the tab order, and identify errors in plain language before users hit them. The forms I remediate fail in predictable ways, and the fixes cost minutes when done at creation instead of hours afterward. Start with the checklist above on your next form, run PAC before delivery, and your PDFs will hold up under both screen readers and procurement audits. If you want a second set of eyes on a stubborn form, that is exactly the kind of remediation work our team handles weekly.