Accessible PDF Forms: Fields, Labels, and Keyboard Navigation

An accessible PDF form is one that a person can complete without a mouse, without sight, or both — every field has a name their software can announce, the fields are reached in a sensible order, and the instructions and errors are available to assistive technology. A printed form scanned to PDF, by contrast, is just a picture of a form; there's nothing to fill in and nothing to read. The gap between those two is where most form accessibility problems live.

This guide covers what makes a PDF form usable for everyone: interactive form fields versus flat printed forms, giving each field an accessible name, the major field types and their labels, logical tab order, required fields and instructions, error and format guidance, and how to test with a keyboard and a screen reader. It extends the structural fundamentals in our WCAG 2.2 and PDF/UA accessible PDF guide.

Interactive forms vs flat printed forms

PDF forms come in two flavors. An interactive form — built on the AcroForm model — has real, fillable widgets: text fields, checkboxes, radio buttons, dropdowns, and buttons that the reader's software recognizes and can operate. A flat form is a static page where the lines and boxes are just drawn graphics, with no fillable elements at all.

Only interactive forms can be made accessible in any meaningful sense. A flat form gives a screen-reader user nothing to land on and no way to enter data; even a sighted keyboard-only user can't tab between fields that don't exist. So the first step is making it a real interactive form — converting drawn boxes into AcroForm fields — before worrying about labels or order. If a form arrives flat, accessibility work can't start until that conversion happens.

Give every field an accessible name

A form field that has no name is announced by a screen reader as nothing more useful than "edit text" or "checkbox" — leaving the user to guess what it wants. Every field needs an accessible name, and in a PDF that name comes primarily from the field's tooltip (the TU, or user name, entry on the field).

The tooltip should match the visible label a sighted user reads. If the printed label says "Date of birth," set the tooltip to "Date of birth." Don't reuse generic names across fields — "Field 1," "Text2" — and don't leave it blank. The tooltip is what the screen reader speaks when the user tabs into the field, so it has to be clear and specific on its own. This is the form equivalent of the alt text an image needs and the headers a table cell needs — the structural naming work described in PDF tags and reading order.

Field types and their labels

Each field type carries its own labeling expectations:

Text fields — a single tooltip naming what to enter ("Email address"). For multi-line fields, the tooltip still describes the whole field.
Checkboxes — each checkbox needs its own name describing the specific option ("I agree to the terms"), not a shared group label. A standalone checkbox represents one independent yes/no choice.
Radio buttons — a set of radio buttons is one logical question with mutually exclusive answers. They share a field name (so selecting one clears the others), while each option's tooltip or export value identifies that choice. The user needs to know both the question and the option they're on.
List boxes and dropdowns — name the field for the question ("Country"), and make sure every selectable option has readable text.
Buttons — a button's name must describe its action ("Submit application," "Reset form"), not just "Button." Push buttons that only decorate the page and do nothing should not be focusable.

The aim throughout is that, hearing only the field's announced name and type, a user knows exactly what is being asked and what their input will do.

Logical tab order

Keyboard and screen-reader users move through a form with the Tab key, so the tab order must follow the form's reading order — top to bottom, and within a row in the direction the language reads. A form that jumps from the first field to one halfway down the page and back up is disorienting and easy to fill in wrong.

Set the tab order explicitly rather than trusting field-creation order, which often bears no relation to position on the page. Many tools offer an "order tabs by structure" or "by row" option; use it, then verify by tabbing through. If a screen reader reads the form one way but Tab moves another, the experience falls apart.

Required fields, instructions, and format guidance

Information that a sighted user picks up visually has to be available non-visually too:

Required fields. Set the field-level Required flag so the field is announced as required; don't rely on a red asterisk or color alone — color isn't conveyed to a screen reader, and an unexplained asterisk is meaningless.
Instructions. Put guidance where it's read in context. Field-specific instructions ("Enter your 9-digit SSN without dashes") belong in or beside that field — folded into the tooltip, or in tagged text immediately before it — not only in a paragraph at the top the user may have already passed.
Format expectations. State the expected format up front: date formats, character limits, whether to include country codes. Telling the user the rule before they type prevents frustrating errors.

Error and format guidance

When a form rejects an entry, the user needs to know which field failed and why, in text. A validation error signaled only by a beep, a color change, or a dialog that isn't tied to a field leaves a screen-reader user stuck.

Identify the specific field in the error message ("Phone number must be 10 digits") rather than a vague "invalid input."
Make the error message available as text the screen reader will announce, and move focus to the field that needs correcting where the workflow allows.
Prefer guidance that prevents errors — clear format hints up front — over messages that only appear after a failed submission.

Everything a user can do with a mouse, they must be able to do with a keyboard: reach every field with Tab, toggle checkboxes with Space, choose among radio buttons with the arrow keys, open and select within dropdowns, and activate buttons with Enter or Space. No field, and no submit action, may require a pointer.

For screen-reader support, the fields must also be part of the document's tag tree, so the reader exposes them in the right reading-order position with their names, types, states (checked/unchecked, required), and instructions. Fields that work for a keyboard user but are missing from the tags can be skipped entirely by a screen reader.

Two passes catch the large majority of form problems:

Keyboard pass. Put the mouse aside. Tab from the top of the form to the bottom and confirm focus moves in a logical order, lands on every field, never gets trapped, and reaches the submit button. Operate each control with the keyboard alone.
Screen-reader pass. Tab through again with a screen reader running and listen: each field should announce a clear name, its type, its state, and whether it's required. Trigger a validation error and confirm the message is spoken and points to the field. A PDF/UA checker built on the Matterhorn Protocol will additionally flag fields with no tooltip and fields missing from the tags, but a checker can't judge whether a name actually makes sense — only a human listening can.

Forms are one piece of a fully accessible document; tables are another, covered in building accessible tables in PDFs. Accessible forms also matter acutely in regulated sectors — see how they factor into healthcare PDFs and HHS Section 504, where intake and consent forms must be usable by everyone.

Key takeaways

Only interactive (AcroForm) fields can be made accessible; flat printed forms must first be converted to real fillable fields.
Give every field a clear, specific accessible name via its tooltip (TU), matching the visible label and unique per field.
Set an explicit tab order that follows the reading order, and make instructions, format hints, required status, and error messages available as text — never color or an asterisk alone.
Ensure full keyboard operability and include the fields in the tag tree so a screen reader exposes their name, type, and state.
Test with both a keyboard-only pass and a screen-reader pass; a Matterhorn-based checker catches the mechanical gaps a human still has to judge for clarity.