Hi everyone!
Today we're tackling another crucial and practical question in the "Questions & Answers" section: "How do I make my forms accessible?" Forms are at the heart of interaction on many websites – for logins, registrations, purchases, contact. If a form is not accessible, users can be excluded from the ability to complete essential actions.
Form accessibility involves several WCAG criteria, primarily under the Operable and Understandable principles.
Key Components for Accessible Forms:
1. Properly Associated Labels:
Every input field must have a visible label that is programmatically associated with it. This allows screen readers to read the label when the field receives focus.
Code: Select all
<label for="username">Username:</label>
<input type="text" id="username">When a user makes an error:
- Visual Indication: The error must be clearly indicated visually (e.g., red border, icon).
- Textual Error Message: Provide a clear, specific error message explaining what went wrong and how to correct it.
- Focus Management: Shift focus to the error field or to an error summary to guide the user.
- Programmatically Accessible: Ensure error messages are announced by screen readers (often via aria-live or aria-describedby).
If a field requires a specific format (e.g., date: DD/MM/YYYY) or has particular requirements, instructions must be provided clearly and accessibly, before the user begins typing.
Code: Select all
<label for="dob">Date of Birth (DD/MM/YYYY):</label>
<input type="text" id="dob" aria-describedby="dob-format">
<span id="dob-format">Enter the date in day/month/year format.</span>Clearly indicate which fields are required (visually with an asterisk and programmatically, e.g., with aria-required="true" if you're not using HTML5 required).
Code: Select all
<label for="name">Name (required):</label>
<input type="text" id="name" required aria-required="true">As with all keyboard navigation, ensure that focus moves in a logical order between fields and that there is always a clear visual indicator of focus.
6. Custom Controls and ARIA:
If you create custom checkboxes, radio buttons, or dropdowns, make sure to use appropriate ARIA roles and states (role, aria-checked, aria-selected, aria-expanded, etc.) to replicate the accessible behavior of native controls.
7. Accessible CAPTCHAs:
Avoid CAPTCHAs based solely on distorted text or images. Offer alternatives (e.g., audio CAPTCHAs, simple questions, accessible reCAPTCHAs that don't require complex visual interaction).
How to Test Form Accessibility:
- Keyboard Test: Try to complete the entire form using only the keyboard. Can you move between all fields? Can you activate all buttons and checkboxes/radio buttons?
- Screen Reader Test: Fill out the form using a screen reader. Are the fields and their labels read correctly? Are error messages announced?
- Error Test: Submit the form with intentional errors to check error handling.
What have been your biggest challenges in creating accessible forms? Do you have specific tips or "tricks" for handling particular input types or validations? Share your experiences!
Warm regards,
Michele (wcgadmfrm)
WCAG Plus Forum Team