o make a fillable Portable Document Format (PDF) form accessible, give every field a descriptive tooltip (the name a screen reader announces), set a tab order that follows the page, make sure each field is tagged in the document structure, group related radio buttons and checkboxes, and state required fields and formats in text rather than color alone. Then run PDF accessibility testing with a keyboard and a screen reader, because an automated checker can’t tell whether a label makes sense.
A prospective student who fills out forms with a keyboard and a screen reader should be able to finish an admissions or financial aid application alone, at midnight, the same way everyone else does. When the fields announce themselves as nothing, that student has to email an office, wait for business hours, and share personal financial details with office staff just to get through the form. That’s the real cost of an inaccessible form: independence, not just convenience.
Most guides to accessible PDF forms walk through adding fields in Acrobat and stop there. What they rarely cover is what a screen reader says when it lands on each field, how to test a form the way a real user moves through it, and when a form shouldn’t be a PDF at all.
Why PDF forms are harder to make accessible than other documents
A form isn’t just read; it’s operated. A text document only has to be announced in the right order. A form also has to tell the user what each field is for, which fields are required, what format an answer needs, and which option they’ve selected, and it has to let them move between fields with the Tab key in a sensible sequence. Each of those is a separate thing that can fail, and most of them are invisible on the printed page.
That’s also why form pages sit at the top of most remediation price lists. PDF remediation services typically price per page, and pages with forms, complex tables, or charts cost several times more than plain-text pages, because each of those elements has to be set up and checked by hand.
Eight common PDF form failures and their fixes
Each of these is easy to miss on screen and hard to get past with a keyboard or a screen reader.
| What goes wrong | What a screen reader user experiences | What works |
| Field has no tooltip | The field is announced by its internal name, such as “Text Field 14,” or with no name at all | Write a tooltip for every field that matches its visible label, such as “Student number” |
| Tab order jumps around the page | Focus moves from the name field to the signature line, then back up | Set the page tab order to follow the document structure and then confirm it matches the visual order |
| Fields exist but aren’t tagged | Fields can be reached but aren’t tied to the surrounding instructions | Make sure each field is included in the tag tree, in reading order, next to its label |
| Radio buttons aren’t grouped | Each option is announced as a separate, unrelated question | Put all options for one question in a single radio button group |
| Required fields marked only by a red asterisk | Nothing indicates the field is required | Mark the field as required in its properties and say “required” in the label and tooltip |
| Date or student number format shown only as gray hint text | The user doesn’t know the expected format until an error appears | Put the format in the tooltip, for example “Date of birth, MM/DD/YYYY” |
| Errors shown only by color or a vague alert | The user can’t tell which field failed or why | Name the field and the problem in the error text itself |
| Scanned form with no real fields | There’s nothing to fill in, only an image of a form | Rebuild the form with real, labeled fields rather than tagging the scan |
WCAG requirements for fillable forms
Five Web Content Accessibility Guidelines (WCAG) success criteria cover the core of form accessibility. Every field needs an accessible name and role (4.1.2); labels or instructions must be provided (3.3.2); focus order must be logical (2.4.3); errors must be identified in text (3.3.1); and color can’t be the only way meaning is conveyed (1.4.1). All five are Level A criteria, so every WCAG 2.1 Level AA conformance claim includes them. For PDFs specifically, the PDF/Universal Accessibility standard adds that form fields must be part of the document’s tag structure, not just sitting on top of the page.
How to fix an existing fillable PDF form
The same PDF accessibility remediation steps apply to almost every form, in this order:
- Check whether the form has real fields. If it’s a scan or a flattened file, rebuild the fields before anything else.
- Give every field a tooltip that matches its visible label and includes any required format.
- Group radio buttons and related checkboxes so each question is announced once.
- Mark required fields in their properties and in the label text.
- Confirm every field is tagged and sits in the reading order next to its label and instructions.
- Set the tab order to follow the document structure and then walk it by hand to confirm it matches the page.
If the form started life as a scan, this is PDF remediation in the fullest sense: the fields have to be built from scratch, so the source file, if one exists, is almost always the better place to start.
Testing a form the way a user completes it
Automated checkers confirm that tags and tooltips exist; they can’t tell you that a tooltip says “Field 3” or that the Tab key skips the signature date. A five-minute manual pass catches most of what matters:
- Put the mouse away and complete the entire form using only the Tab, Shift+Tab, Space, and arrow keys.
- Turn on a screen reader, such as NonVisual Desktop Access on Windows or VoiceOver on a Mac, and listen to what each field announces as you land on it.
- Submit the form with a required field left blank and check whether the error says which field and why.
- Run the PDF Accessibility Checker or Acrobat’s accessibility checker last, to catch structural problems the manual pass didn’t surface.
PDF forms versus accessible web forms
High-volume forms that are submitted online are often better as accessible web forms.
| Consideration | Fillable PDF form | Accessible web form |
| Works well with screen readers and mobile devices | Depends on the PDF reader the user has | Generally more consistent across browsers and devices |
| Needs to be printed, signed, or archived as a fixed document | Strong fit | Possible, but needs a separate printable version |
| Updated often (deadlines, fees, program names) | Each update risks breaking field setup and tab order | Easier to update without redoing accessibility work |
| Submitted online and processed digitally | Adds a download-fill-upload step | Usually the better choice: fewer steps and no dependence on a PDF reader |
First steps for admissions and financial aid offices
- List every form a student must complete to apply, enroll, or receive aid, and start there rather than with the full document library.
- Run the five-minute keyboard and screen-reader test on the top five forms by volume.
- Decide, form by form, whether it should stay a PDF or move to an accessible web form.
- Fix the source file for any form that stays a PDF, so the next year’s version is accessible from the start.
A form is often the first thing a student does with an institution, and sometimes the last if it can’t be completed.
If your forms backlog is bigger than your team can test by hand, ContentA11Y remediates fillable PDF forms with every field checked by keyboard and screen reader rather than left to auto-detection. We can review a few of your highest-volume forms at no cost and show you which of these failures they contain before you budget for the rest.