Accessible PDF forms: how to make a fillable form screen readers can use

Accessible PDF forms are forms a person can complete without seeing the page. Every field is a real, tagged form field, every field has a tooltip that a screen reader reads aloud, and the Tab key moves through the fields in the order the form intends. Forms deserve attention before almost any other PDF, because they are how residents apply for permits, licenses, benefits and services. The work is tractable: most of it is careful naming, done once per form. This guide covers the WCAG criteria, the "Text1" problem, Acrobat Pro settings, a field-by-field checklist, testing with NVDA, and when a web form is better.

Why forms come first, and what WCAG 2.1 asks of them

People use forms to get a service: permit applications, license renewals, records requests, patient intake. Under the ADA Title II web rule, PDFs posted before your compliance date can be exempt, but not when they are "currently used to apply for, gain access to, or participate in" your services, programs or activities. A form residents still download is in scope no matter when you posted it. See Title II and PDFs for the exceptions and the Section 504 guide for HHS-funded programs.

An inaccessible form shuts out screen reader users and keyboard users, whose workaround is asking someone else to fill it in and reading a date of birth or medical history aloud to them.

Seven WCAG 2.1 success criteria do most of the work. The W3C's PDF techniques are examples of one way to pass, not requirements.

The "Text1" problem: screen readers read the tooltip, not the field name

A field's General tab in Acrobat has two boxes that look alike, Name and Tooltip, with different jobs.

• Name is internal. Acrobat uses it to tell fields apart and to label exported data. The W3C's PDF12 technique says "the name field in the Properties dialog is not used to provide the name for a control when read by assistive technologies."
• Tooltip is what gets announced. Adobe tells authors to type a description in the Tooltip box because "Screen readers read this text aloud to the user."

So a form can look perfect and say nothing. Without a tooltip, a screen reader falls back to the field's type and internal name. A Centers for Medicare & Medicaid Services guide to Acrobat forms describes a check box that announces only "Check Box 1," its type and its state, even with a visible label beside it. A resident tabbing through a permit application hears "Text1, edit," then "Text2, edit."

Good tooltips follow four rules.

• Match the printed label. WebAIM says the tooltip "must be equivalent to any visible text that is functioning as a label for the field."
• Add what the layout tells sighted people. Include the format, "required," line numbers and character limits. The W3C's PDF10 example tooltip reads "Date you are available: use MM/DD/YYYY format."
• Name the field, don't instruct. In Adobe's example, "First name" is a good description and "Enter first name" is not.
• Make every name unique. Two fields called "Date" become "Date of incident" and "Date signed."

How to make a fillable PDF form accessible in Acrobat Pro

Menu names follow Adobe's help pages as of October 2026. Older versions call the tool Prepare Form.

1. Start from a tagged document. Draw field lines as graphics, because Adobe warns that typed underscores and vertical bars "can confuse screen readers."
2. Add the fields. Choose All tools > Prepare a form. Acrobat detects likely fields and copies nearby text into their tooltips, but Massachusetts' state guidance warns that not every field will be detected accurately. Review every one.
3. Write each tooltip. Right-click a field, choose Properties, and type the tooltip on the General tab. Tick Required for mandatory fields and put "required" in the tooltip too, as WebAIM recommends.
4. Tag the fields. Choose All tools > Prepare for accessibility > Automatically tag form fields. WebAIM notes that adding a field does not create its tag, so a field can be fillable yet missing from the structure a screen reader follows.
5. Set the tab order. In the Fields panel, sort by Tab order, choose Order tabs by structure and turn on Show tab numbers. Then select all page thumbnails, open Page Properties and set Tab Order to Use Document Structure.
6. Run the checker. Choose All tools > Prepare for accessibility > Check for accessibility and clear the Tagged form fields and Field descriptions rules.

Radio buttons and check boxes

Give every button in a radio group the same Name and the same Tooltip, which carries the question ("Applicant type"). On each button's Options tab, set Radio Button Choice to its visible answer ("Business"). A screen reader announces both. A choice can't be cleared without a reset, so give optional questions a "Not applicable" answer. Check boxes are separate questions, so each gets its own tooltip, with the shared question included when there is one: "Services requested: bulk trash pickup."

Dates, combs, dropdowns and calculated fields

