Reference · Beginner

HTML form elements

Collect user input with form, label, input, textarea, select, button, fieldset, and legend while preserving clear relationships.

Published
Last checked

Definition

Form elements define controls, labels, groups, and submission behavior for collecting input.

Minimal valid pattern

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

Key relationships

Every control needs a programmatic label. Related controls use fieldset and legend. The name identifies submitted data; type provides expected semantics and behavior.

Use for and id when the label and control are separate, or wrap a simple control directly in its label. Instructions and errors can be associated with aria-describedby. Autocomplete tokens identify familiar personal and payment fields more reliably than visual labels alone.

Submission behavior

action identifies the endpoint and method selects the request method. Information-changing submissions normally use POST rather than placing sensitive or lengthy values in a URL. Buttons inside a form default to submit, so use type="button" for controls that should not submit.

A production endpoint must return truthful, distinct states for success, validation failure, rate limiting, authentication, and service failure. A client-side success message is not evidence that the server received or stored the data.

Validation and recovery

Native attributes such as required, minlength, and input type provide a useful browser baseline. They do not replace server validation. Preserve valid values after a failure, explain how to correct each problem, and move focus to an error summary when the result would otherwise be missed.

Do not disable submission merely because fields are incomplete. A disabled button cannot explain the missing requirement. Let the user attempt the task and provide specific recovery.

Accessibility and security

Keep labels visible, errors specific, and focus predictable. Validate on the server, encode output, protect mutable endpoints from abuse, and do not claim a submission succeeds without a real endpoint.

Limit field sizes and accepted formats on both client and server. Apply appropriate CSRF protection, rate limits, authorization, output encoding, and retention rules for the data being collected. Never place secrets in client markup or analytics events.

Common misuse

Placeholders do not replace labels. A styled generic element does not replace a button. Client validation does not establish trust.

Verification checklist

  • Complete every task using only a keyboard.
  • Inspect each control’s name, description, required state, and current value.
  • Submit empty, malformed, valid, duplicate, and oversized data.
  • Test slow networks and server failures without losing correct values.
  • Confirm success only after the endpoint returns a verified success response.
  • Review storage, email delivery, analytics, abuse controls, and data deletion.