Forms are one of the most commonly failed accessibility categories in university digital content — and one of the most consequential. An inaccessible form can prevent a student from registering for a course, a job applicant from submitting an application, or an employee from completing a required process. Unlike a document, a form asks something of the user in real time, which means every interactive element — input fields, dropdowns, radio buttons, checkboxes, date pickers, and submit buttons — must work for keyboard-only users and screen reader users, not just mouse users.
The core requirements for accessible forms
Every form element must have a visible label that is programmatically associated with the input. Placeholder text is not a label — it disappears when the user starts typing and is not reliably announced by screen readers. If a field requires a specific format (a date, a phone number, a file type), that instruction must be visible before the user submits, not only after an error occurs.
Error messages must be specific, visible, and helpful. Telling a user "this field is required" is minimally useful. Telling them "Please enter your email address in the format name@louisiana.edu" is accessible. Error messages must also be announced to screen reader users — not just displayed visually.
All form controls must be reachable and operable by keyboard alone. Tab order must follow the visual sequence of the form. Dropdowns, date pickers, and custom components built with JavaScript require extra attention — native HTML elements are almost always more accessible than custom-built alternatives.
Microsoft Forms
Microsoft Forms is the most common form tool in use at UL Lafayette. It is generally accessible out of the box for simple forms, but has limitations for complex ones.
- Form questions automatically receive labels that screen readers can read — do not rely on placeholder text inside input fields as a substitute for the question label itself
- Use the "Required" toggle for any field that must be completed — this adds a visual indicator and programmatic requirement that assistive technologies can announce
- Avoid using images as the only way to convey a question or instruction — any image in a form must have alt text
- For forms that include a file upload field, ensure the label clearly states what file types and sizes are accepted
- Preview your form using keyboard-only navigation before publishing: Tab through every field, activate every dropdown, and submit the form without using a mouse
- Microsoft Forms generates a confirmation message after submission — ensure it contains meaningful text confirming what was submitted, not just "Your response has been recorded"
Known limitations: Microsoft Forms does not support custom error messaging — error text is standardized and cannot be edited. Complex branching logic and multi-page forms can create unpredictable keyboard navigation in some screen reader environments. Test these carefully before distributing widely.
Fillable PDFs
Fillable PDF forms present significant accessibility challenges and should generally be replaced with an HTML-based form (Microsoft Forms, Qualtrics, etc.) wherever possible. If a fillable PDF is necessary:
- Each form field must have a tooltip or label set in Adobe Acrobat Pro — this is what screen readers announce to users
- Tab order must follow the visual sequence of the form — verify this in Acrobat Pro under Tools → Prepare Form → Tab Order
- Required fields must be marked as required programmatically, not only with a red asterisk or color
- Submit buttons must be actual PDF form buttons, not images or graphics
- Run the full accessibility checker in Adobe Acrobat Pro before distributing — fillable PDF forms have their own category in the checker results
If you are distributing a form that a user must print, complete by hand, and return, that is not a fillable PDF — it is a paper form and a different accommodation process applies. Contact Disability Services for guidance.
Qualtrics
Qualtrics is used across UL Lafayette for surveys, feedback forms, and research data collection. It produces reasonably accessible output when used correctly, but requires deliberate configuration.
- Write clear, specific question text — avoid jargon, abbreviations, and ambiguous phrasing
- For matrix questions and rating scales, ensure column and row labels are meaningful on their own — screen readers read these combinations independently of surrounding context
- Avoid using graphics or custom visual elements as response options without text equivalents
- Use the Qualtrics accessibility preview to test your survey before distributing
- For research surveys that will reach participants with disabilities, test with a screen reader before launching
Review the Qualtrics support documentation on accessible surveys »
