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.