Forms

A form is how a page collects information and sends it somewhere. In the expense tool, it is how a claim gets created: a description, a category, an amount, a date.

Forms are the part of HTML where using the right element pays off most. You met label association in the semantic HTML lesson. Here you will see the rest of what the form element and the right input types hand you for free — and the specific shortcuts that quietly take it away again.

<form action="/expenses" method="post">
  <fieldset>
    <legend>Expense details</legend>

    <div class="field">
      <label for="description">Description</label>
      <input
        type="text"
        id="description"
        name="description"
        maxlength="80"
        required
      />
    </div>

    <div class="field">
      <label for="amount">Amount in GBP</label>
      <input
        type="number"
        id="amount"
        name="amount"
        min="0"
        step="0.01"
        required
      />
    </div>

    <div class="field">
      <label for="spent-on">Date spent</label>
      <input type="date" id="spent-on" name="spentOn" required />
    </div>
  </fieldset>

  <button type="submit">Submit claim</button>
</form>

• The form element groups the fields and decides where the data goes. It also gives you submission when the reader presses Enter in a text field, which people expect and notice the absence of.
• Every label carries a for value that matches the id of its input. That association is what makes the label announced with the field, and what makes clicking the label focus the field.
• name is what the value is called when it is sent. id is for the label and for CSS or script. They are often the same word, but they do different jobs.
• required tells the browser not to submit while the field is empty, and marks the field for assistive technology as one that must be filled in.
• step="0.01" allows pence. Without it, a number input only accepts whole numbers, which is a confusing error to debug.
• type="submit" is the default for a button inside a form, but writing it makes the intent obvious to the next reader.

<fieldset>
  <legend>Category</legend>

  <label><input type="radio" name="category" value="travel" required /> Travel</label>
  <label><input type="radio" name="category" value="equipment" /> Equipment</label>
  <label><input type="radio" name="category" value="training" /> Training</label>
</fieldset>

<div class="field">
  <label for="cost-centre">Cost centre code</label>
  <input
    type="text"
    id="cost-centre"
    name="costCentre"
    pattern="[A-Z]{3}-[0-9]{4}"
    title="Three capital letters, a hyphen, then four digits"
    required
  />
  <p id="cost-centre-hint">For example: FIN-2041</p>
</div>

• The three radio buttons share one name, which is what makes them one choice rather than three separate questions. Only the selected value is sent.
• fieldset groups them and legend is the group's question. Without that, a screen reader user hears three options with no idea what is being asked.
• Here each input sits inside its label, which is the other valid way to associate them and is convenient for short option text. Pick one style and keep to it.
• pattern describes the required format. It is checked only when the field has a value, so pair it with required if the field is mandatory.
• title supplies the text the browser shows when the pattern fails. Without it the message is generic and unhelpful. The visible hint below the field does the same job more reliably, because it is there before the error.