Form Accessibility
This help article outlines why thoughtful form design is critical to accessibility and usability, how to ensure forms are accessible, and where form design may be most relevant.
Forms consist of interactive elements, designed for user input or submission such as text boxes, checkboxes, radio buttons, or dropdown lists.
Table of Contents
Why is Form Accessibility So Important?
For a form to be accessible, users, including those who may be using adaptive technologies or only a keyboard, must be able to:
Navigate all fields
Determine if a field is required,
Fill or respond to all fields
Understand and resolve any errors
Submit the form without using a mouse.
How Do I Make Form Fields Accessible?
Adobe Sign, Foxit PhantomPDF, and OnBase, tend to provide more back-end control over form elements and tab order than survey tools like Google Forms or Qualtrics. Regardless of the program, it is critical to:
Review any available accessibility guidelines
There may be specific criteria regarding which question types are more accessible.
Ensure all directions and cues are accessible
This means that you will need to test form functionality using only a keyboard.
Clearly identify any required form elements
Only make a field required if it is necessary.
Tab Order
Tab order (also called focus order) is the order content is accessed in. When engaging with a digital form, users should be able to use the tab key to select each interactive element. A logical, sequential tab order allows content to be more accessible, particularly for people with cognitive disabilities and visual impairments. You can test the tab order of your form by opening your form and using the Tab key on your keyboard to navigate through each interactive element.
Error Recovery
When a user attempts to submit a form and a required field is empty or filled out incorrectly (i.e. a form field contains a name instead of a date), the form should intuitively and accessibly inform the user of any errors and provide clear guidance on how to remediate those errors.
Form Labels
Form labels programmatically describe a form field to a user (i.e. a text box intended for the user’s first name would be labeled “First Name”). While a sighted user may be able to visually identify a form field’s associated instructions, a screen reader user, typically navigates through interactive fields via the Tab key, and thus identifies each form field by its label only.
In Adobe Acrobat Pro and Foxit PhantomPDF, form labels are applied using unique, descriptive tooltips.
For information about form labels in Adobe Acrobat, refer to Adobe’s PDF Form Fields support article.
For information about form labels in Foxit PhantomPDF, WebAIM’s Foxit and PDF Accessibility support article.
For more detailed instructions on how to design a fully accessible form using complex controls and labeling, please refer to WebAIM’s article on Creating Accessible Forms.
Where might I encounter form fields?
The following tools for generating forms are officially supported by OIT.
Please note that while it is possible to generate accessible forms using each of the following tools, it is also possible to generate largely inaccessible forms. Not all question types are fully accessible; thus, you should manually test all interactive elements without a mouse for both navigability and utility.
Adobe Sign
(for external-facing information gathering that requires validation)
Adobe Sign can be used for PDF forms and web forms. There are a wide variety of accessibility tools and support resources for PDF forms, and the same principles apply to web forms. You can start by checking out the Validation Checkpoints for Forms in our help article on Accessibility for Non-HTML Content.
To ensure that your Adobe Sign PDF or web form is as accessible as possible to all users, you still need to manually test the accessibility and navigability of your form fields with a keyboard.
For more information on when and how to use Adobe Sign for web forms, please refer to the OIT Service Catalog entry for Adobe Sign.
Google Forms
(for internal-facing information gathering that does or does not require validation)
Google Forms has some built-in support and shortkeys for screen reader users, and form elements relatively simple. It is entirely possible to generate an accessible form in Google Forms when following the accessibility best practices outlined in this article for tab order, error recovery, and form labels.
To ensure that your Google Form is as accessible as possible to all users, you will need to manually test the accessibility and navigability of your form fields with a keyboard.
For more information on when and how to use Google Forms, please refer to the OIT Service Catalog entry for Google Forms.
OnBase
(for internal-facing information gathering that requires validation)
OnBase does not currently offer any accessibility documentation or validation support. However, like other fillable form solutions, it is entirely possible to generate an accessible form when following the accessibility best practices outlined in this article for tab order, error recovery, and form labels.
To ensure that your OnBase form is as accessible as possible to all users, you will need to manually test the accessibility and navigability of your form fields with a keyboard.
For more information on when and how to use OnBase, please refer to the OIT Service Catalog entry for OnBase.
Qualtrics
(for internal or external-facing information-gathering that does not require validation)
Qualtrics offers a Check Survey Accessibility Tool that can detect a number of accessibility issues. To ensure that your Qualtrics form or survey is as accessible as possible to all users, you will still need to manually test the accessibility and navigability of your form fields with a keyboard.
There are some question types that are not fully accessible to screen reader users. With this in mind, Qualtrics details Question Type Accessibility for your convenience.
For more information on when and how to use Qualtrics, please refer to the OIT Service Catalog entry for Qualtrics.
University Policy Connection
Using properly formatted forms is a critical step in complying with Web Content Accessibility Guidelines (WCAG) 2 per Portland State University’s Digital Accessibility Policy. Please reference the following World Wide Web Consortium help articles for more information:
If faculty or staff have any additional questions regarding digital accessibility for public-facing digital resources at PSU, please email help-accessibility@pdx.edu or submit a Digital Accessibility Support ticket.