Accessible HTML Forms
What is HTML form accessibility?
HTML form accessibility is the practice of building web forms so that all users—including those using screen readers, keyboard-only navigation, or voice recognition software—can understand, fill out, and submit data successfully. At its core, it requires that every form element is programmatically linked to its purpose, ensuring that instructions and requirements are as clear to an assistive technology as they are to a sighted user. This alignment is central to WCAG 2.1 Success Criterion 3.3.2, which mandates that labels or instructions must be provided whenever a user is required to input data, ensuring the form's purpose remains clear, regardless of how it is accessed.
Why is it important?
Web forms are vital gateways to NC State University Libraries’ collections, spaces, and services. Whether a student is requesting a research consultation, a researcher is booking a high-tech visualization space, or a community member wants to view a rare manuscript, these forms are fundamental to how our community uses our resources.
When an HTML form is inaccessible, that access point is effectively locked for users who rely on assistive technologies. Ensuring every form element is programmatically accessible is a matter of academic equity and functional reliability.
How can I test form accessibility?
Automated testing
Usage of automated testing tools are great at catching errors that make forms inaccessible. The WAVE browser extension provides a visual overlay that flags common form issues.
Manual keyboard testing
Automated testing can catch many errors but is limited when it comes to catching certain errors, particular issues testing keyboard functionality. An important way to test keyboard accessibility is manually testing whether you can complete the form only using your keyboard:
- Does focus move through the fields in the logical order of the form?
- Can you toggle checkboxes, select radio buttons, and trigger the “Submit” button without the mouse?
- If the form has a date picker or a custom dropdown, can you close it by hitting escape?
These are examples of issues that can only be tested manually. For more in-depth information, view our Keyboard Accessibility guide.
Screen reader testing
Using VoiceOver on Mac, NVDA on Windows, or Orca on Linux, to verify that labels, types, instructions and error messages are clearly announced. This manual check ensures that the information provided to assistive technologies is not only present but also concise and logical within the form’s context.
What are the common issues?
Form instructions
Instructions must be clear and programmatically connected to the input they describe. If a field requires a specific format (e.g., a Unity ID or a date), that hint should be linked using the aria-describedby attribute. This ensures that the instruction is read automatically when the user focuses on the field, rather than being skipped by a screen reader.
Additionally, the help text should appear between the question/label and the input area, so that the help text is read before the user is asked to fill in their response.
How can I fix this?
Use aria-describedby to programmatically link your hint text to the input.
Order and structure
The visual layout of a form should match the underlying HTML source code. If the code is out of order, keyboard users will find their "tab order" jumping unpredictably across the page.
How can I fix this?
Ensure the HTML source code follows the visual flow.
Do not use tabindex values greater than 0.
Related inputs should be grouped using <fieldset> and <legend> tags to provide necessary context to non-visual users.
Missing form labels
Every input must have a corresponding <label> element.
A common error is using "Placeholder" text as a label. Placeholders often disappear when the user starts typing and lack sufficient color contrast.
How can I fix this?
A correctly implemented <label for="ID_MATCH"> ensures that the purpose of the field is always accessible and provides a larger clickable target for users with motor impairments.
Example:
<label for="email">Email address</label><input id="email" name="email" type="email">
Required fields
Indicating a mandatory field using only color (like a red border) or a symbol (like an asterisk) is insufficient.
How can I fix this?
For a form to be accessible, the "required" status must be communicated via text and reinforced programmatically using the required or aria-required="true" attributes.
Placeholder text
Placeholder text is sometimes used in place of visible labels or form instructions, but this creates accessibility issues. Placeholder text disappears when a user begins typing, which can make it difficult to review or correct an answer. It also often has lower color contrast than regular text and may not be announced consistently by assistive technologies.
How can I fix this?
Avoid using placeholder text whenever possible. Instead, provide a persistent visible <label> for every form field. When providing instructions, do not rely on the placeholder attribute; provide the instructions as visible text near the form control and associate them with the field using the aria-describedby attribute.
If placeholder text must be used, make sure it is supplemental and not the only source of important information. Placeholder text must also meet WCAG SC 1.4.3 contrast requirements, with a contrast ratio of at least 4.5:1 against the background.
Providing adequate time and submission review
Users must be given enough time to complete their tasks without unexpected timeouts. For high-stakes interactions—such as booking a visualization lab or submitting a research request—it is essential to provide a way for users to review and correct their data before the final submission. This prevents errors caused by assistive technology misinterpretations or cognitive load.
How can I fix this?
If a session timeout is necessary (e.g., for security), provide a warning 2–3 minutes before the time expires with an option to extend it. For submission review, provide a "Review Your Request" screen that displays input in plain text before the final "Confirm" button.
Other resources
- W3 tutorial
- Yale Usability & Web Accessibility Guide
- Harvard Accessibility Guide (includes information about Qualtrics, Google, Microsoft, and PDF Forms)