Forms, inputs & accessibility basics

Forms: how the web collects data

<form action="/signup" method="post">
  <label for="email">Email</label>
  <input id="email" name="email" type="email" required>

  <label for="plan">Plan</label>
  <select id="plan" name="plan">
    <option value="free">Free</option>
    <option value="pro">Pro</option>
  </select>

  <button type="submit">Sign up</button>
</form>

Key input types: text, email, password, number, date, radio, checkbox, file. The right type gives you the right mobile keyboard and free validation.

Native validation — before any JavaScript

The browser validates for free with attributes: required, minlength, maxlength, min, max, pattern. An <input type="email" required> refuses to submit when empty or malformed — no JS needed. Learn these before you ever write a validation function.

Accessibility is not optional

Roughly 1 in 6 people has a disability. The basics cost you nothing:

1. Every input gets a <label> wired by for/id — clicking the label focuses the input, and screen readers announce it.
2. Every image gets meaningful alt text (or alt="" if purely decorative).
3. Heading hierarchy must be logical — screen reader users navigate by headings.
4. Buttons are <button>, links are <a> — a clickable <div> is invisible to keyboards.

ARIA (intro only): attributes like aria-label and aria-expanded add meaning where HTML can't. Rule one of ARIA: don't use ARIA when a native element already does the job.

Check yourself

Tab through a form you've built using only the keyboard. Can you reach every field, see where focus is, and submit? If not, neither can many of your users.