(Office of Accessibility): Creating accessible forms: From choosing a tool to testing a PDF

Minnesota IT Services sent this bulletin at 08/27/2026 08:00 AM CDT

Having trouble viewing this email? View it as a webpage

Digital Accessibility News

From the Office of Accessibility at Minnesota IT Services

Illustration of three people considering a forms decision tree between a web form and a fillable PDF.

Choosing the right tool for accessible forms: When a fillable PDF makes sense

When your team creates a digital form for employees or the public, it may be tempting to begin by asking, “Should we use an online form or a fillable PDF?” Instead, begin by considering who will use the form and what they need to accomplish.

Consider the form’s purpose and audience, required features, security and data needs, maintenance, and investment. Accessibility should be part of each of these considerations from the beginning. The answers can help guide you toward the tool—or tools—that best fit your needs.

Sometimes, that choice will be a fillable PDF. And that’s OK! Learn when a fillable PDF makes sense and use our decision checklist and grid to help your team choose the right approach.

Illustration of a person testing a form on a desktop computer, holding a pencil and raising their hand to their eyes

Tech Tip: Testing Your Fillable PDF Form for Accessibility: Part 1

The August 2026 article “Decision-making process to create forms” covers how to select the most appropriate form publishing tool for your form. This tech tip dives into how to test your form for accessibility, specifically when you have a fillable PDF that will be used digitally.

We will focus this first part on four common Web Content Accessibility Guideline (WCAG) Success Criterion (SC) issues State of Minnesota PDF remediators come across in simple PDF forms:

SC 4.1.2: Name, Role, Value
SC 1.3.2 Meaningful Sequence
SC 2.1.1: Keyboard
SC 2.4.3: Focus Order

This tech tip provides an intermediate- to advanced- level understanding intended for teams producing and/or remediating fillable PDFs.

If you have limited experience with PDF remediation, work with a specialist at your organization, take training before making considerable changes, or consider hiring a vendor.

Why accessibility testing is critical in PDF forms

PDFs are digital content. When people complete a fillable PDF electronically, the form must be accessible. Accessibility testing helps confirm users who rely on assistive technology (AT), such as screen readers, screen magnifiers, and speech recognition software, can use a fillable form without barriers.

Automated checkers can identify some accessibility issues, but they cannot fully tell you whether a person can understand and complete a form. Manual testing by someone who understands accessible PDF remediation:

Verifies the automated test results.
Identifies issues that automated tools may miss.
Confirms that the form works as intended.

Testing preparation and implementation

To test a fillable PDF, review its layout, tag structure, reading order, and field properties using a combination of automated and manual tools. We’ll start with the software and tools you’ll need, then cover the specific testing practices.

Testing tools

Software and automated checkers

For this article, we use Adobe Acrobat Pro’s (Acrobat) “Prepare a form” tool and “Accessibility tags” function to inspect and remediate the form. Acrobat is widely available to State of Minnesota employees. If you use another PDF authoring or remediation tool, the specific steps may differ, but the testing concepts should still apply.

*Please note, some form functionality solely depends on the software, both for form creation and form remediation. We will focus on what is in the remediator’s control for this article.

Manual testing

Automated checkers alone cannot confirm accessibility, so manual testing is essential. Use the keyboard as the primary tool to test these success criteria.

If possible, we recommend running a check with a screen reader* to verify the remediation work. Use a full-featured screen reader software, like NVDA or JAWS, to read through the form both in reading mode and in interactive mode, ensure labels and instructional text are read, and no content is skipped or repeated .

*Important note: Screen reader testing for accessibility requires training and experience. This article provides an overview of what to look for, but it does not replace formal training. If you’d like to learn more about screen reader testing training, here are some options to check out:

Deque University: An Introduction to Screen Readers
Vispero’s JAWS Inspect software
For MN State employees only: Office of Accessibility extranet screen reader testing guidance.

Test 1: SC 4.1.2 Name, Role, Value

