Sign in Get started

Modern HTML5 in Production · Capstone Projects

Capstone: An Accessible, Fast Checkout Form

Design the HTML for a checkout form that works with keyboards, screen readers, password managers and autofill, validates helpfully, and can't double-charge.

Scenario

Example company: an e-commerce site is rebuilding its checkout. Current problems: 30% mobile abandonment on the address step, complaints from screen-reader users, occasional double charges, and a security review flag about trusting client-side totals.

Requirements

  • Contact, shipping address, delivery options and payment steps.
  • Fast completion on mobile: correct keyboards and full autofill support.
  • Accessible: labels, grouped options, clear errors, keyboard-only completion, announced status changes.
  • Safe: server-side validation and pricing, no double charges.

Constraints

  • Card details are entered in the payment provider's iframe.
  • The site must work if JavaScript fails to load (forms submit normally).

Deliverables

  1. The HTML for each step: labels, type, autocomplete, inputmode, fieldset/legend for delivery options, error containers linked with aria-describedby.
  2. The validation design: HTML attributes for quick feedback, server validation with field-level errors, focus management on errors.
  3. The double-submission design: button state, idempotency key, Post/Redirect/Get.
  4. A test plan: keyboard-only, screen reader, password managers and autofill on major browsers, Lighthouse and axe.

Hints

  • Delivery options are a radio group: wrap them in <fieldset> with a <legend>.
  • Use autocomplete tokens such as shipping street-address, shipping postal-code and email.
  • The order total shown is for information only; the server recomputes it.

Deliverables

How do you mark up the delivery options?

Model answer

As a radio group inside a fieldset with a legend ("Delivery method"), each radio with its own label including price and timing, so screen readers announce the group name and each option.

Rubric

Look for fieldset/legend, real radio inputs and descriptive labels.

How does the form behave when the server finds errors?

Model answer

It re-renders (or updates) with a summary at the top linking to each field, specific messages next to fields linked with aria-describedby, aria-invalid on invalid fields, preserved user input, and focus moved to the summary.

Rubric

Strong answers cover both no-JS and JS paths and preserve user input.

How do you guarantee no double charges?

Model answer

Disable the button on submit with visible progress, send an idempotency key generated per checkout and enforced by the server and the payment provider, and redirect after success (Post/Redirect/Get).

Rubric

Look for server-side idempotency, not only button disabling.

Open in the app to mark lessons complete, take notes and track your progress.