Accessible forms are essential for creating an inclusive digital experience, allowing users of all abilities to interact with your website effectively. From navigating with a keyboard to understanding form fields with screen readers, accessibility ensures that no user is left behind. This blog will guide you through the principles and best practices of creating accessible forms, complete with examples to help you implement these techniques seamlessly, enabling us to create accessible forms on websites.
Table of Contents
What is Form Accessibility?
Form accessibility refers to designing forms that are easy to navigate, understand, and complete for all users, including those with disabilities. Accessible forms ensure compatibility with screen readers, braille displays, and other assistive devices while addressing common usability challenges.
Key Principles of Accessible Forms
Clarity:
Labels and instructions should be straightforward, avoiding ambiguity. A clear structure ensures that users understand each field’s purpose.
Compatibility with Assistive Technologies:
Forms must support screen readers, braille displays, and other assistive devices.
Ease of Navigation:
Forms should allow smooth interaction using various input methods, such as keyboards, touchscreens, or voice controls.
Mobile-Specific Considerations:
- Ensure touch targets are large enough for easy interaction on small screens.
- Use responsive design techniques to maintain readability and usability across all device sizes.
- Avoid interactions that depend on hover effects, which are ineffective on mobile.
Key Elements of Accessible Forms
1. Labeling Forms
Labels provide essential information about the purpose of each form field, ensuring assistive technologies like screen readers can announce their function accurately. This is useful, especially when forms on-screen don’t have visible labels or aren’t providing enough information about their purpose or function.
Labels reduce errors and improve user experience by clarifying input expectations from users, particularly in complex forms. Labels also serve as consistent references, where placeholder text may be partially hidden by the on-screen keyboard during input, or disappear completely when typing in the input field.
Benefits of Using Labels:
- Clarity: Labels ensure users understand what is expected.
- Improved Navigation: Assistive technologies rely on labels to guide users effectively.
- Error Prevention: Labels reduce confusion, minimizing incorrect inputs.
Consequences of Not Using Labels:
- Users may abandon forms due to unclear input requirements.
- Screen readers may provide insufficient context, leading to a poor experience.
2. Required Attribute
The required attribute is crucial to make forms accessible, screen readers will announce which forms are required to be filled before submitting a form. This helps remove confusion when filling forms, for users to avoid dealing with error messages if a required field is not indicated programmatically.
Using a combination of an icon like the asterisk (*) or even including the word “Required” in the visible label will also help keyboard-only or users with cognitive disabilities to identify that they must fill out the form fields.
Example:
This example uses a <label> element with the for attribute to associate it with an input field. This ensures screen readers announce the label when focusing on the input.
The required attribute is added to the <input> element, indicating to screen reader users that the Username field must be filled.
<label for="username">Username:</label>
<input type="text" id="username" name="username" required>3. Grouping Related Forms
Forms with related inputs, such as a set of radio buttons, benefit from logical grouping. Using <fieldset> and <legend> provides context and structure, allowing screen readers to announce the group together. This improves usability, reduces cognitive load and frustration.
Benefits of Grouping Elements:
- Improved Context: Logical grouping clarifies relationships between inputs.
- Enhanced Navigation: Screen readers announce groups effectively, minimizing confusion.
- Streamlined Interaction: Logical sections reduce errors and improve user satisfaction.
Consequences of Not Grouping Elements:
- Related inputs may appear disconnected, confusing users.
- Navigation becomes more difficult, particularly for screen reader users.
Example:
This code groups related radio buttons within a <fieldset> and describes the group with a <legend>. This helps screen readers announce the purpose of the radio buttons.
We will also increase the size of the radio buttons top 24 by 24 pixels to meet WCAG size requirements for on screen elements.
<fieldset>
<legend>Choose your subscription plan:</legend>
<div style="display: flex; align-items: center; margin-bottom: 8px;">
<input type="radio" id="basic-plan" name="plan" value="basic" required style="width: 24px; height: 24px;">
<label for="basic-plan" style="margin-left: 8px;">Basic Plan</label>
</div>
<div style="display: flex; align-items: center;">
<input type="radio" id="premium-plan" name="plan" value="premium" style="width: 24px; height: 24px;">
<label for="premium-plan" style="margin-left: 8px;">Premium Plan</label>
</div>
</fieldset>4. Providing Descriptive Error Messages
Error messages help users identify and correct input mistakes. They should be clear, actionable, and programmatically tied to the corresponding input field using aria-describedby to provide more information if needed. Positioning error messages near inputs ensures they are visible and easy to understand, especially for mobile users. You can read more about accessible error messages in this article here.
Benefits of using Descriptive Error Messages:
- Actionable Feedback: Users can resolve issues quickly with clear instructions.
- Inclusive Design: Ensures all users, including those relying on assistive technologies, can complete forms successfully.
- Higher Completion Rates: Reduces form abandonment caused by confusion.
Consequences of Not Providing Descriptive Error Messages:
- Users may not understand why their input was rejected, leading to frustration and low completion rate of forms.
- Screen reader users might miss error information entirely.
Example:
Here, the <span> error message is tied to the Username input field using aria-describedby. Screen readers will announce the error message when the error occurs.
Javascript is used for input validation, if the field is empty, the error appears. If the input isn’t empty, the form submits.
<form>
<label for="username">Username:</label>
<input type="text" id="username" name="username" aria-describedby="username-error-message" required>
<span id="username-error-message" style="color: red;"></span>
<br>
<button type="submit">Submit</button>
</form>
<script>
const usernameInput = document.getElementById('username');
const usernameError = document.getElementById('username-error-message');
usernameInput.addEventListener('invalid', function (e)
{ e.preventDefault();
if (this.validity.valueMissing) {
this.setCustomValidity('Please enter your username');
usernameError.textContent = 'Please enter your username';}
else {
this.setCustomValidity('');
usernameError.textContent = '';}
});
usernameInput.addEventListener('input', function () {
this.setCustomValidity('');
usernameError.textContent = '';
});
</script>
Best Practices for Accessible Forms
Text Inputs and Text Areas
Text inputs are fundamental to forms and should include clear labels, placeholders, and helper text. The correct usage of the required attribute and aria-describedby improves accessibility for all users, and gives context to accessibility technologies about which forms must be filled before submission. Mobile users benefit from well-spaced fields and auto-expanding text areas, reducing the chance of accidental inputs.
Example:
In this example, we’ll add the required attribute to <textarea> to ensure the field is marked as mandatory to be filled before submission for assistive technologies, and aria-described by links helper text to the input field for additional guidance, especially for screen readers users.
We’ll also add a <label>
The required attribute can also be added to other HTML elements such as <input> and <select>.
<label for="comments">Comments:</label>
<br>
<textarea id="comments" name="comments"
aria-describedby="comments-help"
placeholder="Write your feedback here" required >
</textarea>
<br>
<span id="comments-help" class="help-text">Your feedback is important to us. Please limit it to 500 characters.</span>Checkboxes
It is highly recommended to use a clear and explicit <label> and use native HTML type=”checkbox” element for checkboxes. Note that <legend> should only be used when checkboxes are grouped with multiple form elements. . When checkboxes are grouped together, it is recommended to use <fieldset> and <label> to give context to the user.
Checkboxes should also have sufficient touch target size to improve usability, especially on mobile devices, ensuring users can select options easily without mistake. According to WCAG guidelines, the minimum recommended size for checkboxes should be 24 by 24 pixels.
Example:
In this example we’ll use <fieldset> to group related checkboxes. Each checkbox also has a <label> linked by the for attribute.
We’ll also increase the size of the checkboxes to 24 by 24 pixels.
<fieldset>
<div style="display: flex; align-items: center; margin-bottom: 8px;">
<input type="checkbox" id="daily-updates" name="preferences" value="daily" style="width: 24px; height: 24px;>
<label for="daily-updates" style="margin-left: 8px;">Daily Updates</label>
</div>
<div style="display: flex; align-items: center; margin-bottom: 8px;">
<input type="checkbox" id="weekly-digest" name="preferences" value="weekly" style="width: 24px; height: 24px;>
<label for="weekly-digest" style="margin-left: 8px;">Weekly Digest</label>
</div>
</fieldset>Dropdown Form Fields
Dropdown form fields should be using the native HTML <select> element and <option> elements. Since they’re natively supported and recognized by screen readers.
if a value is often selected by users or if there’s a recommended value to be selected. If not, setting the default state to “Select” or “Select an option” is good practice for accessibility.
According to WCAG guidelines, setting a default option for drop down menus isn’t mandatory, but it benefits user experience. As it requires less effort from users with disabilities and chances of error are reduced.
Unlike other components, native dropdown forms on mobile devices are generally accessible and user friendly by leveraging mobile gestures and feedback.
Example:
Here, we’ll associate the <label> element with the dropdown using the for attribute, and we’ll set the default value to “Choose a country” to provide guidance for users.
We’ll also increase the size of the drop down menu to 24 by 24 pixels to respect the minimum WCAG accessibility guidelines.
<label for="country">Select your country: </label>
<select id="country" name="country" required style="width: 200px; height: 30px; font-size: 16px;">
<option value="" disabled selected>Choose a country</option>
<option value="us">United States</option>
<option value="ca">Canada</option>
<option value="uk">United Kingdom</option>
</select>Buttons and Submit Controls
Buttons should feature descriptive text that clearly conveys their purpose. Buttons with clear accessible names like “Proceed to Checkout” are preferred over generic labels such as “Click Here”.
It is highly recommended according to WCAG guidelines to announce a status message to screen reader users after a form was submitted. This can be done by using the role=”status” or the aria-live=”polite” attribute.
Example:
In this example, when the button is clicked an informational feedback is displayed, and aria-live=”polite” is used to inform the screen reader of the change, which the screen reader then announces to the user.
<button type="submit" onclick="submitAction()" style="width: 74px; height: 24px; font-size: 14px;">
Submit
</button>
<p id="feedback" role=”status” style="margin-top: 10px;"></p>
<script>
function submitAction() {
document.getElementById("feedback").textContent = "Form submitted successfully.";
}
</script>Using ARIA Attributes for Enhanced Accessibility
ARIA (Accessible Rich Internet Applications) attributes improve accessibility by providing additional context for assistive technologies. While native HTML should be the first choice, ARIA can enhance user experiences where native elements fall short.
When to Use ARIA Attributes
- Custom Widgets: ARIA helps make non-standard form elements, such as custom dropdowns or sliders, accessible.
- Supplementing Native HTML: Use ARIA to add additional context (e.g., aria-describedby for helper text) when necessary.
- Dynamic Content: ARIA properties such as aria-live and role=”status” can clarify the status of dynamic form elements and announce it to users, such as expandable sections or buttons being clicked.
Best Practices with ARIA
- Use ARIA only where necessary—overusing it can add unnecessary complexity.
- Always prioritize native HTML solutions before resorting to ARIA attributes.
Conclusion
Careful consideration should be given to forms and submit controls, because they can affect a website’s general user experience and completion rate if not rendered accessible. Ensuring that forms are accessible benefits a wider audience not only users with disabilities. All while meeting WCAG and ADA compliance in the US.
