Accessible HTML Form Errors with Labels and Descriptions

A form error should explain what went wrong and how to correct it. Color alone is not enough, and a placeholder disappears as the user types. Accessible forms connect each control to a persistent label, useful instructions and an error message that assistive technology can discover.

Associate the label with the input

Use a unique id on the control and a matching for attribute on its label. Keep a visible label even if the layout includes an icon. The example uses an email field, but an email-shaped value still needs server-side validation appropriate to the application.

<form>
  <label for="email">Email address</label>
  <p id="email-help">Use an address where you can receive replies.</p>
  <input id="email" name="email" type="email" required
    autocomplete="email" aria-describedby="email-help email-error" />
  <p id="email-error"></p>
  <button type="submit">Send request</button>
</form>

Expose an error when validation fails

When your validation logic finds an error, place a specific message in email-error and set aria-invalid="true" on the input. Remove the invalid state when the error is corrected. aria-describedby connects the error to the field; it is not a guarantee that newly inserted text is announced immediately.

Plan notification and focus behavior

For a longer form, an error summary near the top can link to invalid fields after submission. Move focus deliberately to the summary or the first invalid field according to the interaction design. A live region can announce changes when needed, but avoid repeatedly announcing the same error on every keystroke.

Keep client and server rules aligned

Browser validation helps users recover quickly, but the server remains responsible for accepting or rejecting a submission. Preserve user-entered values when presenting server errors. Do not treat a generic request failure as proof that the email field is wrong; a network failure needs a different message.

Test without relying on sight or a mouse

Navigate with Tab, activate the submit button with the keyboard and confirm focus remains visible. Check the accessible name and description in browser developer tools. Test zoom and narrow widths, and verify that error text is readable without red coloring. Automated audits help, but they do not replace interaction testing.

Practice and check your understanding

Add a required subject field and create an error summary with links to both fields. Submit an empty form, correct one field and submit again. Confirm the remaining error is specific and entered values remain intact.

Continue learning

Explore the related Code Hacker course syllabus for structured learning. Then read Responsive CSS Card Grids with minmax and auto-fit to connect this exercise to the next skill.

Reference

WAI forms notifications tutorial provides the underlying API or technical guidance. Check the documentation for the version you use; examples here are small learning exercises rather than complete production implementations.