Back to HTML for JavaScript Developers: Build the Bones

Forms Without Tears: Labels, Inputs & the Contact Page

Forms used to terrify me. Not because they’re hard, but because I never really understood what made a form good. My first few contact forms were trainwrecks—no labels, weird tab orders, “submit” buttons that mysteriously disappeared on mobile. The worst part? I didn’t even know they were bad until users started emailing me because the form was broken. So let’s save you that pain. Today, we’re building a clean, functional, no-JavaScript-needed contact form. It’ll work. It’ll be accessible. And it won’t make users rage-quit your site.

inputs, textareas, and submit buttons that don’t suck

Let’s get one thing out of the way: the <form> element is not just a box with stuff in it. It’s a promise that you care about user interaction.

Here’s a bare-bones but fully functional contact form:

html
1
2
3
4
5
6
7
8
9
10
11
12
          <form action="/contact-submit" method="post">
  <label for="name">Your Name</label>
  <input type="text" id="name" name="name" required>

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

  <label for="message">Message</label>
  <textarea id="message" name="message" rows="5" required></textarea>

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

No fancy JavaScript. No classes. But this thing works. It sends data, it validates email format, and it even plays nice with screen readers.

Personal mistake? I used to leave out the name attributes because “I don’t need them yet.” Then I’d wonder why the form submitted blank data. Don’t skip name attributes—they’re how the form talks to your server.

labels: Not Optional, Seriously

Want to fail accessibility audits in 0.2 seconds flat? Skip your labels. Better yet, use placeholder text instead of a label and really frustrate your users.

Here’s the deal: <label> connects human-readable language to form controls. It’s not just helpful—it’s required for accessibility. Screen readers rely on them. Touchscreen users rely on them. Everyone benefits.

Also, use the for attribute like it’s your job:

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

That ties the label to the input, making it easier to click and clearer to parse. If you're ever tempted to skip it because “it looks cleaner without,” just remember: invisible doesn't mean ignorable.

Let’s Build: Your Contact Page (All Structure, No Style)

Drop this directly into your course project’s contact.html page. We’ll style it later, but structure comes first:

html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
          <main>
  <section>
    <h1>Contact Me</h1>
    <form action="/contact-submit" method="post">
      <label for="name">Name</label>
      <input type="text" id="name" name="name" required>

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

      <label for="message">Message</label>
      <textarea id="message" name="message" rows="5" required></textarea>

      <button type="submit">Send</button>
    </form>
  </section>
</main>

We’re sticking to the basics: semantic HTML, useful attributes (required, type="email"), and labels that actually help. Save the fancy animations and real-time validation for later. This is about building a reliable foundation.

One quick bonus tip: HTML5 Boilerplate has a ton of sensible defaults that can help with forms and more if you're building larger-scale pages.

What’s Next?

Your contact form is up and running. It’s real. It works. But let’s take it further—let’s make it inclusive. In the next lesson, we’ll look at how HTML supports accessibility beyond forms, and how to build interfaces that speak (literally) to every user. Ready to build HTML that talks back? Accessibility & HTML That Speaks is up next.