• Dates. Put the format in the tooltip so people learn it before they type. A Date format on the Format tab makes Acrobat show an error alert when an entry isn't recognized.
• Error messages. A validation script's alert must say what is wrong and how to fix it ("Enter the ZIP code as five digits"), not just "Invalid value."
• Combs. Five one-box fields for a ZIP code mean five unnamed tab stops. Use one text field with Comb of characters and a tooltip that gives the length.
• Dropdowns. A screen reader reads the tooltip and the default choice, so add a tooltip and a neutral first item such as "Select a county."
• Calculated fields. A computed total should say so in its tooltip ("Total fees, calculated") and be set to Read Only.

Signature fields, flat forms and print-and-sign forms

Section508.gov's advice for signature fields (opens an external site) is to "add tooltips that match the label or instruction." Drawing a signature takes a mouse or touch screen, so if your office accepts a typed name, say so.

Adobe describes flat forms (opens an external site) as "scanned paper forms or PDFs that don't have interactive fields to fill in or sign." Convert one with Prepare a form, then follow every step above. If it is a scan, run OCR first, as our guide to scanned PDFs and OCR explains. A form signed in ink still needs its labels and instructions tagged in order, and making it fillable lets people type before printing.

An accessible PDF form checklist, field by field

Wording varies between screen readers, so listen for the meaning.

How to test a PDF form with NVDA

The checker confirms tooltips exist. Listening tells you whether they make sense.

1. Install NVDA, a free Windows screen reader from NV Access, and open the form in Acrobat Reader.
2. If you are sighted, turn on Speech Viewer (NVDA menu > Tools > Speech Viewer) to see a transcript of what NVDA says.
3. Press Tab from the top and compare each announcement with the printed label. Shift+Tab goes back, Space checks a box, and arrow keys move within radio groups and lists.
4. Confirm the order matches the form, then enter a badly formatted date and listen to the error.
5. Tabbing skips ordinary text, so instructions between fields get missed. Press NVDA+Space for browse mode to read everything, and F to jump to the next field.

Check the field borders too: a pale gray outline on white can fall below the 3:1 non-text contrast ratio.

When a web form beats a PDF form

GOV.UK tells publishers to "Build forms in HTML where possible." Massachusetts calls a web-based form "the most accessible, flexible, and least time-consuming way to create or modify a form," and notes that web entries typically go straight into a database, while PDF entries are often retyped by hand. As WebAIM notes, HTML ties a visible label to its field, while a PDF repeats it in a tooltip. Digital.gov (opens an external site) still keeps a place for PDFs, including "forms or documents that will be printed for use."

• Choose a web form when people submit online, the answers feed a system, or the form changes often.
• Keep an accessible PDF when the form must be printed, signed in ink or filed in person, or another agency requires a fixed layout.

A web form must meet WCAG 2.1 AA too. If one replaces a PDF, take the old file down or redirect its address.

How Ockem Proof handles form fields

Ockem Proof, our product, does the registration and checking work and leaves naming to a person.

• Fields registered automatically. Proof tags each field widget into the document's form structure and writes its tooltip.
• Names checked. Proof flags names that don't identify the field, such as "Text1," two fields both called "Date," or a date field whose name never states the format.
• Names drafted, then confirmed. Proof drafts each name from the printed label, and AI drafts one only where the page prints nothing. A person accepts or edits each name where it meets the field, and no AI draft is written without that approval. Drafting runs on self-hosted models on hardware Ockem operates; no customer document content goes to a third-party model.
• Focus order walked. Fields are checked in the order a screen-reader user tabs through them.
• Ghost widgets cleared. Leftover exporter widgets are removed, but only when provably junk.
• Focus visible. For many form documents, WCAG 2.4.7 Focus Visible is now decided inside Proof, without a separate tab-through.
• Field borders measured. Proof measures form-field border contrast, and a person attests to non-text contrast with the evidence beside them. An attestation can clear a review item but never overrides a confirmed failure, and an unanswered check reads "Needs review," never "Failed."

Every check Proof asks a person to make points at the exact spot on the page. The certificate states what software verified, what your organization attested and what was not tested.

A person still decides what each field is called, whether an instruction relies on position or shape, and whether the form should be a web page at all. As the rule page puts it, a field's name is "content, not plumbing." See the form fields rule page.

See it on your own forms

You can try one PDF (opens an external site) of up to 10 pages free, with no account. To find every form on your site, use the free PDF inventory tool. The form fields rule page covers Proof's handling. For the rules, read Title II and PDFs. For forms in columns or tables, see reading order in complex layouts, and for what software settles alone, see what software fixes and what needs a person.

Questions

This guide explains the rules in plain language. It isn’t legal advice. Check how they apply to your organization with counsel.