How to Build an Accessible Contact Form
A beginner, hands-on guide to build an accessible contact form with browser inspection, exact code-level changes and verification.
By the end: You will implement and verify build an accessible contact form on a real local/staging page.
You will implement and verify build an accessible contact form on a real local/staging page.
Key terms before you start
These definitions make the steps easier to follow and help distinguish controls, files and concepts that can look similar at first.
What you need before starting
- A page you are allowed to edit
- Access to the HTML/CSS/JS or CMS/template that renders it
- A modern browser with Developer Tools
Step-by-step tutorial
Every step is shown below. Work through them in order and use each checkpoint to confirm the result before moving on.
Work on a local or staging copy
Open the project containing the website source. If this is a production site, use a staging copy or backup before structural changes.
A browser page is rendered from source files/CMS output; DevTools edits do not save back to the server.
Move it into the actual source and reload.
Open the page in a modern browser
Load the page, then press F12 or Ctrl+Shift+I (Windows/Linux) to open Developer Tools.
DevTools lets you inspect the DOM, applied CSS, computed sizes, requests and console errors.
Move it into the actual source and reload.
Create a form element
Wrap fields in <form> and set the real submission method/action handled by your backend/framework.
HTML alone does not deliver email without server/application handling.
Create a visible Name label
Use <label for="name">Name</label> and matching input id="name".
The for/id link gives the field an accessible name.
Use the email input type
Use <input type="email" ... autocomplete="email">.
Browsers can provide useful input/keyboard behavior and basic format validation.
Add a message label and textarea
Use a visible label plus <textarea>.
Do not rely on placeholder as the only label.
Move it into the actual source and reload.
Mark only truly required fields
Use required for fields the process cannot accept without.
Do not make phone mandatory if email is sufficient.
Move it into the actual source and reload.
Write specific error messages
On server/client validation, explain what needs fixing beside the field.
“Invalid input” is less useful than “Enter an email address”.
Preserve entered values on errors
Do not wipe a long message because one field failed.
Avoid forcing users to retype valid information.
Add a truthful success state
After successful submission, say it was received and what happens next.
Do not claim “we will respond in 1 hour” unless operationally guaranteed.
Test with keyboard only
Complete all fields and submit without mouse/touch.
This catches labels, focus order and inaccessible custom controls.
Move it into the actual source and reload.
Test the public/staging URL logged out
Open the final URL in a private/incognito window.
CMS/admin sessions can hide caching, permission or styling differences.
Check caching, loaded asset URL, theme/template and logged-out view.
Document the changed file/rule
Record the file/template/component and purpose of the change in the project notes or version-control commit.
Future maintainers should not have to reverse-engineer why a rule exists.
Check caching, loaded asset URL, theme/template and logged-out view.
Reload the real page and reproduce the result after all temporary DevTools edits are gone.
Concrete examples
Copyable example
<label for="email">Email address</label>
<input id="email" name="email" type="email" autocomplete="email" required>
<label for="message">Message</label>
<textarea id="message" name="message" required></textarea>
<button type="submit">Send message</button>Troubleshooting
Move it into the actual source and reload.
Check caching, loaded asset URL, theme/template and logged-out view.
Use the Styles/Computed panels to trace the final value instead of adding stronger selectors blindly.
The change has a traceable reason/location.
Continue with these tutorials
Documentation and references
Use these primary and supporting sources to verify current controls, browser behavior and product-specific details.