Forms are among the most accessibility-critical UI patterns. They are the mechanism through which users complete transactions, authenticate, and provide information. Inaccessible forms create barriers that exclude users entirely. The most common form accessibility failures are preventable at the design stage.
Labels, not placeholders
Placeholder text is not a substitute for a visible label. Placeholders disappear when the user starts typing, are not announced consistently by all screen reader/browser combinations, typically fail color contrast requirements (3:1 is required for placeholders, and most implementations use values like #aaaaaa which fails), and are inaccessible to users who rely on cognitive aids that cannot display placeholder text. Every input needs a persistent, visible label positioned above (not beside) the field.
Error messaging that actually works
WCAG 3.3.1 requires that when an input error is detected, the item in error is identified and the error is described in text. This means: the error message must be in the DOM (not just a red border), must be associated with the input via aria-describedby, must be specific about what the error is, and must suggest how to fix it. "Invalid input" is not a sufficient error message. "Email address must be in the format name@example.com" is.
Associating error messages with inputs
<div>
<label for="email">Email address</label>
<input
id="email"
type="email"
aria-describedby="email-error"
aria-invalid="true"
/>
<p id="email-error" role="alert">
Enter a valid email address (e.g., name@example.com)
</p>
</div>Required fields
Required fields must be identified before the user attempts submission — not just after validation fails. The HTML required attribute adds native validation and screen reader announcement. For visual indication, use text ("Required") rather than relying solely on an asterisk (*), or include a legend explaining the convention at the top of the form. The asterisk convention is not universally understood and cannot be perceived by users with low vision who may miss the small symbol.
Input purpose and autocomplete
WCAG 1.3.5 requires that inputs collecting personal information expose their purpose via the HTML autocomplete attribute. This allows browsers and assistive technologies to help users fill in forms using stored information. It is particularly beneficial for users with cognitive disabilities or motor impairments who find text entry difficult. Common values: autocomplete="name", "email", "tel", "street-address", "postal-code", "new-password".
Tip
After form submission that results in errors, move focus to an error summary at the top of the form (or the first errored input) and announce the number of errors via a live region. Users who have tabbed past all the visible fields should not have to hunt for what went wrong.