Create and publish a fillable PDF form
Turn a structured source into an interactive PDF form with labeled fields, predictable keyboard order, clear instructions, and a tested alternative path.
Decide whether PDF is the right form
Ask the website team about an HTML form when the task needs validation, status updates, repeated submissions, or mobile use. A fillable PDF may suit an approved signature workflow or print-ready record. Agree the format with the form owner before changing an established process. Provide an accessible HTML or Word alternative when the PDF cannot support the task. A scanned page with blank lines is a static document, not a fillable form.
Start with the source file and the task instructions. Define each field's purpose, type, required state, allowed format, and what happens after submission. Group related questions and explain abbreviations before the user reaches the first field.
BuildLACCD example
The public DES-0003-A1 Project Design Coordination Checklist presents cover-sheet lines and visible YES, NO, N/A boxes across a 21-page checklist. Printed lines and drawn boxes are not automatically interactive fields. Verify the exact current download in Acrobat and provide an equivalent alternative if people cannot complete the checklist with their chosen tools.
Label and structure every control
Use a real text label for every text field, checkbox, radio button, list, combo box, and button. In Acrobat, set a concise tooltip that says what to enter, not just an internal field ID. Use distinct field names, set the correct control type and required or optional state, and group radio buttons under one question. Include the controls in the tag tree and set the tab order to follow the visual and instructional sequence. W3C's PDF techniques call for interactive controls, labels, required-state information, and name, role, and value information.
Instructions must not live only in placeholder text, color, a symbol, or an underline. State the expected format before the field, such as “Project ID, 8 digits,” and give errors in text that identifies the field and explains how to fix it. Do not make a signature image or a drawn checkbox the only input mechanism.
Build from a tagged source and preserve the record
Prepare headings, lists, tables, figures, and link text in the authoring file, then export a tagged PDF. In Acrobat Pro, use Prepare Form or the form-field recognition tool as a starting point, then inspect and correct each field. Set the PDF title and language, allow assistive technology in security settings, and keep the editable source and a change note with the PDF.
For forms that will be reused, maintain a stable form ID and revision label in the file and on the landing page. If the form is signed or a record, preserve the original and publish a clearly identified accessible copy only through the responsible records process. Do not flatten an interactive form until the workflow explicitly calls for a static record.
Test the complete form task
- Run Acrobat Pro Accessibility Checker or Full Check, resolve failures, and investigate warnings. This is a defect list, not a conformance certificate.
- Use only the keyboard to reach every field, move between grouped controls, enter values, correct an error, and activate the submit or save action. Confirm visible focus and a logical tab order.
- Have a reviewer use a screen reader to complete the representative task and confirm each field's label, role, state, value, and required instruction. An accessibility API or field-property inspection can support this review, but does not replace the user task. Reopen the saved file and verify values persist.
- Check zoom and reflow separately, then compare a text extraction sample with the visual page. Check contrast, dates, numeric formats, calculations, and any conditional fields. Test the HTML, Word, or other alternative with the same task.
Ask for specialist review when the form has conditional logic, nested tables, signatures, complex calculations, sensitive records, or a high-consequence deadline. Record the file URL, form ID, revision, tools and versions, pages and fields tested, result, unresolved barrier, and next review date.
Publish with clear format and status
On the library page, give the form ID, title, confirmed revision or effective date, file type, size, and language. Say whether a PDF is fillable only after testing it. A useful label is “CP-0100 Request for Information (Word),” with the verified revision beside it. Do not call every form a PDF or use a row of links that all say “Download.” Offer the accessible alternative beside the PDF when available.
When a form changes, replace the canonical link deliberately, update the revision metadata, and check old direct links. Mark a retained prior edition as archived and not for current submissions. Do not silently leave multiple revisions that look current, and do not call a form accessible solely because an automated checker reports no errors.
Before you publish
Check each item as you review. These marks last for this page visit only.
Sources and standards
Related WCAG criteria: 1.3.1 Info and Relationships; 2.1.1 Keyboard; 2.4.3 Focus Order; 2.4.6 Headings and Labels; 3.3.1 Error Identification; 3.3.2 Labels or Instructions; 4.1.2 Name, Role, Value. This is a task-specific reference, not a complete conformance checklist.
- Adobe: Create and verify PDF accessibility with Acrobat Pro
- Adobe: Accessibility features in PDFs
- W3C WAI: PDF5, indicating required form controls in PDF forms
- W3C WAI: PDF10, providing labels for interactive form controls in PDF documents
- W3C WAI: PDF12, providing name, role, value information for form fields
- W3C WAI: PDF22, indicating when user input falls outside the required format or values
- W3C WAI: PDF23, providing interactive form controls in PDF documents
- BuildLACCD: Forms library
Guidance reviewed September 12, 2026. Tool interfaces may vary by version.