From idea to working page

Before you begin

• Can create/open a local HTML file.
• A modern browser; coding experience is not required.

Free original, non-accredited practice. Self-review is not independent assessment. No particular provider, payment platform or country is mandatory; use a legitimate available route or explicitly labelled manual practice.

Specify the smallest tool

A useful first web tool has one clear job and no unnecessary accounts, payments, analytics, or personal data. Build a fictional quote calculator: quantity multiplied by unit price. Inputs must be finite, non-negative numbers. Decide whether decimals and zero are allowed before asking AI for code. Acceptance criteria turn an idea into something testable. Define inputs, expected results, error messages, keyboard behaviour, and offline use. This makes it possible to reject generated code that looks attractive but does the wrong thing. The calculator is an estimate exercise, not a production billing system.

Worked example

ACCEPTANCE: 3 × 5 = 15.00; 0 × 5 = 0.00; 1.5 × 2 = 3.00; negative or blank input is rejected. Every input has a visible label. The page works without a network request.

Your practical task

1. Write a one-sentence problem statement.
2. Choose rules for zero, decimal, blank, negative, and non-finite values.
3. Create at least eight input/expected-result tests using quote-tests.json.
4. Sketch the page with labels, calculate action, result, and error area.
5. State explicitly that no payment or real customer data is involved.

Evidence to keep

• A small written specification and page sketch.
• Eight acceptance tests with expected values.
• A clear boundary between an estimate and an invoice.

Mistakes to watch for

• Starting from visual styling before defining behaviour.
• Letting generated code decide how invalid inputs are handled.

Check your understanding

If the tool displays 0.00 for a blank quantity, did it meet your specification?

No-service / offline route

Write the specification and test table on paper before coding.

Build and inspect

Ask for one self-contained HTML file with labelled inputs, a button, a result area, and no external libraries. Read generated code before running it. Look for network calls, script imports, credential fields, unexpected storage, and operations unrelated to the tool’s purpose. Separate calculation logic from the interface. A pure calculateQuote function can be tested with known inputs; the event handler reads form values and displays the result. Avoid inserting user-provided content with innerHTML. Use textContent for results and errors so input is treated as text rather than markup.

Worked example

LOGIC: reject blank input; convert to numbers; reject non-finite or negative values; multiply; check that the result is finite; format for display.
INTERFACE: read fields → call calculation → put a result/error into a text node.
SCOPE: no tax, currency conversion, or payment processing.

Your practical task

1. Create or generate a one-file implementation matching your specification.
2. Inspect it for fetch, external script tags, storage, and unrelated permissions.
3. Find the function that validates and multiplies values.
4. Explain each validation branch in your own words.
5. Open it locally and run the happy-path tests before styling it.

Evidence to keep

• An inspectable self-contained HTML file.
• An explanation of input validation and calculation.
• A list of external dependencies: none for this build.

Mistakes to watch for

• Running generated install commands without inspection.
• Assuming HTML min attributes replace all validation logic.

Check your understanding

Which lines would you inspect first if a generated calculator unexpectedly requested an API key?

No-service / offline route

Use the supplied self-contained reference calculator and annotate the code before changing it.

Test and share

Run the same acceptance tests against your actual file, not a screenshot or an AI explanation. Record expected output, observed output, and pass/fail. Test keyboard operation and a narrow screen as well as arithmetic. A page that works only with a mouse is not complete. The reference calculator intentionally remains simple. JavaScript floating-point arithmetic can be unsuitable for precise financial accounting. Formatting with two decimals does not solve every money-calculation problem. State that limitation rather than advertising the exercise as an invoicing or payment system.

Worked example

TEST LOG: quantity 3, price 5 → expected 15.00 → observed 15.00 → pass.
KEYBOARD TEST: Tab reaches both inputs and Calculate; Enter submits; the result is announced in a status region.
LIMITATION: Educational estimate, no tax or financial rounding policy.

Your practical task

1. Run all eight fixture cases and record observed results.
2. Navigate the page using only Tab, Shift+Tab, Enter, and Space.
3. Test a phone-width viewport and long error text.
4. Disconnect the network and repeat a successful calculation.
5. Share the HTML with a README listing tests and limitations.

Evidence to keep

• Eight recorded arithmetic/validation tests.
• Keyboard, narrow-screen, and offline checks.
• A README that does not overstate financial correctness.

Mistakes to watch for

• Testing the reference file while sharing a different untested version.
• Treating two-decimal formatting as a complete accounting policy.

Check your understanding

Can someone open the file offline and reproduce your test results without installing anything?

No-service / offline route

The entire activity is designed to run from a local file.

Debug with reproducible failures

