015: HTML Review

Learning outcomes

By the end of this lesson, you should be able to reconstruct semantic HTML from a screenshot and a content brief without copying the original source. You should also be able to diagnose common structural, path, media, table, and form defects; validate the result and test it with a keyboard when time is limited; and explain your decisions in a ten-question written and code review.

Prerequisites and retrieval

Have your finished portfolio nearby, but begin today's timed task in a new folder. Before looking anything up, write the standard document skeleton, five landmark or section elements, and the rule for associating a label with a form control. Retrieval is useful here because it shows what you understand, not what you can reproduce by copying.

Terminology

• Reconstruction: implementing from observable requirements without taking source code (course term).
• Visual inference: a tentative conclusion drawn from appearance that still has to be checked against content meaning (course term).
• Content brief: the authoritative text, destinations, purpose of media, and required interactions (course term).
• Timebox: a fixed period that forces you to prioritize (course term).
• Diagnosis: finding the root cause from evidence instead of treating only the visible symptom (course term).
• Parser recovery: browser-defined handling that produces a DOM even from erroneous markup, which can conceal defects. — Source: WHATWG: Parse errors
• Verification: demonstrating that requirements are met through tests (course term).
• Tradeoff: a 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 captures one rendering at one viewport. It cannot reliably tell you whether a title is an h1, a card is an article, the columns come from CSS layout, or a control has a label associated with it. Reproducing the pixels with tables, repeated <br> elements, empty wrappers, or heading ranks selected by font size produces the wrong document even when the screenshot looks close.

Start with both sources of evidence:

• screenshot: visual grouping, prominence, sequence, and likely repeated patterns;
• brief: purpose, exact content, heading relationships, destinations, actions, image meaning, and form requirements.

When those inputs seem to disagree, protect meaning and operation first. CSS can reproduce the visual arrangement later. The HTML you write now should still be an excellent document when all styling is removed.

Review matrix: what a strong HTML developer should be able to explain

Use this matrix as a preflight check before the timed rebuild. For each row, try to choose the relevant HTML and defend the choice without looking up the answer first:

If one row feels shaky, revisit that lesson before starting the rebuild. The point of review is to expose weak mental models, not to rehearse a list of 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. For verification, serve that folder with python -m http.server 8000, open http://localhost:8000/, and run both the keyboard checks and the 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

1. 0-5 minutes: annotate regions and heading outline.
2. 5-12: create skeleton, metadata, landmarks, navigation/fragments.
3. 12-25: implement content, lists, image, articles, table.
4. 25-35: implement labeled/grouped validated form.
5. 35-40: inspect paths, IDs, headings, names, alt/dimensions.
6. 40-45: keyboard test and Nu check; fix earliest root causes.

Do not start styling. If the clock gets tight, finish correct core semantics before adding optional media polish.

Guided example: derive the outline and structure

Begin by turning the brief into an outline. The outline makes the hierarchy explicit before wrappers and attributes distract you:

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)

Here is one complete rebuild based on that outline:

<!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 wrapper choices do not have to match this document character for character. For instance, the About figure could sit outside its section if the content's meaning justified that choice. What matters in an assessment is an explicit rationale, not visual or textual imitation.

Intermediate example: diagnose ten defects

Read the snippet as evidence of several independent problems rather than trying to repair it from the first line onward:

<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: the document is missing a doctype, language, charset, and viewport; its title is vague; navigation is fake and has no destination; the heading order is inverted; the image has weak alt text and no dimensions; the table has no caption, headers, or scope; a change operation uses GET, which can expose submitted data in the URL; the email control has no label, name, or autocomplete; the textarea's label does not match its ID, it has no name, and value is not how its initial text is supplied; and the fake button uses a positive tabindex. One line can contain several root causes, so do not assume one correction per line.

Advanced optional extension: explain tradeoffs

Explain these three choices in your own words:

• Why article for projects but li for skills?
• Why one h1 even though multiple are conforming possibilities?
• Why native validation remains while server validation is required?

Then propose what CSS and JavaScript could add without changing the core semantics. CSS can provide a responsive visual grid and focus styles. JavaScript might enhance error summaries, but it should preserve native names, the operation, and server checks.

