A form often determines whether someone completes a task or gives up. A polished offer and fast front end cannot compensate for a confusing contact, checkout, or registration form.
That is why form accessibility is not a minor detail. It is one of the most practical parts of WCAG.
Why forms are critical
Forms are where visitors move from reading to acting: sending a message, booking a consultation, placing an order, creating an account, or making a payment. Barriers at this point immediately lead to errors, abandoned journeys, lower conversion, and frustration.
A form must work for people using a keyboard, screen reader, or magnification, as well as people experiencing cognitive load, limited concentration, or stress.
Start with semantics
Correct HTML remains the best foundation. Use native elements such as label, input, textarea, select, fieldset, legend, and button.
Form controls need programmatically associated labels. A screen reader cannot infer a designer's intent from visual placement; it relies on DOM structure and semantics. See W3C WAI's guide to labeling controls.
Labels are only the beginning
When a field requires a particular format or has constraints, explain them before the user makes a mistake. This includes date formats, password requirements, required fields, and dependencies between fields.
Do not move those instructions into a placeholder. Placeholders disappear as soon as typing begins and should never be the only source of context.
Sources: Understanding SC 3.3.2 and Form Instructions.
Error messages must be specific
“This form contains errors” does not tell the user which field failed or how to fix it. A useful message says, for example:
- “Email address is required”
- “Enter a valid email address”
- “Password must contain at least 12 characters”
Associate the message with its field, commonly through aria-describedby, and ensure important state changes are announced to assistive technology. Color alone is not enough.
Focus and navigation order
Keyboard focus should follow the visual and logical order, remain clearly visible, and move only when there is a good reason. Avoid removing the browser outline without an equally visible replacement.
In React, problems often appear when rerendering removes the focused element or a custom widget looks like a form control without behaving like one. Test with a keyboard from the beginning, not just before release.
React does not replace the fundamentals
Build valid HTML first and style it second. Prefer native controls, present validation in text, and verify the final DOM rather than judging accessibility from component names.
Before launch, confirm that every field has a label, related controls use fieldset and legend, required fields are clear, errors explain the correction, the full form works from the keyboard, and instructions are available to screen readers.
An accessible form is not a premium version of a form. It is simply a well-designed one—and it is usually easier for everyone to complete.