015: HTML Review
Learning outcomes
By the end of this lesson, you can reconstruct semantic HTML from a screenshot plus content brief without copying source; diagnose common structural, path, media, table, and form defects; validate and keyboard-test under time pressure; and explain decisions in a ten-question written/code review.
Prerequisites and retrieval
Bring the finished portfolio, but start today's timed task in a new folder. From memory, write the standard document skeleton, five landmark/section elements, and the label association rule. Retrieval reveals understanding better than copying.
Terminology
- Reconstruction: implementing from observable requirements without taking source code (course term).
- Visual inference: tentative conclusion from appearance that must be checked against content meaning (course term).
- Content brief: authoritative text, destinations, media purpose, and interactions (course term).
- Timebox: fixed period that forces prioritization (course term).
- Diagnosis: finding root cause from evidence rather than treating symptoms (course term).
- Parser recovery: Browser-defined handling that produces a DOM even from erroneous markup, which can hide defects. — Source: WHATWG: Parse errors
- Verification: demonstrating requirements through tests (course term).
- Tradeoff: deliberate choice between competing constraints, stated explicitly (course term).
- Reconstruction (course): "This course's term for implementing from observable requirements without copying source — not a WHATWG spec term." — Source: intuitive workflow; contrast with WHATWG: Introduction
- Parser error / Recovery: "A parse error is a violation of HTML syntax; the parser defines recovery to produce a DOM." — Source: WHATWG: Parse errors
- Verification (course): "Demonstrating requirements through tests (Nu checker, keyboard navigation)." — Source: MDN: Debugging HTML & WCAG-EM
Mental model: meaning behind pixels
A screenshot shows one rendering at one viewport. It cannot reliably tell you whether a title is h1, a card is article, columns are CSS layout, or a control has an associated label. Never reproduce pixels with tables, repeated <br>, empty wrappers, or heading levels chosen by font size.
Combine two inputs:
- screenshot: visual grouping, prominence, sequence, likely repeated patterns;
- brief: purpose, exact content, heading relationships, destinations, actions, image meaning, form requirements.
When they conflict, preserve meaning and operation. CSS will later reproduce layout. Today's output should be an excellent unstyled document.
Review matrix: what a strong HTML developer should be able to explain
Use this matrix before the timed rebuild. You should be able to choose and defend the relevant HTML without looking up the answer first:
| Area | You should be able to explain |
|---|---|
| Document | doctype, html, head, body, encoding, viewport, title |
| Syntax | nesting, void elements, boolean attributes, global attributes, whitespace |
| Text | headings, paragraphs, lists, quotes, citations, abbreviations, editorial semantics |
| Navigation | relative/absolute URLs, fragments, id, meaningful link text, rel/target decisions |
| Media | img, alt, dimensions, figure, responsive images, audio/video, loading priority |
| Structure | landmarks, section, article, aside, generic containers |
| Data | simple and complex table headers; when not to use a table |
| Forms | labels, names, control types, GET/POST, encoding, choices, autocomplete |
| Validation | constraints, patterns, bypass, and why server validation remains required |
| Accessibility | native semantics, keyboard order, accessible names, skip navigation, restrained ARIA |
| Metadata | description, canonical, favicon, Open Graph, robots, structured data |
| Integration | uploads, character references, iframes, CSS/JS inclusion, CSP concepts |
If a row feels weak, revisit that lesson before attempting the rebuild. Review should expose weak mental models, not merely rehearse memorized tag names.
Timed rebuild brief
Build a one-page portfolio profile in 45 minutes:
Create a new folder and save the result as index.html. During verification, serve the folder with python -m http.server 8000, open http://localhost:8000/, and run the keyboard and Nu checks against the served page.
Site identity: Mira Chen Primary navigation: Home, Experience, Contact (same-page fragments) Main introduction: Building clear, accessible interfaces with semantic HTML About: two paragraphs Skills: Semantic HTML, accessibility reviews, study planning Experience: two independent projects, each with title, summary, year, and detail link Availability: weekday/topic/start table with three rows Contact: name, email, topic select, reply preference, message, send action Image: Mira reviewing a page outline; 1200 x 800 Safety: fictional endpoint; no sensitive information
Time plan
- 0-5 minutes: annotate regions and heading outline.
- 5-12: create skeleton, metadata, landmarks, navigation/fragments.
- 12-25: implement content, lists, image, articles, table.
- 25-35: implement labeled/grouped validated form.
- 35-40: inspect paths, IDs, headings, names, alt/dimensions.
- 40-45: keyboard test and Nu check; fix earliest root causes.
Do not begin styling. If time runs short, complete correct core semantics before optional media embellishment.
Guided example: derive the outline and structure
Outline:
Building clear, accessible interfaces with semantic HTML (h1) About Mira (h2) Skills (h2) Selected work (h2) HTML study group (h3) Portfolio review clinic (h3) Availability (h2) Contact Mira (h2)
Complete rebuild:
<!doctype html>
<html lang="en">
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1">
<title>Portfolio | Mira Chen</title>
</head>
<body>
<header>
<p>Mira Chen</p>
<nav aria-label="Primary">
<ul>
<li><a href="#home">Home</a></li>
<li><a href="#experience">Experience</a></li>
<li><a href="#contact">Contact</a></li>
</ul>
</nav>
</header>
<main id="home">
<h1>Building clear, accessible interfaces with semantic HTML</h1>
<p>I turn content plans into robust, accessible pages.</p>
<section>
<h2>About Mira</h2>
<figure>
<img
src="images/profile.webp"
alt="Mira Chen reviewing a page outline on a desk"
width="1200"
height="800">
<figcaption>A collaborative review before coding begins.</figcaption>
</figure>
<p>I build accessible, semantic pages from clear content plans.</p>
<p>My work emphasizes explanation, testing, and inclusive choices.</p>
</section>
<section>
<h2>Skills</h2>
<ul>
<li>Semantic HTML</li>
<li>Accessibility reviews</li>
<li>Study planning</li>
</ul>
</section>
<section id="experience">
<h2>Selected work</h2>
<article>
<h3>HTML study group</h3>
<p>2026</p>
<p>Weekly sessions progressing from documents to personal sites.</p>
<p><a href="projects/study-group.html">HTML study group details</a></p>
</article>
<article>
<h3>Portfolio review clinic</h3>
<p>2026</p>
<p>Structured reviews of semantics, accessibility, and links.</p>
<p><a href="projects/review-clinic.html">Portfolio review clinic details</a></p>
</article>
</section>
<section>
<h2>Availability</h2>
<table>
<caption>Weekly focus schedule</caption>
<thead>
<tr><th scope="col">Day</th><th scope="col">Topic</th><th scope="col">Start</th></tr>
</thead>
<tbody>
<tr><th scope="row">Monday</th><td>HTML foundations</td><td>09:00</td></tr>
<tr><th scope="row">Wednesday</th><td>Accessibility review</td><td>14:00</td></tr>
<tr><th scope="row">Friday</th><td>Portfolio planning</td><td>10:30</td></tr>
</tbody>
</table>
</section>
<section id="contact">
<h2>Contact Mira</h2>
<p>Required fields are marked “required.” Do not send sensitive information.</p>
<form action="/contact" method="post">
<p>
<label for="name">Name (required)</label>
<input type="text" id="name" name="name" autocomplete="name" required maxlength="100">
</p>
<p>
<label for="email">Email (required)</label>
<input type="email" id="email" name="email" autocomplete="email" required maxlength="254">
</p>
<p>
<label for="topic">Topic (required)</label>
<select id="topic" name="topic" required>
<option value="">Choose a topic</option>
<option value="general">General question</option>
<option value="review">Portfolio review</option>
</select>
</p>
<fieldset>
<legend>Reply preference</legend>
<input type="radio" id="reply-email" name="reply" value="email" required>
<label for="reply-email">Email reply</label>
<input type="radio" id="reply-none" name="reply" value="none">
<label for="reply-none">No reply needed</label>
</fieldset>
<p id="message-help">Enter 20 to 1000 characters.</p>
<p>
<label for="message">Message (required)</label>
<textarea id="message" name="message" rows="8" cols="50" required minlength="20" maxlength="1000" aria-describedby="message-help"></textarea>
</p>
<button type="submit">Send message</button>
</form>
</section>
</main>
<footer><p><small>Copyright 2026 Mira Chen</small></p></footer>
</body>
</html>
The exact wrapper choices can differ while remaining correct. For example, About's figure could sit outside its section if content meaning justified it. Assessment rewards an explicit rationale, not character-for-character similarity.
Intermediate example: diagnose ten defects
<html><head><title>Page</title></head><body>
<div class="nav"><div>Home</div></div>
<h3>Profile</h3><h1>Skills</h1>
<img src="photo.jpg" alt="photo">
<table><tr><td>Day</td><td>Time</td></tr><tr><td>Mon</td><td>9</td></tr></table>
<form action="/contact" method="get">
<input id="email" type="email" placeholder="Email">
<label for="message">Message</label><textarea id="msg" value="Hello"></textarea>
<div role="button" tabindex="2">Send</div>
</form></body></html>
Diagnose before repairing: missing doctype/language/charset/viewport; vague title; fake navigation and absent destinations; inverted headings; weak alt/no dimensions; table lacks caption/headers/scope; sensitive/change operation using GET; email lacks label/name/autocomplete; textarea label mismatch/name and invalid value approach; fake button/positive tabindex. One line can contain several root causes.
Advanced optional extension: explain tradeoffs
Explain three choices in your own words:
- Why
articlefor projects butlifor skills? - Why one
h1even though multiple are conforming possibilities? - Why native validation remains while server validation is required?
Then propose what CSS and JavaScript may add without changing core semantics. CSS can create a responsive visual grid and focus styles. JavaScript might enhance error summaries, but should preserve native names, operation, and server checks.
Common mistakes and debugging
- Copying source from the screenshot's site: defeats reconstruction and may copy defects/licensed work.
- Encoding visual columns as tables: determine data relationships first.
- Omitting content when image unavailable: write equivalent purpose.
- Time spent polishing indentation while controls fail: prioritize operation, then clarity.
- Browser rendering mistaken for correctness: inspect DOM and run Nu.
- First validator error ignored: parser cascades obscure later diagnosis.
- Answers recite tags: explain user/content purpose and alternatives considered.
- Finishing at minute 45 without tests: reserve the final ten minutes.
Accessibility, security, and performance
The rebuild must support keyboard operation, logical headings/landmarks, meaningful links, appropriate alt, table associations, form labels/groups/instructions, and visible native focus. Screenshot fidelity never overrides these. No single review proves WCAG conformance.
Use fictional submissions; GET must not expose message/personal data in a query; POST still requires HTTPS and server validation. Generated output requires encoding and authorization as applicable. Reserve image dimensions, optimize files, avoid autoplay/custom widgets, and let semantic HTML work before enhancements.
Tiered exercises
Level 1: plan
Produce the content inventory, outline, landmark map, and file paths in five minutes.
Level 2: timed rebuild
Implement the brief in 45 minutes, reserving ten minutes for keyboard and conformance checks.
Level 3: written/code review
Answer ten questions and repair the defective snippet without reference notes, then compare your reasoning with the provided solutions.
Level 1: use the guided outline. Map identity/nav to header, unique content to main, each named theme to section, independent experiences to articles, and copyright to footer.
Level 2: the guided complete document is one valid solution. Test fragment IDs, nested project paths, table header coordinates, label clicks, same-named radios, invalid form boundaries, keyboard order, and Nu output.
Level 3 questions and answers:
- Internet vs Web? Internet is network infrastructure; Web is linked resources transferred mainly with HTTP.
- Why doctype? It selects standards mode for normal HTML documents.
- Why heading ranks? They express content hierarchy, not font size.
- Relative path basis? The URL of the document containing the reference.
- Empty alt when? The image is decorative or redundant in that context.
- Why table scope? It associates simple row/column headers with data.
- ID versus name? ID identifies/labels in the document; name keys submitted form data.
- Link versus button? Link navigates; button performs an action.
- Why native HTML before ARIA? Native elements provide semantics and behavior; ARIA only changes accessibility semantics and can conflict.
- Why server validation? Browser checks can be bypassed; the server is the trust boundary.
Repair the diagnostic snippet using the guided complete patterns: add the document skeleton; real nav links; one logical h1 then h2; context-specific alt/dimensions; caption/th/scope; POST; explicit label/ID/name/autocomplete; textarea content between tags with matching ID/name; and a native submit button with no positive tabindex.
Recap and exit questions
HTML mastery means deriving meaning from content, implementing native semantics, diagnosing root causes, and proving behavior. A screenshot is evidence about presentation, not source semantics.
- What information can a screenshot not provide?
- How should time be divided in a rebuild?
- Which defects are highest priority?
- Why can two different structures both be correct?
- Can you explain every chosen element without citing its appearance?
Try it with your own example
For your own final timed rebuild, don't reuse Mira Chen's brief verbatim — write a two-minute brief for a business or person you actually know (a real bakery, a relative's small shop, a friend's portfolio), the way this course wrote one for Rina across the last fourteen lessons. A brief you invent yourself, under time pressure, is a much closer simulation of a real freelance or job-interview task than rebuilding a brief you've already memorized.
Give yourself the same five-minute planning limit before you start:
Site identity: [real name] Primary navigation: [2-4 real pages or sections] Main introduction: [one honest sentence about what they actually do] About: [what you'd genuinely want a visitor to know first] A collection with at least two comparable items (products, projects, services) One piece of tabular data (hours, prices, a comparison) A form that collects one real, useful thing from a visitor
Then run the same 45-minute clock from this lesson's timed brief. When you finish, ask yourself the three tradeoff questions from the advanced section above — but answer them about your choices, not Mira's. If you can explain why you chose article over li for your own real content without looking back at any earlier lesson, you have finished this course in the way that matters: not by remembering Asha's or Rina's or Mira's markup, but by being able to make the same decisions again, unaided, for content nobody wrote examples for in advance.
