Forms — Letting Visitors Talk Back
The bakery wants customers to pre-order a cake: name, phone number, pickup date and a message for the icing. That is a form. Forms are where a page stops only talking and starts listening, and a few small attributes decide whether the data actually arrives and whether everyone can fill it in.
The rule
Every input needs a label for people and a name for the server.
<form action="/orders" method="post">
<label for="customer">Your name</label>
<input id="customer" name="customer" type="text" required>
<label for="phone">Phone</label>
<input id="phone" name="phone" type="tel" required>
<label for="pickup">Pickup date</label>
<input id="pickup" name="pickup" type="date">
<label for="icing">Message on the cake</label>
<textarea id="icing" name="icing" maxlength="40"></textarea>
<button type="submit">Place order</button>
</form>The form. action is where the data goes; method is how. post sends the data in the request body, which suits creating an order. get puts the data in the URL, which suits searches you might bookmark.
The label (for people). A <label> whose for matches an input's id is tied to that input. Screen readers announce the label when the field gets focus, and clicking the label puts the cursor in the field, which makes small targets easier to hit. Placeholder text is not a label: it disappears as soon as someone types.
The name (for the server). When the form is submitted, the browser sends each field as name=value, for example customer=Asha&phone=98450.... A field with no name is simply not sent, even if the visitor filled it in.
The type. type="email", tel, number, date and others give the right phone keyboard and some built-in checking. required, min, max and maxlength add simple checks before anything is sent. These help visitors, but the server must still check everything, because anyone can bypass the browser.
The button. A <button> inside a form submits it by default. Write type="submit" to be clear, and type="button" for buttons that should not submit.
The shortcut
Check each field with the "two readers" test: Can a person tell what it is for? (a visible label tied by for and id) and Can the server tell what it is? (a name). One missing reader means a broken field.
Reader one: people
There is a
<label for="icing">, and the textarea hasid="icing". They match, so the label is tied to it.
The silent trap is a field with an id but no name. It looks fine, the label works, and the value never reaches the server.
Drills
Answer fast — trust the rule.
A field has id="email" and a matching label, but no name. What happens on submit?
How do you tie <label>Phone</label> to <input id="phone">?
Which method suits a search form whose results people may want to bookmark?
The cake form uses required and maxlength. Does the server still need to check the data?
Remember
- Every input needs a label for people and a name for the server.
- Two readers test: label tied by
forandid, plus aname. - Trap: a field with no
nameis silently left out; browser checks never replace server checks.