Electronic forms are generally more accessible than paper forms, but they must be created carefully to ensure all users can interact with them. All form fields need clear labels, logical tab order, accessible error messages, and no mouse-only actions.
Overview
Electronic forms are generally more accessible than paper forms, but they must be created carefully to ensure all users can interact with them. All form fields need clear labels, the tab order must be logical and intuitive, error messages must be accessible to screen readers and keyboard users, and there must be no mouse-only actions or interactions.
Why this matters
Forms are critical interaction points on the web. Inaccessible forms prevent users from completing essential tasks like registering for accounts, making purchases, submitting information, and accessing services. Screen reader users depend on proper labels, instructions, and programmatic associations to understand what information each field requires and how to complete the form successfully. Users with motor disabilities require keyboard accessibility and logical tab order. When forms are inaccessible, entire groups of users are excluded from participating in important online activities.
Techniques for Word
It is not possible to create a fully accessible interactive form within Microsoft Word. If you need to create an interactive form, you must export the document to PDF format and then add form controls using Adobe Acrobat Pro. HTML forms are the preferred approach for creating accessible forms on the web.
Techniques for PDF
Creating accessible PDF forms is technically possible but requires specialized knowledge and skills. HTML forms are strongly preferred. If a PDF form is necessary, follow the guidelines below.
Creating New PDF Forms
- Do not use the authoring tool’s form features or form-building functionality
- Do not create a tagged PDF with form fields using the form features
- Use Adobe Acrobat Pro to manually detect and mark form fields
- Verify the tab order is logical and matches the visual reading order
- Verify that all labels and tooltips are present and descriptive
- Verify that radio buttons are properly grouped and labeled
- Verify that checkboxes are properly labeled and grouped
Checking or Repairing Existing PDF Forms
- Determine if the form is interactive with fillable fields
- Check if the tab order is intuitive and follows the visual layout
- Verify labels are appropriate and accessible to assistive technology
- Confirm radio buttons are grouped and labeled correctly
- Ensure checkboxes are properly labeled
- Finishing touches: create links, add tags, and perform a full accessibility check per Digital Documents
HTML
Using the <label> Element
Every form input should have an associated label. Labels should be explicitly associated with inputs using the for and id attributes:
<label for=”email”>Email Address:</label> <input type=”email” id=”email” name=”email” />
Explicit association of labels is critical because it allows screen readers to announce the label to users and expands the clickable area of the input for all users.
Supplemental Help Text
For additional information beyond the label, use the aria-describedby attribute to associate help text with the form input:
<label for=”password”>Password:</label> <input type=”password” id=”password” aria-describedby=”pwd-hint” /> <p id=”pwd-hint”>At least 8 characters</p>
Using <fieldset> and <legend>
For groups of related form inputs such as radio buttons or checkboxes, use <fieldset> and <legend> to associate a group label with the inputs:
<fieldset> <legend>Choose your favorite color:</legend> <input type=”radio” id=”red” name=”color” value=”red” /> <label for=”red”>Red</label> <input type=”radio” id=”blue” name=”color” value=”blue” /> <label for=”blue”>Blue</label> </fieldset>
Form Validation
Form validation ensures that user input is correct and complete. Validation can occur on both the client side (in the browser) and server side (on the server).
Client-Side Validation
HTML5 provides several input types and validation attributes:
- Input types: tel, url, email, date, number, etc.
- Attributes: required, pattern, min, max, step, etc.
When validation errors occur, ensure errors are announced to screen readers and keyboard users:
- Use role=”alert” to announce errors
- Position error messages immediately after the field
- Use tabindex=”0″ to allow keyboard focus on error messages
Server-Side Validation
Server-side validation handles data verification on the server. When errors occur:
- Change the page title to include the word “Error”
- Use prominent styling and color to highlight errors
- Include a heading that says “Error” or similar
- Provide specific, actionable error details
- Include same-page links to the fields that have errors
Form CAPTCHA
Traditional CAPTCHAs (Completely Automated Public Turing Test to tell Computers and Humans Apart) are inaccessible to users with visual impairments. Google reCAPTCHA v3 operates behind the scenes without user interaction. For more information on CAPTCHA accessibility challenges, see the W3C note on CAPTCHA. Contact the Digital Accessibility Services (DASH) Team for guidance on accessible alternative solutions.
Common mistakes
When creating accessible forms, watch out for these frequent accessibility issues:
- Missing form labels: Inputs without associated labels prevent screen readers from announcing what information is required. Always use the <label> element with proper for/id attributes.
- Using placeholder text as labels: Placeholder text disappears when users start typing, leaving them confused about what the field is for. Use visible labels instead.
- Missing error identification: Validation errors must be clearly identified for all users, not just announced to screen readers. Include specific, actionable error messages near the fields.
- No programmatic association between labels and inputs: Labels that are visually next to inputs but not properly associated using for/id attributes are inaccessible to assistive technology.
- Missing fieldset and legend for grouped inputs: Radio buttons and checkboxes must be grouped with <fieldset> and <legend> to communicate the relationship between options.
- Inaccessible custom form controls: Custom-styled inputs, switches, and dropdowns may not be keyboard accessible or properly announced by screen readers. Always test with assistive technology.
- No focus management after submission: After a form submission, focus should move to a confirmation message or next logical area. Leaving focus in place causes confusion.
Additional Resources
Related DASH Pages:
WCAG Criteria
Getting help
If you have questions or need assistance, the Digital Accessibility Services Hub (DASH) is available to support colleges, schools, and administrative units as they build sustainable accessibility practices.
- Contact DASH at [email protected] for consultations, training, or technical assistance.
- Visit the DASH training page for resources and learning opportunities.
Accessibility is a shared responsibility, and every step you take makes UGA’s digital environment more inclusive.