Forms that reach the right desk

A web form is a promise: fill this in and someone will act on it. When the form sends to the wrong person, or to nobody, the resident does not know. They wait, then they call, upset, and nobody can find what they sent.

This lesson makes sure every form on your site reaches a person who will act on it.

Make a list of every form

Most sites have more forms than anyone remembers: contact forms, request forms, registrations, complaint forms, job interest forms, a form a vendor built for one event years ago. Your list needs, for each:

• the page it is on,
• what it is for,
• where submissions go (email addresses, a system or both),
• the owner who acts on it,
• the date it was last tested.

Your website's editor may have a forms area that lists them all. Search the site for pages with forms too, because some are embedded from outside services.

Send to a role mailbox

Submissions should go to a mailbox named for the job, such as clerk@, permits@ or parks@, that at least two people read. A form that sends to one person's address stops working the day they go on leave, change jobs or retire.

If your form system can also save submissions in the website or a database, turn it on. Email can be filtered as spam or lost. A saved copy can be found.

The confirmation tells residents what happens next

After submitting, the resident should see, and ideally receive by email:

• that the form was received,
• what happens next and by when ("We answer within two business days"),
• a reference if you have one,
• who to call if they do not hear back.

Only promise a response time your office meets.

Collect only what you need

Every field is data you must store, protect and possibly produce in a records request. Ask only for what the task needs. A pothole report needs a location and a way to reach the person, and it does not need a date of birth.

Never ask for Social Security numbers, bank details or full card numbers in an ordinary web form unless a law or program requires it and the system is built for that data. Payments belong in the payment provider's system.

Forms people can fill in

Each field needs a visible label that stays visible while typing, and errors need to say what is wrong and how to fix it. These are WCAG 2.1 requirements (Success Criteria 3.3.1 and 3.3.2), and Title II applies them to your forms. Accessible Content Basics covers forms in its seventh lesson.

Spam protection should not lock people out. Some puzzle-style challenges are hard or impossible with a screen reader. Ask your web provider for an option that does not require solving a visual puzzle.

Test every month

Once a month, send a test through every active form:

1. Fill it in with obviously test data ("TEST, please ignore").
2. Confirm the message arrived in the right mailbox, and the confirmation reached you.
3. Write the date in your form list.

Also test after anything changes: the form, the website software, the email system, or the staff who read the mailbox.

When the form's owner changes

When someone who handles a form leaves or changes jobs, update the form list the same day. Check that the role mailbox still has a reader. Shared Accounts and Offboarding covers the full checklist.