HTML Forms: Inputs, Labels, and Why Labels Matter

So far every page you've built has been one-directional: the browser shows content, the visitor reads it. Forms change that. A form lets a visitor send information back, whether that's a search query, a login, or a contact message. This lesson covers the core form elements, and specifically why the <label> tag matters far more than beginners usually assume.

Connecting Labels And Inputs

A form starts with the <form> tag, which wraps all its inputs:

<form>
  <label for="name">Your Name</label>
  <input type="text" id="name" name="name" value="Vikesh Singh">
</form>

Look closely at how <label> and <input> connect. The label's for attribute, "name", matches the input's id attribute, also "name". This connection is not decorative, it is functional. Because they're linked, clicking directly on the label text "Your Name" will focus the input box, exactly as if you'd clicked the box itself. More importantly, screen readers announce that label text whenever a visitor using assistive technology tabs into that field, so they know what information is expected there. Without a properly linked label, a screen reader user may hear nothing describing the field at all, just "edit text, blank."

A very common beginner mistake is writing a label as plain text sitting near an input without the for and id connection:

<p>Your Name</p>
<input type="text" name="name">

This looks identical on screen to a sighted user, but it provides zero actual connection for assistive technology or for click-to-focus behavior. Always use a real <label> tag, always link it with matching for and id values.

Value Versus Placeholder Text

The value attribute, used above, pre-fills the input with starting text; the visitor can edit or clear it. This is different from placeholder, which shows faint hint text that disappears the moment the visitor starts typing and is never actually submitted as data:

<input type="text" id="hero-name" name="hero-name" placeholder="e.g. Iron Man">

A frequent mistake is using placeholder as a substitute for a real label, leaving the input with no <label> at all. Placeholder text vanishes once typing starts, and some screen readers don't announce it reliably, so a visitor who looks away and back, or who uses assistive tech, can lose track of what the field is asking for. Placeholder text should supplement a label, never replace one.

Common Input Types

The type attribute on <input> changes both its behavior and often its on-screen appearance. A few you'll use constantly:

<input type="email" id="contact-email" name="contact-email" placeholder="tony@starkindustries.com">
<input type="password" id="pwd" name="pwd">
<input type="checkbox" id="subscribe" name="subscribe">
<input type="radio" id="suit-mark1" name="suit-choice" value="mark1">
<input type="radio" id="suit-mark50" name="suit-choice" value="mark50">

type="email" gives mobile keyboards an email-friendly layout and lets the browser do basic format checking before submission, which we'll cover properly in the validation lesson later in this course. type="password" masks typed characters on screen. type="checkbox" lets a visitor pick any number of independent options, zero or more. type="radio" restricts a visitor to exactly one choice among a group, and the grouping is determined entirely by matching name values, not by visual placement; both radio buttons above share name="suit-choice", which is what makes them mutually exclusive.

Textareas And Submit Buttons

For longer text, like a message or comment, use <textarea> instead of <input>, since it supports multiple lines:

<label for="message">Message</label>
<textarea id="message" name="message" rows="4">Looking forward to seeing the new armor.</textarea>

Notice <textarea> has a closing tag, and its starting content sits between the opening and closing tags, unlike <input>'s value attribute.

Finally, every form needs a way to submit it:

<button type="submit">Send Message</button>

A common slip is using <button> without specifying type="submit" inside a form; some browsers default buttons inside a form to submit behavior anyway, but being explicit avoids confusing bugs, especially once a page has more than one button.

This course won't cover where submitted form data actually goes, that requires a backend, outside HTML's scope entirely. For now, focus on building forms that are structurally correct and genuinely usable without a mouse or with a screen reader, since that's a foundation no backend can fix after the fact.

Practice Building A Form

Put this into practice: build a small form collecting a name, pre-filled with "Vikesh Singh," an email address with a helpful placeholder, and a favorite superhero chosen from two radio button options. Tab through the entire form using only your keyboard, no mouse, and confirm every field is reachable and every label makes sense when you land on its field.