Build an Accessible Contact Form
Combine labels, ARIA attributes, keyboard navigation, and color contrast to build a fully accessible contact form.
What we're building
In this capstone, you will combine everything from this module to build a fully accessible contact form. Contact forms are on almost every website — from Amazon's customer service page to your local restaurant's website. They look simple, but they are one of the most common sources of accessibility failures on the web. Missing labels, no error feedback, keyboard traps in custom dropdowns, low-contrast placeholder text, and missing ARIA attributes make forms unusable for millions of people.
Our contact form will have:
- A proper form structure with <form>, <fieldset>, and <legend>.
- Text inputs for name and email with visible <label> elements.
- A textarea for the message.
- Required field indicators that do not rely on color alone.
- A live region for form validation feedback (using aria-live).
- Proper focus management with visible focus indicators.
- A skip link to jump past the page header.
- Sufficient color contrast on all text.
- Semantic HTML landmarks wrapping the entire page.
By the end, you will have a form that a blind user can fill out with a screen reader, a motor-impaired user can complete with only a keyboard, a color-blind user can understand without confusion, and a sighted user finds clean and professional. This is what accessibility looks like in practice — it is not a separate layer of work, it is simply good HTML and CSS.
WCAG has multiple success criteria specifically about forms: 1.3.1 (Info and Relationships — labels must be programmatically associated), 3.3.1 (Error Identification — errors must be described in text), 3.3.2 (Labels or Instructions — inputs must have labels), and 4.1.2 (Name, Role, Value — all form controls must have accessible names). Our form will satisfy all of these.