What to confirm

Each form field can be understood by AT. AT announces the correct role (e.g., text input field, check box, radio button, combo box, list box, and button) and the name, state, and value associated.

Notes from the WCAG Understanding SC 4.1.2 page:

A particularly important state of a user interface control is whether or not it has focus. The focus state of a control can be programmatically determined, and notifications about change of focus are sent to user agents and AT. For example, whether or not a check box or radio button has been selected.
This test checks whether the field is correctly identified by AT.

How to test

1. From Acrobat’s All tools bar, open the Prepare a form tool.

screenshot of Acrobat's All tools panel with Prepare a form highlighted.

2. From the Fields panel, inspect each form field’s type and properties.

screenshot of the Fields panel with the list of active form fields, which can be edited or deleted.

2a. Form types are identified in the Fields panel as text input, radio button, check box, etc.
- Note: In Acrobat the role for form controls is set automatically.

3. Right click (Shift + F10) on an item from the Fields list to select its Properties.

screenshot of Fields>Properties option as described in the text.

4. In the field Properties, view the General tab to:

4a. Verify Name field autofill content.
4b. Verify Tooltip field has content. This is the content which AT reads to users. The Tooltip must match the text presented visually. You can add text to provide additional visual form field details.

4c. Example 1: Visible text on a text input field type is “Text2” with a visible text field title of “Why?” The Text Field Properties within the General Tab are: Name: “Text2” and Tooltip: “Why?” It informs AT that it is a text input field, and they are answering the question “Why?”

screenshot of Properties>General Tab's Example 1 as described in text.

4d. Example 2: Visible text on a check box field type is “Check Box_1” with a visible field title of “Oakdale Nature Center.” The Check Box Properties within the General Tab are: Name: Check Box_1 and Tooltip: “Oakdale Nature Center.” It informs AT that it is a check box input and they are selecting the answer “Oakdale Nature Center.”

screenshot of Properties>General Tab's Example 2 as described in text.

5. In the Options tab:

5a. For Check Box Properties: Although not a requirement, changing Check Box Style to “Cross” helps AT understand it better. AT often misreads other styles.
5b. Verify that any Default Value or Export Value matches the form's intended behavior.
- For example, a text field that requires the user to enter their personal information should generally remain blank (which means the form opens with blank fields), and therefore its text field Default Value will also be blank. If an organization wants a text field set with a predetermined response, like a text field with the organization’s name and address entered (which means the form opens with these fields already filled in), then its text field Default Value will contain the same text as the visual text.
5c. For Text fields: Ensure “Scroll long text” is unchecked (as it is checked by default).

5d. Example 1: Visible text on a text field type is “Text2” with a visible field title of “Why.” The Text Field Properties within Options tab is: Default Value: blank (no text) and “Scroll long text” option is unchecked. It informs AT the text field is blank until filled in by the user. And it will have a multi-line capability without a text scroll.

screenshot of Properties>Option Tab's Example 1 as described in text.

5e. Example 2: Visible text on a check box field type is “Check Box_1” with a visible text field title of “Oakdale Nature Center.” The Check Box Properties within Options tab is: Check Box Style: Cross and Export Value: “Yes” and “Check box is checked by default” option is unchecked. It informs AT the check box is blank until selected. And when the answer is selected, it implies it is a “Yes” response (value) from the user.

screenshot of Properties>Option Tab's Example 2 as described in text.

If possible, run a check with a screen reader to verify the remediation work. Check:

In reading mode, can you understand the form’s content, labels and instructions when they are read aloud, especially without the form’s visual cues?
In interactive mode, when you enter a form field, does AT identify the field correctly and communicate its name, role, value, and state?

Common barriers

Improperly named form fields.
Blank tooltips.

Fixing barriers

Ensuring Name field is appropriate.
Adding appropriate Tooltip.

Verify changes

If making any changes, make sure to manually test the form again. If you used a screen reader during initial testing, run the same checks again.

WCAG References