Let’s build a small lesson page together. We are choosing landmarks so a learner can move directly to the central explanation instead of repeatedly hearing the same header and navigation. The browser can render divs, but semantic elements tell people and assistive technology what each region actually owns.

We are building a page another person can understand without our help. That means the HTML must communicate structure before CSS, JavaScript, analytics, or a component framework enters the picture.

As we read each example, identify the region, its owner, and the user action it supports. If CSS disappeared, the page should still reveal a banner, navigation, one main task, optional supporting content, and a footer.

• Name the purpose before choosing the element.
• Test the keyboard or reading order after writing it.
• Keep visual layout classes separate from document meaning.

A small honest page is more valuable than a large page of copied tags. We will use each example as a decision we can explain, test, and reuse.

Let’s work through this decision slowly. Create the page landmarks is useful because it gives the document a truthfully named boundary rather than a visual box with hidden meaning.

First identify the element and its owner. Next predict what a learner can do with it. Finally, change one attribute or heading and explain whether the meaning remains honest. This is how we turn tag knowledge into a dependable engineering habit.

HTML

<header><h1>AlgoGalaxy Notes</h1></header>
<nav aria-label="Primary"><a href="/learn">Learn</a></nav>
<main><h2>Today’s lesson</h2><p>Semantic HTML.</p></main>
<footer>© AlgoGalaxy</footer>

Landmark list: banner, navigation (Primary), main, contentinfo.

Teacher check: do not merely copy the tag. State the learner impact in one sentence before you keep it in a production page.

Let’s work through this decision slowly. Name two navigation regions is useful because it gives the document a truthfully named boundary rather than a visual box with hidden meaning.

First identify the element and its owner. Next predict what a learner can do with it. Finally, change one attribute or heading and explain whether the meaning remains honest. This is how we turn tag knowledge into a dependable engineering habit.

HTML

<nav aria-label="Primary"><a href="/courses">Courses</a></nav>
<main>
  <nav aria-label="On this page"><a href="#landmarks">Landmarks</a></nav>
  <h1 id="landmarks">Landmarks</h1>
</main>

A screen reader announces “Primary navigation” and “On this page navigation.”

Teacher check: do not merely copy the tag. State the learner impact in one sentence before you keep it in a production page.

Let’s work through this decision slowly. Keep the lesson in main is useful because it gives the document a truthfully named boundary rather than a visual box with hidden meaning.

First identify the element and its owner. Next predict what a learner can do with it. Finally, change one attribute or heading and explain whether the meaning remains honest. This is how we turn tag knowledge into a dependable engineering habit.

HTML

<main>
  <article>
    <h1>Build a semantic document</h1>
    <p>We will identify each landmark before adding CSS.</p>
  </article>
</main>
<aside aria-label="Lesson resources"><a href="/glossary/landmark">Glossary</a></aside>

The article is primary content; the glossary remains supporting material.

Teacher check: do not merely copy the tag. State the learner impact in one sentence before you keep it in a production page.

Let’s work through this decision slowly. Give the article its own footer is useful because it gives the document a truthfully named boundary rather than a visual box with hidden meaning.

First identify the element and its owner. Next predict what a learner can do with it. Finally, change one attribute or heading and explain whether the meaning remains honest. This is how we turn tag knowledge into a dependable engineering habit.

HTML

<article>
  <h2>Semantic HTML review</h2>
  <p>Landmarks make a page easier to navigate.</p>
  <footer><p>Written for the HTML course.</p></footer>
</article>

The footer is clearly owned by this article.

Teacher check: do not merely copy the tag. State the learner impact in one sentence before you keep it in a production page.

Let’s work through this decision slowly. Offer a skip link is useful because it gives the document a truthfully named boundary rather than a visual box with hidden meaning.

First identify the element and its owner. Next predict what a learner can do with it. Finally, change one attribute or heading and explain whether the meaning remains honest. This is how we turn tag knowledge into a dependable engineering habit.

HTML

<a href="#main-content">Skip to lesson</a>
<header><h1>AlgoGalaxy</h1></header>
<nav aria-label="Primary">...</nav>
<main id="main-content"><h2>Semantic HTML</h2></main>

The first keyboard link moves the learner directly to main content.

Teacher check: do not merely copy the tag. State the learner impact in one sentence before you keep it in a production page.

Now review the page as a learner would. Can you reach main quickly? Does every heading describe a real topic? Does every control have the native behavior its label promises?

• Read the heading outline without using font size.
• Tab from the first interactive element into the lesson.
• Replace one vague div, link, or heading with the element that states the real intent.

Semantic HTML is not extra decoration for accessibility. It is the clearest explanation of the document we are already trying to build.

Start by naming the value the next line depends on. This keeps the lesson input explicit before we apply a transformation or call an external boundary. We are applying that habit while revisiting HTML Semantic HTML: Document Landmarks.

Keep the example small enough to trace. First predict the normal result; then change one input and explain the boundary result in your own words.

HTML

<label for="lesson-7">HTML Semantic HTML Document Landmarks</label>
<input id="lesson-7" name="lesson" value="HTML Semantic HTML Document Landmarks" />
<p id="result-7">Ready to practice</p>

A labelled input and a readable result are rendered.

Try next: Replace the sample value with one from your own notes, predict the result, and then run it.

A small guard makes the allowed and rejected path visible. We want a caller to receive an intentional result instead of discovering an unexplained failure later. We are applying that habit while revisiting HTML Semantic HTML: Document Landmarks.

Keep the example small enough to trace. First predict the normal result; then change one input and explain the boundary result in your own words.

HTML