A useful bug report contains the smallest input that reproduces the problem, the expected result, the actual result, and the relevant environment. When asking AI for help, include the narrow function and test—not secrets, an entire account export, or unrelated application files. Change one thing at a time and keep a known-working version. A suggested fix may solve one case while breaking another. Rerun the full small test set after each change. If the model proposes a large rewrite, ask it to explain why a smaller patch is insufficient.

Worked example

BUG: Empty quantity shows zero instead of an error.
CAUSE: Number("") becomes 0.
SMALL FIX: Check the trimmed raw input before numeric conversion.
REGRESSION TESTS: zero must still be accepted; blank must fail.

Your practical task

1. Introduce the blank-input bug in a copy of the calculator.
2. Write a four-part bug report with exact reproduction steps.
3. Ask for or propose the smallest change that addresses the cause.
4. Run the blank and zero tests, then all remaining cases.
5. Record the diff and the reason the fix is correct.

Evidence to keep

• A reproducible bug report.
• A small explained patch and regression test results.
• An unchanged known-working backup.

Mistakes to watch for

• Pasting an entire private project into a cloud prompt.
• Accepting a rewrite without checking whether old tests still pass.

Check your understanding

Why must zero remain a separate test after fixing blank-input handling?

No-service / offline route

Debug the local file using browser developer tools or a text editor.

Improve accessibility and safe rendering

Accessibility and safe rendering are engineering requirements, not final decorations. Use visible labels connected to inputs, meaningful button text, readable contrast, and a result/status region. Errors should explain the problem without relying only on red colour. Treat any future free-text field as untrusted. For this exercise, test that text such as <img src=x onerror=alert(1)> is shown as text or rejected, never executed. Do not add a rich-text editor or third-party UI library just to display a result. Keep the file inspectable and responsive.

Worked example

REQUIRED: label for="quantity" matches input id="quantity".
STATUS: a result region uses role="status".
SAFE OUTPUT: result.textContent = message.
REVIEW: controls remain readable at browser zoom and do not require hovering.

Your practical task

1. Check the label/input associations.
2. Confirm that errors are understandable without colour.
3. Inspect every location that displays user-supplied text.
4. Test keyboard focus visibility and a larger browser zoom.
5. Remove decorative features that reduce clarity or add unnecessary dependencies.

Evidence to keep

• An accessibility checklist with observed results.
• No untrusted HTML insertion in the tool.
• A responsive version that remains usable without hover.

Mistakes to watch for

• Using placeholders as the only labels.
• Confusing a sanitisation claim with evidence that rendering is safe.

Check your understanding

How would a keyboard user know which input is invalid and where the current focus is?

No-service / offline route

Perform every check on the downloaded HTML; no account or network is required.

Capstone: release a tested quote tool

Deliver a small release that another person can inspect, run offline, and test. Include the implementation, specification, acceptance tests, observed results, accessibility notes, and known limitations. A release note should explain what changed and what is deliberately outside scope. If you publish the file online, review it again for secrets and dependencies. Do not add payment buttons or real customer collection to this capstone. Those features introduce additional financial, security, legal, and privacy responsibilities that this practice build has not addressed.

Worked example

RELEASE PACK: index.html, README.md, specification.md, test-results.md, CHANGELOG.md.
ACCEPTANCE: all eight fixture tests pass; keyboard and offline checks pass; no network dependencies; no misleading billing claims.

Your practical task

1. Freeze a release candidate and run the entire test checklist.
2. Ask another learner to reproduce two tests from the README.
3. Fix one issue they find and record the change.
4. Score the five capstone criteria with evidence.
5. Export the HTML and release pack without credentials or private data.

Evidence to keep

• A runnable and inspectable release pack.
• Complete tests and a documented review improvement.
• Explicit limits covering financial accuracy, tax, and production use.

Mistakes to watch for

• Publishing a later untested version after finishing the test report.
• Claiming secure or production-ready solely because the page runs.

Check your understanding

Which acceptance test would catch a regression introduced by your last visual change?

No-service / offline route

Complete and distribute the release as local files; public deployment is optional.

Capstone self-review

Score each criterion 0 (missing), 1 (partial), or 2 (demonstrated). A self-review pass needs at least 8/10 and 2/2 on the final safety/limits criterion. This is practice feedback, not verified assessment.

• Specification: Inputs, invalid cases and scope are defined before implementation.
• Behaviour: All eight fixture tests have expected and observed results.
• Accessible use: Visible labels, keyboard operation, focus and status/error handling are checked.
• Reproducibility: Offline file, README, change log and review evidence are supplied.
• Safety and scope — critical: No secrets/dependencies/real payments; financial limits are stated.

Review questions

Practice files

• LICENCE.md
• quote-engine.mjs
• quote-lab.html
• quote-tests.json
• release-checklist.md

References and editorial limits

Original authored practice material; not independently expert-reviewed.

• MDN: first website
• MDN: accessible forms
• MDN: textContent

Browse all build paths → · Curriculum overview