Why labels matter

A caption nobody can click

Look back at every form you've built in the last two courses. Above each input sits a word: "Email", "Password", "Country". To your eyes it reads as a caption, sitting where a caption should sit. To a mouse, it's dead space; clicking it does nothing. To a screen reader, it's not even a caption, it's just a sentence of text floating in the page, with no announced connection to the input two lines below.

Email
<input type="email" name="email">

That markup looks finished, but it's broken. Sighted mouse users can find the input by its position, so the gap is invisible to them, which is why it survives in production for years. The people who pay for it are the ones who can't rely on position: someone using a screen reader, someone with a tremor who needs a bigger target than a 20px box, someone tabbing through the page with a keyboard alone.

What a real label buys you

The fix is one element, <label>, and it buys two things at once:

• An announced name. A screen reader lands on the input and reads "Email, edit text" instead of just "edit text". The visitor knows what they're filling in without having to guess from context.
• A bigger click target. Click the word "Email" and focus jumps into the field. On a phone, where fingers are wider than text, this difference decides whether a form feels effortless or infuriating.

<label for="email">Email</label>
<input type="email" id="email" name="email">

Same visual result on screen. Completely different form underneath: the browser now knows these two elements are one unit, and it tells every piece of software that reads the page.

The placeholder trap

A common shortcut skips <label> entirely and leans on placeholder instead:

<input type="email" name="email" placeholder="Email">

It looks like a label. It behaves like one for about a second: the moment the visitor types their first character, the placeholder vanishes, and the caption disappears along with it. Come back to a half-filled form later and the field marked "Email" is now just an empty-looking box with no memory of what it was asking for. Placeholder text is a hint about the expected format ("[email protected]"), not a replacement for the field's name. The two solve different problems, and this course is about the one placeholder cannot solve.

Where this fits

Nothing here changes what gets submitted. The name and value rules from the last two courses still decide what shows up in params. Labels are a layer on top of that machinery, connecting a human-readable caption to a control that already works. You could ship every form in this course without a single <label> and the server would receive identical data. The difference lives entirely in who can use the form, and that difference is the whole subject here.

What this course covers

• Lesson 1, Why labels matter: the gap between looking labeled and being labeled (you are here)
• Lesson 2, Explicit labels: the standard way to connect a label to its control with for and id
• Lesson 3, Implicit labels: nesting the control inside the label instead
• Lesson 4, fieldset and legend: captioning a group of controls
• Lesson 5, aria-label and aria-labelledby: naming a control when there's no room for visible text
• Lesson 6, aria-describedby: attaching hints and error messages to a control
• Lesson 7, Putting it together: one signup form built with every technique in this course

By the end, every input you write will announce its purpose to whatever is reading the page, and every group of related controls will carry a caption a screen reader can find.