Exercise

Repair labels and submission data in a signup form

Fix a newsletter form with persistent labels, submission keys, autocomplete, help text, and explicit button behavior.

Intermediate3 min readLearn · Practice · Review

Published by HTML Code Runner · AI-assisted material · Independent editorial review pending · Editorial policy

On this page

The brief

A newsletter form currently relies on placeholder text and omits the names used in a submission. The fields look usable until someone starts typing, then the instructions disappear. A browser may also collect no useful data because an input ID is not a submission key. Repair both problems while collecting only the information the task requires.

Create a visible email label and connect it to an email input whose ID and name are both email. Use the email autocomplete token to support established browser autofill behavior. Add a persistent help paragraph with ID email-help and associate it through aria-describedby. Require the email value, but do not claim this proves ownership of the address. The service still needs its own verification workflow.

Include an optional name field with the name autocomplete token and a proper visible label. The submit button should explicitly say type="submit". This is a markup challenge: it does not provide an endpoint or subscribe anyone. An action that actually changes an account needs server validation, appropriate consent, and a clear success or error response.

Requirements

  • Persistent email label: A visible label connected by for/id remains available during typing.
  • Email control and submission key: Use the email input type, name, autocomplete token, and required constraint together.
  • Help association: Connect the control to the persistent help paragraph.
  • Persistent help text: A help paragraph should explain what happens to the submitted address.
  • Name label: The optional field still needs a name users can perceive.
  • Optional name field: Name is useful only when needed, and this brief intentionally leaves it optional.
  • Explicit submit button: Declare submit behavior so future refactoring does not change the intent.

Build and check

Write your solution, then check the stated requirements.

    Study the solution
    <form>
      <label for="email">Email address</label>
      <input id="email" name="email" type="email" autocomplete="email" aria-describedby="email-help" required>
      <p id="email-help">We send one learning digest each month.</p>
      <label for="person">Name (optional)</label>
      <input id="person" name="name" autocomplete="name">
      <button type="submit">Join newsletter</button>
    </form>

    The solution separates ID relationships from submission keys. Each label is connected, the help text remains visible, and native input constraints provide basic feedback. This does not validate mailbox ownership or replace the receiving server.

    This is client-side practice with visible rules. A passing result confirms these checks only.

    Review beyond the checks

    Try an empty email, a malformed value, and a plausible address in a standalone copy. The first two should produce browser feedback during normal submission. Do not record a successful validity check as a successful subscription: those are separate events. Check that autofill does not overwrite the optional field with an inappropriate value.

    For a production form, add a real receiving endpoint and test how its error messages are associated with the affected fields. Preserve values when the server rejects a request, identify the problem in text, and avoid using color as the only signal. The static checker confirms the attributes requested here; it cannot test server behavior or the clarity of your privacy language.

    Continue learning

    Inspect a complete document in the markup lab or return to the HTML course.