Form Anatomy: <form>, <fieldset>, <label>, <input>, <button>

"A form is a contract. Every field is a question, every label is the question text, every input is the user's answer."

The `<form>` Element Itself

The <form> wraps a group of inputs that submit together. The attributes that matter:

action="/api/signup" — where the form data is sent.
method="post" — almost always post for forms that change state; get only for search-style forms that read.
autocomplete="on" | "off" — controls browser autofill. Default is on. Turning it off site-wide is a hostile-to-users move; turn off per-field only when there's a real reason (a one-time PIN, an OTP).
novalidate — disables the browser's built-in HTML5 validation. Useful when you're doing custom validation but want browsers to still send the form on submit.

`<label>` + `<input>`: The Atomic Pair

This is the most important pattern in the entire track. Every input needs a label. Two ways to associate them:

Explicit (preferred): <label for="email">Email</label> <input id="email" type="email" />. The for attribute on label matches the id on input.
Implicit: <label>Email <input type="email" /></label>. Wrap the label around the input. No id required.

Both give the input an accessible name screen readers can announce, and both make the label text clickable (which focuses or toggles the input). Skip the label and your form fails WCAG, fails Lighthouse, and ships an input that screen readers describe as "edit text" with no context.

The `name` Attribute

The name attribute is what your backend (or JavaScript) receives. <input name="email" /> means the form submission sends email=user@example.com. Without name, the input is essentially invisible to form submission — it has a value but nothing is sent. Common bug: building a form, wondering why the backend sees nothing, realizing no inputs have names.

`<fieldset>` + `<legend>`: Grouping Related Fields

When several inputs belong together — a billing address (street, city, zip), a radio group ("Choose a plan"), a checkbox group ("Email me about...") — wrap them in <fieldset> with a <legend> that names the group. Screen readers announce "Billing address, group, 5 items" before reading the fields.

Radio buttons are the canonical case: they only make sense as a group. The name attribute ties them together (only one can be checked); the <fieldset> + <legend> tells the user what the group represents.

State Attributes: `required`, `disabled`, `readonly`

required — the form will not submit without it. The browser shows a built-in validation message in the user's language.
disabled — input is unfocusable, ungreyed visually, not submitted with the form. Use for fields that aren't applicable to the current flow.
readonly — input shows the value but the user can't edit. Is submitted with the form. Use for confirmation fields where the value was computed.

Subtle distinction: disabled excludes from submission, readonly includes it. Pick on the basis of what you want the server to see.

`<button>`: type Attribute Matters

Always specify type on <button>. The default is type="submit", which means any <button> inside a form will submit the form when clicked. If you have a 'Reset password' button next to a 'Sign up' button, both will submit unless you set type="button" on the non-submit ones. This catches every developer at least once.

The three types:

type="submit" — submits the parent form (default).
type="reset" — clears all form fields back to their initial values. Almost never wanted; one accidental click destroys user data.
type="button" — does nothing by default. For buttons that run JavaScript (toggle visibility, open a modal).

Native Validation: Free For The Asking

HTML5 validation runs in the browser without any JavaScript: required, type="email", type="url", pattern="...", min, max, minlength, maxlength. Submit a form with invalid data → the browser shows a localized error message and focuses the first invalid field. Style invalid fields with :invalid in CSS. Catch the error event with noValidate + custom UI when you outgrow it. Don't reinvent the wheel until the wheel can't get you there.

Pippa's Note

Cwk-site's auth flow uses native HTML5 validation entirely — no custom validator library. required, type="email", minlength, pattern, and a tiny bit of :invalid CSS. The error messages come from the browser in the user's locale (Korean shows Korean errors, English shows English). Less code, more correct behavior, and translations for free.

Code

Full form with fieldsets, labels, and intentional button types·html

<!-- Canonical form anatomy -->
<form action="/api/signup" method="post">
  <fieldset>
    <legend>Create an account</legend>

    <div class="field">
      <label for="email">Email</label>
      <input
        id="email"
        name="email"
        type="email"
        required
        autocomplete="email"
      />
    </div>

    <div class="field">
      <label for="password">Password</label>
      <input
        id="password"
        name="password"
        type="password"
        required
        minlength="8"
        autocomplete="new-password"
      />
    </div>
  </fieldset>

  <fieldset>
    <legend>Choose a plan</legend>
    <label><input type="radio" name="plan" value="free" required /> Free</label>
    <label><input type="radio" name="plan" value="pro" /> Pro ($9/mo)</label>
    <label><input type="radio" name="plan" value="team" /> Team ($29/mo)</label>
  </fieldset>

  <button type="submit">Sign up</button>
  <button type="button" onclick="resetWithConfirmation()">Clear</button>
</form>

Every mistake at once·html

<!-- WRONG — every common mistake at once -->
<form>                              <!-- no action, no method -->
  <div>Email</div>                  <!-- no label, no association -->
  <input type="text" />             <!-- no name, no id, no type=email -->

  <div>Password</div>
  <input type="text" />             <!-- password as plain text! -->

  <input type="radio" value="free" /> Free  <!-- no name → radios don't group -->
  <input type="radio" value="pro" /> Pro

  <button>Sign up</button>          <!-- no type → default submit, fine here -->
  <button>Cancel</button>           <!-- no type → ALSO submits! -->
</form>

Implicit vs explicit label·html

<!-- Implicit label (wrap) — id not required -->
<label>
  Username
  <input name="username" type="text" required />
</label>

<!-- Explicit label (for/id) — preferred when styling needs the input
     and label to be siblings, not parent/child -->
<label for="bio">Bio</label>
<textarea id="bio" name="bio" rows="4"></textarea>

Exercise

Build a sign-up form with: email (required, validated), password (required, min 8 chars), name (required), country (select with at least 3 options), a fieldset for 'How did you hear about us?' with 4 radio options, an 'I agree to terms' required checkbox, and two buttons: Submit and Cancel (cancel must NOT submit). Run it through Lighthouse → Accessibility. Should score 100. Then turn on VoiceOver and Tab through it — every field should announce its label and state.

Hint

If Lighthouse complains about missing labels, you forgot a for/id pair somewhere. If Cancel submits the form, you forgot type="button". If the radio group doesn't read as a group, you forgot the <fieldset><legend>.

Form Anatomy: <form>, <fieldset>, <label>, <input>, <button>

The `<form>` Element Itself

`<label>` + `<input>`: The Atomic Pair

The `name` Attribute

`<fieldset>` + `<legend>`: Grouping Related Fields

State Attributes: `required`, `disabled`, `readonly`

`<button>`: type Attribute Matters

Native Validation: Free For The Asking

Pippa's Note

Code

External links

Exercise

Progress

Comments 0

The <form> Element Itself

<label> + <input>: The Atomic Pair

The name Attribute

<fieldset> + <legend>: Grouping Related Fields

State Attributes: required, disabled, readonly

<button>: type Attribute Matters

Native Validation: Free For The Asking

Pippa's Note

Code

External links

Exercise

Progress

The `<form>` Element Itself

`<label>` + `<input>`: The Atomic Pair

The `name` Attribute

`<fieldset>` + `<legend>`: Grouping Related Fields

State Attributes: `required`, `disabled`, `readonly`

`<button>`: type Attribute Matters