Write a labeled email form

Learning objectives

Associate a visible label; submit a named value; understand required and email validation.

Prerequisites

Know elements, attributes, and the distinction between a link and a button.

Understand the markup

A form collects values for a defined task. Start by deciding which information is necessary and what will happen when someone submits it. A browser can display controls and perform basic validity checks, but receiving and storing data requires a real server endpoint or another deliberately implemented processing workflow.

Connect a label to its input using a for value that exactly matches the input's id. The id must be unique on the page. The name is different: it becomes the key in submitted form data. An input without a name can appear and accept typing while its value is absent from the form submission.

The email input asks the browser to check the value's email syntax and can offer an appropriate mobile keyboard. It cannot prove that the address exists or belongs to the person typing it. The required boolean attribute rejects an empty value during ordinary interactive submission. Writing required="false" still enables the attribute because its presence is what matters.

The action identifies the receiving URL and method determines how values travel. GET places the data in a query string and is suitable for retrieval, such as search. POST puts data in the request body and is appropriate for changing server state; use HTTPS either way. Browser validation improves usability but never replaces server validation, authorization, or abuse protection. The isolated playground blocks form submissions, so use it to inspect labels and validity rather than to send information.

Try a working example

<form>
  <label for="email">Email address</label>
  <input id="email" name="email" type="email" autocomplete="email" required>
  <button type="submit">Subscribe</button>
</form>

Expected output

A label appears above the email field. An empty or malformed email triggers browser validation when Subscribe is activated. A valid submission is blocked by the playground policy.

Another example

<form action="/search/" method="get">
<label for="query">Search the catalogue</label>
<input id="query" name="q" type="search">
<button type="submit">Search</button>
</form>

Common mistakes

A placeholder is not a label: it disappears during typing. Do not collect passwords or private data using a GET query string. Never trust client-side validation as a security boundary.

Accessibility and browser notes

Keep instructions visible and associate extra help with aria-describedby. Let the browser expose the native label and required state before adding ARIA.

Check your work

Test at least three cases: an empty field, a malformed value such as library, and a plausibly valid address. Observe which cases trigger a browser message. The wording varies between browsers and language settings. A successful validity check is not evidence of successful delivery: inspect the receiving application separately when you later connect a real endpoint.

Practice

Add visible help text explaining that no marketing messages will be sent, and connect it to the email field.

<label for="email">Email address</label>
<input id="email" name="email" type="email" autocomplete="email" aria-describedby="email-help" required>
<p id="email-help">We send account notices only, with no marketing messages.</p>

Related lesson

Add an accessible disclosure with details and summary

Specifications and further reading

WHATWG HTML Living Standard

Submission rules that explain surprising behavior

Only successful controls contribute values to a normal form submission. A disabled control is generally excluded, an unchecked checkbox contributes no value, and a control without a name is not a named entry. Readonly and disabled therefore have different consequences. Use readonly for supported text-like controls when a value should remain part of the submitted data but cannot be edited in this interface.

The submitter can also affect the request. Two submit buttons can have different names and values, and button-level formaction or formmethod can override the containing form. Document those decisions when a form supports several actions. A receiving endpoint must determine the requested action securely rather than trusting that only the intended button can be used.

Be careful with scripted submission: form.submit() bypasses the normal submit event and interactive constraint-validation flow, while requestSubmit() follows the normal submission pathway and can use a submitter. Those APIs solve different problems. For most beginner forms, use a native submit button first and add scripting only when you have a clear reason and a test for keyboard and error behavior.