Common mistakes and debugging

• Copying source from the screenshot's site: defeats reconstruction and may copy defects or licensed work.
• Encoding visual columns as tables: determine the data relationships first.
• Omitting content when image unavailable: write the equivalent purpose.
• Time spent polishing indentation while controls fail: prioritize operation, then clarity.
• Browser rendering mistaken for correctness: inspect the DOM and run Nu.
• First validator error ignored: parser cascades can obscure later diagnosis.
• Answers recite tags: explain user and content purpose, along with alternatives considered.
• Finishing at minute 45 without tests: reserve the final ten minutes.

Accessibility, security, and performance

The rebuild needs to work from a keyboard, maintain logical headings and landmarks, use meaningful links and appropriate alt text, associate table headers correctly, and provide form labels, groups, and instructions. Native focus should remain visible. Screenshot fidelity never outranks these requirements, and no single review establishes WCAG conformance.

Use fictional submissions. GET must not expose message or personal data in a query string; POST still requires HTTPS and server-side validation. Treat generated output as something that needs encoding and authorization where applicable. Reserve image dimensions to reduce layout shifts, optimize the files, avoid autoplay and custom widgets, and let semantic HTML do its job before adding enhancements.

Tiered exercises

Level 1: plan

In five minutes, produce the content inventory, outline, landmark map, and file paths.

Level 2: timed rebuild

Implement the brief in 45 minutes, keeping ten minutes for keyboard and conformance checks.

Level 3: written/code review

Without reference notes, answer ten questions and repair the defective snippet. Then compare your reasoning with the provided solutions.

Level 1: use the guided outline. Map identity and navigation to header, unique content to main, each named theme to section, independent experiences to article, 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:

1. Internet vs Web? Internet is network infrastructure; Web is linked resources transferred mainly with HTTP.
2. Why doctype? It selects standards mode for normal HTML documents.
3. Why heading ranks? They express content hierarchy, not font size.
4. Relative path basis? The URL of the document containing the reference.
5. Empty alt when? The image is decorative or redundant in that context.
6. Why table scope? It associates simple row/column headers with data.
7. ID versus name? ID identifies or labels in the document; name keys submitted form data.
8. Link versus button? A link navigates; a button performs an action.
9. Why native HTML before ARIA? Native elements provide semantics and behavior; ARIA only changes accessibility semantics and can conflict.
10. 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 navigation links; one logical h1 followed by h2; context-specific alt text and dimensions; caption, th, and scope; POST; explicit label/ID/name/autocomplete; textarea content between its tags with matching ID and name; and a native submit button with no positive tabindex.

Recap and exit questions

HTML mastery is the ability to derive meaning from content, implement native semantics, find root causes, and prove behavior. A screenshot is evidence about presentation; it is not evidence of the source semantics.

1. What information can a screenshot not provide?
2. How should time be divided in a rebuild?
3. Which defects are highest priority?
4. Why can two different structures both be correct?
5. Can you explain every chosen element without citing its appearance?

Try it with your own example

For your own final timed rebuild, do not reuse Mira Chen's brief verbatim. Instead, write a two-minute brief for a business or person you actually know (a real bakery, a relative's small shop, or a friend's portfolio), the way this course wrote one for Rina across the last fourteen lessons. Creating the brief yourself and working under time pressure is much closer to a real freelance or job-interview task than rebuilding one you already memorized.

Give yourself the same five-minute planning limit before starting:

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 use the same 45-minute clock as the timed brief in this lesson. When you finish, answer the three tradeoff questions from the advanced section, this time about your own choices rather than Mira's. If you can explain why you chose article instead of li for your own real content without looking back at an earlier lesson, you have completed the course in the way that matters: not by remembering Asha's, Rina's, or Mira's markup, but by making the same decisions again, unaided, for content no one prepared as an example.

Official references

• WHATWG HTML Living Standard

• WHATWG HTML Living Standard

• MDN: Structuring content with HTML

• MDN: Debugging HTML

• W3C WCAG 2.2

• W3C WAI: Page Structure Tutorial

• W3C WAI: Easy Checks

• Nu HTML Checker