Use fillable form fields instead of flat text
A form distributed as a PDF has to contain real interactive controls, not printed lines and boxes to write on. W3C's aim for this technique is keyboard operation, that people relying on the keyboard can recognize the fields, understand them, make selections, type, and submit. PDF supports six control types for the job. Text field, check box, radio button, combo box, list box, and button. W3C publishes PDF23 as a sufficient technique for keyboard access. Conversion is the thing to watch, because a document built with form features in another application might not keep its fillable fields on export, and W3C singles out complex forms as the ones that lose fields and labels. Acrobat Pro's Prepare Form tool detects and creates them.
How we find it in an audit
We try to complete the form with a keyboard and screen reader. If Tab finds no fields, the form is flat and fails at the first step. Where fields exist, we check each one is a real labeled control rather than a drawn box with nothing behind it, and we pay closest attention to forms that were converted from another format, because that is where fields go missing without anything looking different on the page.
How affected users experience it
A flat form is a dead end. Nothing to tab into, nothing to type into, no way to make a mark on the signature line. Someone who is blind is left printing a document they cannot see and filling it in by hand, or asking another person, which on a medical or financial disclosure means giving up privacy just to answer a form.
Passes vs. fails
Passes
The intake form is rebuilt with Acrobat Pro's Prepare Form tool. Labeled text fields, real checkboxes and radio groups, and a logical tab order, so it can be completed start to finish without a mouse or a printer.
Fails
A clinic's intake form is a PDF of underscores and empty checkboxes. Keyboard and screen reader users cannot enter a single character anywhere.
How this gets tested
The W3C publishes test rules that define what a checker looks for here.
- Iframe with interactive elements is not excluded from tab-orderA tool can check this
- Scrollable content can be reached with sequential focus navigationA tool can check this
Other ways to satisfy this rule
13 guides on this site are filed under 2.1.1 Keyboard. W3C lists this one as sufficient for that rule when used for ensuring keyboard control, so the condition is part of the test rather than a footnote to it.
- G90sufficientPair every event handler with keyboard support
- G202sufficientMake every control work with a keyboard
- H91sufficientUse native HTML controls instead of rebuilt ones
- PDF3sufficientFix the reading and tab order in PDFs
- PDF11sufficientTag PDF links so they are announced
- SCR2sufficientPair every mouse handler with a keyboard one
This guide is our interpretation of W3C technique PDF23: Providing interactive form controls in PDF documents. W3C publishes its techniques as guidance rather than as the standard, and says so on every one of them. The success criterion is what conformance is measured against, and a technique is one documented way to meet it.