Forms, editing, legal pages and analytics
How do I set up contact forms, a CMS, legal pages and analytics on a client website?
Route form submissions to an inbox the client checks, pick the simplest editing option they will actually use, cover accessibility basics, add legal pages they have approved and load analytics only with consent where required.
What you will be able to do
Wire up a form that reaches the right inbox, pick an editing option the client will use, cover accessibility basics, add approved legal pages, and set up analytics that respect consent.
Before you start
- A site in progress, built as in Build with an AI coding assistant.
- The brief, with the person or inbox that handles the primary action. See Define the goal before the design.
- The Launch QA checklist.
The legal parts here are general information, not legal advice. Rules vary by place, and the client is responsible for their legal pages.
Why this matters
The form is where the site makes money. If submissions land in spam, go to an old address or fail on a phone, the site looks perfect and produces nothing.
Accessibility and legal pages protect the client and you. Analytics loaded without required consent can cause the client real trouble.
Step by step
Tick each step as you do it. Your ticks are saved in this browser.
Decide where form submissions go and how
Options: a form handling service, a serverless function that sends through a transactional email provider, or a booking or CRM tool the client already uses. Write the destination in the project instructions file.
Build the form with labels, validation and a clear thank you
Every field has a visible label. Ask only what the business needs to respond. Mark required fields in words, not only colour. Validate in the browser and again on the server. After submission, say what happens next: "We will call you within one business day."
Protect the form from spam without punishing humans
Add a hidden honeypot field and reject submissions that fill it. Add a captcha only if spam still gets through. Keep keys in environment variables, never in the repository.
Test delivery end to end, including spam folders
Submit from a phone on mobile data and from a desktop. Confirm the email reaches the real inbox. Ask the client to confirm in writing that they received a test.
Pick the simplest editing option that fits
Ask what the client will realistically change and how often.
- Nothing much, a few times a year: keep content in files and make the changes yourself under a maintenance plan.
- Hours, prices, a few photos: a small headless CMS or simple content file editor, with only those fields editable.
- Regular posts or many pages: a fuller CMS with fixed templates and limited fields so the layout cannot break. Whatever you pick, write a short guide for the handoff.
Cover the accessibility basics on every page
One H1 per page and headings in order. Real alt text on meaningful images, empty alt on decorative ones. Check text contrast. Every link and button works with the keyboard and shows a visible focus outline. Do not rely on colour alone for errors. Set the page language. WCAG "AA" is a sensible target for small business sites.
Add legal pages the client has seen and approved
Most sites need a privacy policy saying what personal data the site collects (form data, analytics, cookies), why and who it is shared with. Add a cookie notice if the site sets cookies that are not strictly necessary. Use a reputable generator or the client's lawyer with the client's real details, get written approval, and link the pages from the footer and near the form.
Set up analytics with consent where required
Rules depend on where visitors are and what the tool collects. Under GDPR and PECR style rules in the UK and EU, non essential tracking generally needs opt in consent before it loads. The safe pattern: load no analytics until the visitor accepts, make reject as easy as accept, and record the choice.
Track the one action that matters
Set up a single conversion event for the primary action, such as a successful form submission or a tap to call click. Test that it fires once per real action.
Run the forms and legal section of the launch checklist
Go through the forms, accessibility and privacy items on the Launch QA checklist and fix failures before the client review.
Example
A booking form prompt for the fictional Austin dental clinic.
Read CLAUDE.md and docs/brief.md first.
Build the booking form on /book.
Fields (all with visible labels):
* Your name (required)
* Phone number (required, type="tel")
* Email (optional)
* Who is the visit for? Adult / Child / Whole family (required, radio)
* Insurance provider (optional, free text)
* Anything we should know? (optional, textarea)
Behaviour:
* Submit to the serverless function in api/booking.js.
* That function sends an email to the address in the env var
BOOKING_INBOX, with reply to set to the visitor's email if given.
* Add a hidden honeypot field named "company". Reject if filled.
* On success, replace the form with: "Thanks. We will call you
within one business day to confirm a time."
* On failure, show the front desk phone number as a tap to call link.
* Fire the analytics event "booking_submitted" only on success, and
only if the visitor accepted analytics in the consent banner.
* Link the privacy policy under the submit button.
Do not commit any API keys. Tell me which env vars I need to set.
Routing, spam, failure, consent and the conversion event are all specified.
Common mistakes
- Testing the form only with your own email. The real inbox may filter it.
- No fallback when the form fails. A visitor who sees an error and no phone number is gone.
- Giving clients a full CMS for three edits a year.
- Copying another site's privacy policy. It describes someone else's data handling.
Try it yourself
On your practice site, build the primary form with labels, a honeypot, a thank you message and a fallback phone link. Connect it to an inbox you control and test from a phone and a desktop. Add a generated privacy page and a consent banner that blocks analytics until accepted.
Time: about 45 minutes.
Deliverable: a short note listing where submissions go, the test results, the editing option you would recommend and why, and three accessibility checks you ran.
Resources
- Launch QA checklist the forms, accessibility and privacy checks
- Website specification brief where you record who receives submissions
- Test before the client sees it the full QA pass
- Hand off the site and set support boundaries documenting the editing option
Finished this lesson?
Mark it complete to track your progress through the course.
Last reviewed October 18, 2026. Prices, laws and tool terms change, so check current terms before you rely on any figure.