<label for="lesson-8">HTML Semantic HTML Document Landmarks</label>
<input id="lesson-8" name="lesson" value="HTML Semantic HTML Document Landmarks" />
<p id="result-8">Ready to practice</p>

A labelled input and a readable result are rendered.

Try next: Try an empty value as well as the normal value and describe why the two outcomes differ.

This step returns a value instead of mixing the rule with display or storage work. That separation gives us a small unit we can run, test, and reuse. We are applying that habit while revisiting HTML Semantic HTML: Document Landmarks.

Keep the example small enough to trace. First predict the normal result; then change one input and explain the boundary result in your own words.

HTML

<label for="lesson-9">HTML Semantic HTML Document Landmarks</label>
<input id="lesson-9" name="lesson" value="HTML Semantic HTML Document Landmarks" />
<p id="result-9">Ready to practice</p>

A labelled input and a readable result are rendered.

Try next: Call the same rule twice with different inputs and confirm that each result depends only on its input.

Use a named branch where the business rule changes. A future reader should be able to point at the condition and state the result for both sides. We are applying that habit while revisiting HTML Semantic HTML: Document Landmarks.

Keep the example small enough to trace. First predict the normal result; then change one input and explain the boundary result in your own words.

HTML

<label for="lesson-10">HTML Semantic HTML Document Landmarks</label>
<input id="lesson-10" name="lesson" value="HTML Semantic HTML Document Landmarks" />
<p id="result-10">Ready to practice</p>

A labelled input and a readable result are rendered.

Try next: Change the boundary value by one and explain exactly which branch becomes active.

Collections become safer when we can see which value is read, which value is derived, and whether the original collection remains owned by the caller. We are applying that habit while revisiting HTML Semantic HTML: Document Landmarks.

Keep the example small enough to trace. First predict the normal result; then change one input and explain the boundary result in your own words.

HTML

<label for="lesson-11">HTML Semantic HTML Document Landmarks</label>
<input id="lesson-11" name="lesson" value="HTML Semantic HTML Document Landmarks" />
<p id="result-11">Ready to practice</p>

A labelled input and a readable result are rendered.

Try next: Add one more item and predict the derived result before executing the code.

A named outcome is easier to test than an implied side effect. We can now distinguish a successful path from a rejected path without guessing from console noise. We are applying that habit while revisiting HTML Semantic HTML: Document Landmarks.

Keep the example small enough to trace. First predict the normal result; then change one input and explain the boundary result in your own words.

HTML

<label for="lesson-12">HTML Semantic HTML Document Landmarks</label>
<input id="lesson-12" name="lesson" value="HTML Semantic HTML Document Landmarks" />
<p id="result-12">Ready to practice</p>

A labelled input and a readable result are rendered.

Try next: Rename the outcome in your own words while preserving the same success and failure rule.

Work through one value at a time. The point is not to memorize syntax; it is to see how the accumulator or output changes after each repeatable step. We are applying that habit while revisiting HTML Semantic HTML: Document Landmarks.

Keep the example small enough to trace. First predict the normal result; then change one input and explain the boundary result in your own words.

HTML

<label for="lesson-13">HTML Semantic HTML Document Landmarks</label>
<input id="lesson-13" name="lesson" value="HTML Semantic HTML Document Landmarks" />
<p id="result-13">Ready to practice</p>

A labelled input and a readable result are rendered.

Try next: Use a shorter collection first, then add one value and trace the extra iteration aloud.

The core rule prepares a value, while the outer line decides how to show it. That keeps the result usable by a UI, test, API, or command-line caller. We are applying that habit while revisiting HTML Semantic HTML: Document Landmarks.

Keep the example small enough to trace. First predict the normal result; then change one input and explain the boundary result in your own words.

HTML

<label for="lesson-14">HTML Semantic HTML Document Landmarks</label>
<input id="lesson-14" name="lesson" value="HTML Semantic HTML Document Landmarks" />
<p id="result-14">Ready to practice</p>

A labelled input and a readable result are rendered.

Try next: Change only the display text and verify that the underlying rule and result stay unchanged.

A useful example includes the nearest boundary, not only the happy path. We are making the behavior inspectable before a real caller relies on it. We are applying that habit while revisiting HTML Semantic HTML: Document Landmarks.

Keep the example small enough to trace. First predict the normal result; then change one input and explain the boundary result in your own words.

HTML

<label for="lesson-15">HTML Semantic HTML Document Landmarks</label>
<input id="lesson-15" name="lesson" value="HTML Semantic HTML Document Landmarks" />
<p id="result-15">Ready to practice</p>

A labelled input and a readable result are rendered.

Try next: Try the lowest supported value and then one value just outside the accepted range.

A compact assertion turns the lesson into a repeatable promise. It helps us catch a changed rule before a larger program hides the source of the mistake. We are applying that habit while revisiting HTML Semantic HTML: Document Landmarks.

Keep the example small enough to trace. First predict the normal result; then change one input and explain the boundary result in your own words.

HTML

<label for="lesson-16">HTML Semantic HTML Document Landmarks</label>
<input id="lesson-16" name="lesson" value="HTML Semantic HTML Document Landmarks" />
<p id="result-16">Ready to practice</p>

A labelled input and a readable result are rendered.

Try next: Deliberately change the expected value once, observe the failed check, and then restore the correct contract.

Open one page you already own and sketch its header, navigation, main task, supporting material, and footer. Then compare that sketch with its source. Each mismatch gives you one focused improvement to make.

When you can explain why an element exists, who owns it, and what a learner experiences through it, you are designing a dependable document instead of copying HTML.