See every element of a production-ready page in one place — what each section does, who it serves, and why the structure is the way it is.
A web page has two major sections:
<head>
and
<body>.
What is the fundamental difference between what goes in each one?
<head>
contains instructions and identity information for software — browsers, search engines, social platforms, and AI crawlers. None of it is visible to the page visitor.
<body>
contains the actual page content — everything a visitor sees and interacts with. The
<body>
is structured with semantic landmark elements (
<header>,
<main>,
<footer>)
that tell browsers, screen readers, and search engines what role each region of the page plays.
This course covers every major HTML concept in its own lecture. But before going deep on any single topic — forms, tables, images, accessibility, navigation — it is worth seeing the complete picture first. A real, production-ready HTML page, annotated by purpose, showing how every piece connects to every other piece. That map is what this lecture provides. Every subsequent lecture zooms into one region of it.
A complete HTML page has two distinct layers. The
<head>
layer is invisible — it communicates with browsers, search engines, and social platforms. The
<body>
layer is visible — it communicates with human visitors. Inside the body, landmark elements divide the page into named regions: header, navigation, main content, sidebar, and footer. Inside those regions, content elements — headings, paragraphs, lists, images, forms, tables — carry the actual information.
The structure of an HTML page is not arbitrary. Semantic elements — elements whose names describe their purpose — carry meaning that plain
<div>
containers do not. A
<nav>
tells screen readers "this is navigation." A
<main>
tells search engines "this is the primary content." An
<article>
tells AI crawlers "this content is self-contained and meaningful on its own." Choosing the right element is not a style preference — it changes how the page is understood by every non-human system that reads it.
After reading this lecture you will be able to look at any professional website's source code and recognise its structure immediately. The rest of this course teaches you how to write each section well — but the map you are about to see is the thing that makes all those individual lessons click into place.
A complete, production-ready HTML page — annotated by purpose
The skeleton: DOCTYPE, html, head, body — Every HTML page starts with
<!DOCTYPE html>,
which tells the browser this is a modern HTML5 document (without it, browsers enter "quirks mode" and apply old, inconsistent rendering rules).
<html lang="en">
is the root element — the
lang
attribute tells screen readers which language pronunciation engine to use and tells search engines which language audience to serve the page to.
<head>
holds everything invisible.
<body>
holds everything visible. This four-element skeleton is the container for everything else.
The body's outer structure: skip link, header, main, footer — The first element inside
<body>
is always the skip link — a visually hidden link that keyboard users Tab to first, letting them jump past navigation directly to the content. Then
<header>
with the site logo and primary navigation, then
<main>
with the page's primary content (one per page, never inside header or footer), then
<footer>
with legal links and copyright. This outer structure is the same on every page of every site — it is the universal pattern.
Inside main: sections, articles, and heading hierarchy — The content inside
<main>
is divided into named
<section>
elements, each labelled with
aria-labelledby
pointing to its heading. There is exactly one
<h1>
on the page — the page title in the hero section. Major sections get
<h2>.
Self-contained items within sections (individual service cards, blog posts, products) get
<article>
with
<h3>.
This heading hierarchy is the page's outline — screen reader users navigate by it, search engines use it to understand topic structure.
The content elements: each in its right place — The table appears in the pricing section because the data is genuinely tabular. The
<details>
FAQ uses a native HTML accordion — zero JavaScript, fully accessible. The form uses
method="post",
labelled inputs with matching
for
and
id,
correct input types, and
required
attributes. The map embed has a
title
on the iframe and
loading="lazy".
The image has a real
alt
description and explicit dimensions. Each of these details is a separate lecture in this course — but here you can see where each one fits in the page as a whole.
What this page does for each audience — A sighted mouse user sees a structured, readable page with a working form and expandable FAQ. A keyboard user can Tab to the skip link, jump to main content, navigate sections by heading, and submit the form entirely without a mouse. A screen reader user hears named landmarks, correctly announced headings, labelled form fields, and a described image. A search engine crawler sees a keyword-first title, a canonical URL, a clear h1, semantic sections, and alt text on images. An AI crawler finds structured content with explicit meaning. The same HTML serves all of them simultaneously — that is what correct HTML does.
The map makes the lessons land
Learning forms before seeing where a form lives in a page, or learning tables before seeing that tables go inside sections, means learning pieces with no context. This complete page gives every subsequent lesson a home — students know before the lesson starts roughly where the new concept fits.
Every semantic element in this page — landmark, heading, label, alt text, scope attribute — serves at least two audiences at once. Correct HTML is not extra work for accessibility or SEO — it is one set of decisions that improves the experience for every kind of user and every kind of software that reads the page.
The outer structure never changes
The skip link, header, main, footer pattern is the same on every page of every professional website. Learning it once means you can immediately orient yourself in any codebase, contribute to any project, and build any new page from a reliable mental template.
Visual rendering is the least of it
A page can look exactly right in a desktop browser while failing completely for keyboard users, screen reader users, mobile users, search engines, and AI systems. The HTML in this lecture looks simple — but every element choice is a deliberate decision that makes the page work for all of those audiences at once.
Visually identical — but broken for every non-mouse audience
<html> <!-- no lang -->
<head>
<title>Page</title> <!-- no charset, no viewport,
no description, no canonical -->
</head>
<body>
<!-- no skip link -->
<div class="header">
<div class="nav"> <!-- not a <nav> -->
<span onclick="go('/')">Home</span>
</div>
</div>
<div class="main">
<h1>Welcome</h1>
<h1>Our Services</h1> <!-- two h1s -->
<h4>Design</h4> <!-- skipped h2, h3 -->
<img src="hero.jpg"> <!-- no alt, no dimensions -->
<input placeholder="Email"> <!-- no label, no type -->
<div onclick="submit()">Send</div> <!-- not a button -->
</div>
<div class="footer">…</div>
</body>
</html>
<!--
Keyboard user: cannot navigate, cannot submit form.
Screen reader: no landmarks, no headings, no labels.
Mobile user: 980px desktop layout, must pinch-zoom.
Search engine: two h1s, no description, no canonical.
AI crawler: no structured meaning, no language.
-->
Every audience served — same visual result, correct HTML
<html lang="en">
<head>
<meta charset="UTF-8">
<meta name="viewport"
content="width=device-width, initial-scale=1">
<title>Web Design Services – Acme Agency</title>
<meta name="description" content="...">
<link rel="canonical" href="https://acme.com/services">
</head>
<body>
<a href="#main-content" class="skip-link">
Skip to main content
</a>
<header>
<nav aria-label="Primary">
<ul><li><a href="/">Home</a></li></ul>
</nav>
</header>
<main id="main-content">
<h1>Web Design Services</h1>
<h2>What we offer</h2>
<img src="hero.jpg"
alt="Designer at work on a brand mockup"
width="1200" height="600">
<label for="email">Email address</label>
<input type="email" id="email" name="email">
<button type="submit">Send</button>
</main>
<footer>…</footer>
</body>
</html>
Paste your complete page HTML into ChatGPT and ask: "Audit this page for: correct DOCTYPE and lang attribute, semantic landmark structure (header/main/footer), one h1 with unbroken heading hierarchy, every image having alt and dimensions, every input having a linked label with matching for and id, all navigation using real anchor tags with href, and no interactive elements built from div or span." Use the result as a checklist. Then run a Lighthouse Accessibility audit in Chrome DevTools — it catches the measurable failures that code review cannot see, like actual keyboard focus order and colour contrast ratios.
View source on any page you use regularly (Ctrl+U or Cmd+U). Find the opening
<body>
tag. Is the first element a skip link? Find
<header>-->,
<main>,
and
<footer>.
Find every
<nav>
— does each have an
aria-label?
Find the
<h1>
— is there exactly one? This exercise makes the pattern recognisable in real code.
Build the outer skeleton of a page from memory — DOCTYPE, html with lang, head with the four essentials (charset, viewport, title, description), body with skip link, header, main with id, and footer. Do not look at the example. When you can write this skeleton in under two minutes, you have the foundation for everything else in the course.
Open Chrome DevTools on any page → Accessibility panel → Full page accessibility tree. Expand it. You should see a tree of landmark regions: navigation, main, contentinfo (footer). Each region should have a label. Each interactive element should have a name. If the tree looks flat or unnamed, the page's semantic structure is missing.
Press Tab on any web page and watch where focus goes. Does it start at the skip link? Does it move through navigation links in order? Does it reach the form inputs? Does it reach the submit button? If focus jumps around unpredictably or gets stuck, the page's HTML structure has keyboard accessibility problems you can now identify.
Run a Lighthouse audit on a page you have built — all four categories: Performance, Accessibility, Best Practices, SEO. Before studying the results, try to predict which issues will appear based on what you learned in this lecture. Then compare your predictions to the actual flags. The gap between prediction and result shows exactly which concepts to focus on in the upcoming lectures.
Building the page in
<div>
containers and adding semantic elements later as an afterthought. Semantic structure is not a finish coat — it is load-bearing. The heading hierarchy, landmark regions, and element choices determine keyboard navigation order, screen reader announcements, and search engine understanding. Build semantically from the first line.
Using more than one
<h1>
on a page, or skipping heading levels to control visual size. The heading hierarchy is the page outline — screen reader users navigate it like a table of contents. Two
<h1>
elements tell search engines the page has two primary topics. A jump from
<h1>
to
<h4>
breaks navigation. Use CSS to control visual size; use heading levels to express meaning.
Putting
<main>
inside
<header>
or
<footer>-->,
or nesting
<header>
and
<footer>
inside
<main>.
The site-wide header and footer are siblings of
<main>,
not children of it. The correct order is: skip link →
<header>
→
<main>
→
<footer>,
all as siblings inside
<body>.
Omitting the skip link because navigation "only has four links." On every page load, a keyboard user must Tab through every navigation link before reaching the content — regardless of how few links there are. A site with four navigation links and no skip link means four Tab presses wasted on every single page. The skip link is one line of HTML that eliminates this for every keyboard user, forever.
Assuming a page is correct because it looks right and works with a mouse. The bad code example in this lecture looks visually identical to the good example in a browser. The difference is entirely in the HTML — and it is the difference between a page that works for everyone and a page that works only for sighted mouse users. Always test with keyboard navigation and the Accessibility panel.
Identify every region of a complete HTML page — DOCTYPE, lang, head essentials, skip link, header with labelled nav, main with one h1 and labelled sections, semantic content elements in their correct positions, and footer with footer nav — and explain what each region communicates to each of its audiences: visitors, keyboard users, screen readers, search engines, and AI crawlers.
