012: HTML Page Architecture

Learning outcomes

By the end of this lesson, you should be able to plan a page before writing markup, turn a content inventory into a heading and landmark structure, keep navigation consistent across pages, recognize reusable patterns without copying the wrong IDs or state, and keep content and structure separate from presentation.

Prerequisites and retrieval

Start with the portfolio landmarks and accessibility audit. Before opening the code, describe the site's purpose, its primary audience, the three most important tasks, and the major content it needs. If those answers are still vague, adding more containers will only hide the architectural problem; it will not solve it.

Terminology

Content inventory: a list of the content and functionality that must exist (course term).
Information architecture: the organization, hierarchy, and naming that help people find and understand content (course term).
Page architecture: the landmarks, sections, heading hierarchy, and meaningful order of a document (course term).
Content brief: the required content and its purpose, considered independently of visual layout (course term).
Reusable pattern: a consistently structured unit such as a project article (course term).
Template: a shared page skeleton in which the page-specific content changes (course term).
Source order: the order in which elements appear in markup; it drives reading and focus order. — Source: WCAG 2.2: Meaningful Sequence
Presentation: visual treatment that belongs in CSS rather than in HTML structure. — Source: WHATWG: HTML Introduction
Progressive enhancement: start with robust content and functionality, then add presentation and behavior (course term).
Information Architecture (official): "The structural design of shared information environments — organization, labeling, navigation, and search systems." — Source: Wikipedia: Information architecture — intuitive summary; see MDN: Structuring documents
Content inventory (official): "A comprehensive catalog of content items and their attributes." — Source: MDN: Structuring documents
Page architecture (local construct): "This course's term for a document's landmarks, sections, heading hierarchy, and meaningful order — not a W3C spec term, but applied via WHATWG sections and WCAG Meaningful Sequence." — Source: WHATWG: Sections & WCAG 2.2: Meaningful Sequence

Mental model: blueprint before paint

An architect decides what rooms a building needs and how people will move between them before choosing the wall colors. Page architecture works the same way. Establish the user's goals, the content, its hierarchy, and its reading order before visual styling. A screenshot can hint at visual grouping, but it cannot tell you what those regions mean. Ask what each region is, not merely where it happens to appear.

Use this sequence:

Define the page's purpose and the user's primary tasks.
Inventory the required content and controls.
Group related content and give each group a name.
Write a plain-text heading outline.
Choose landmarks and semantic elements.
Place the content in a meaningful source order.
Add links, forms, and media using the rules already established.
Validate and test accessibility before styling.

Reusable page shells without duplicate semantics

A multi-page site commonly repeats a shell: the site header, primary navigation, main content area, and footer. Reuse that structure, but let each page keep the semantics that belong to it. The shell can be shared without pretending that every page has the same title, current location, or content.

Copying markup mechanically is where problems usually enter:

the same id is duplicated inside one document;
every page keeps the same title even though the body content changed;
an aria-current="page" marker is copied to the wrong navigation item;
a section heading remains after the content of that section has been removed;
form controls are cloned with duplicate id values while their labels still point to the first control.

A server-side template or component system does not remove these constraints. When the shell is generated later, reuse still has to preserve valid relationships across the document, not just produce matching pixels.

It helps to separate the architecture into two layers:

site-wide invariants — primary navigation order, brand link, language, and footer structure;
page-specific data and semantics — title, h1, canonical URL, current navigation state, article content, and forms.

That boundary gives future templates or components a sound foundation. Reuse the stable structure, while supplying the values and relationships that are correct for the current document.

Guided example: plan a portfolio page

Begin with a content brief rather than with tags or a visual mockup:

Purpose: introduce Asha and help visitors inspect work or make contact.
Audience: potential collaborators and visitors.
Tasks: understand role; review projects; contact Asha.
Content: site name, navigation, introduction, about summary, skills,
two projects, availability note, contact link, footer.

A plain-text outline makes the relationships visible before HTML gets involved:

Building useful, accessible websites (h1)
  About me (h2)
  Skills (h2)
  Projects (h2)
    Weather summary (h3)
    Course schedule (h3)
  Contact (h2)

The corresponding architecture map is deliberately small:

header: identity + primary nav
main: h1/introduction + thematic sections
  projects section: reusable project articles
  optional aside: secondary availability note
footer: contact/legal information

Now translate that plan into a document:

<!doctype html>
<html lang="en">
  <head>
    <meta charset="utf-8">
    <meta name="viewport" content="width=device-width, initial-scale=1">
    <title>Portfolio | Asha Rao</title>
  </head>
  <body>
    <header>
      <p>Asha Rao</p>
      <nav aria-label="Primary">
        <ul>
          <li><a href="index.html" aria-current="page">Home</a></li>
          <li><a href="about.html">About</a></li>
          <li><a href="contact.html">Contact</a></li>
        </ul>
      </nav>
    </header>
    <main>
      <h1>Building useful, accessible websites</h1>
      <p>I turn clear content plans into semantic, accessible pages.</p>
      <section>
        <h2>About me</h2>
        <p>I focus on robust, accessible foundations and clear content structure.</p>
      </section>
      <section>
        <h2>Skills</h2>
        <ul><li>Semantic HTML</li><li>Accessibility testing</li></ul>
      </section>
      <section>
        <h2>Projects</h2>
        <article>
          <h3>Weather summary</h3>
          <p>A structured explanation of local forecast data.</p>
          <p><a href="projects/weather.html">Weather project details</a></p>
        </article>
        <article>
          <h3>Course schedule</h3>
          <p>An accessible comparison of study sessions.</p>
          <p><a href="projects/schedule.html">Course schedule details</a></p>
        </article>
      </section>
      <section>
        <h2>Contact</h2>
        <p><a href="contact.html">Send Asha a message</a></p>
      </section>
    </main>
    <footer><p><small>Copyright 2026 Asha Rao</small></p></footer>
  </body>
</html>

The document is intentionally unstyled. It is still understandable in source order and functions as a document without CSS. The ordinary sections do not need ARIA labels: their visible headings already give them structure, and turning every section into a region landmark would add noise. What matters here is that each section has a clear topic and that the headings express the hierarchy explicitly.

Reusable structures and consistency

The two project articles use the same pattern: a heading, a summary, and a detail link. Reuse that pattern, not the exact content or IDs. If the article headings need IDs, generate a unique ID for each one. A static HTML site repeats its navigation by hand, so use a checklist or adopt a templating system later to keep it consistent. Preserve the order, wording, and destinations; change only aria-current="page" and the document-specific title and heading.

Consistent navigation does not require every page to contain every possible link. It requires repeated mechanisms to appear in the same relative order and to use consistent names. If only one page calls Contact “Get in touch,” a visitor may reasonably assume the link leads to something different.

Keep presentation out of the architecture plan. Do not add empty divs to create columns, <br> elements to create card spacing, heading levels to obtain a particular type size, tables for layout, or inline style attributes. A neutral wrapper can be added later when CSS genuinely needs one, but it must not take the place of meaningful HTML.

Intermediate example: multi-page template audit

Audit index.html, about.html, and contact.html by separating what should stay shared from what must change:

Shared	Page-specific
doctype, charset, viewport	title
page header and nav order	`aria-current` link
page footer	`main` content and `h1`
language when same	metadata truly unique to page

Build each page from that distinction. The About page must not retain Home's aria-current, and Contact must not retain title>Home. Every document needs one clear main topic and a unique title. If the footer contains contact information, that information should remain accurate on every page.

Test with the keyboard and with CSS disabled, or before CSS exists. The DOM and source order should express the intended reading order. A later visual design might place an aside next to the projects, but that aside should still occur at a sensible point in source order and should not cut through a project article.

Advanced optional extension: content model and maintenance decisions

Imagine that a server will generate the project cards later. Define a content contract for the information, rather than an API for a particular visual component:

project: title, concise summary, detail URL, optional informative image,
status text, technologies list

Give each field an appropriate semantic destination: the title is an h3, the summary a p, the detail URL an a, an informative image a figure/img when useful, status text a paragraph, and technologies a ul. Validate the data and safely encode untrusted output on the server. This contract keeps future rendering consistent without locking the content to one visual layout.

Good architecture is not the same as maximum abstraction. Two static pages do not need a new build system during an HTML lesson. Notice repetition now, then automate when the benefit justifies the added complexity.

Common mistakes and debugging

Starting from boxes in a screenshot: inventory the content and write the outline first.
One section per visual card automatically: confirm that each card represents a named thematic grouping or an article.
Heading levels changed for styling: restore the content hierarchy and use CSS for appearance.
Inconsistent nav order/text: compare all pages side by side.
Copied aria-current or IDs: correct the current state and uniqueness for each document.
Missing unique page title/h1: give every document a distinct title and main topic.
Presentation embedded in markup: remove spacing breaks, layout tables, and obsolete attributes.
Too many wrappers/landmarks: keep the smallest structure that communicates meaning.
Architecture treated as immutable: revise the grouping when the content or user tasks expose a better one.

Accessibility, security, and performance

Meaningful source order, consistent navigation, descriptive titles, headings, landmarks, and bypass mechanisms all support WCAG requirements. Predictable architecture also reduces cognitive load. Do not label every region just because you can: excessive landmarks make navigation harder. Check reading and focus order before a visual rearrangement hides problems.

Content planning should include data minimization and basic threat thinking. A contact section should not reveal unnecessary personal details. Generated content must be safely encoded, and external media may track users. Reusable, lean markup helps avoid repeated defects and unnecessary bytes, while a content-first page remains useful while slow CSS or scripts are loading. Performance is not a reason to remove semantic text or its alternatives.

Tiered exercises

Level 1: inventory and outline

Write the portfolio's purpose, audience, three tasks, content inventory, and heading-only outline.

Level 2: implement

Build the complete unstyled portfolio architecture with navigation, introduction, about, skills, project articles, contact, and footer.

Level 3: consistency audit

Create or check three pages against their shared and unique fields, source order, links, IDs, current state, headings, and validation.

Level 1: the guided brief and outline provide a complete model. Different personal content is also correct when the purpose, audience, tasks, and heading relationships are explicit.

Level 2: use the guided complete document. The two projects are independent articles under Projects; skills are represented by a list; Contact uses a link; and the page-wide regions are header/nav/main/footer. No visual-layout markup is necessary.

Level 3: every page shares the skeleton, navigation order and names, and footer. Each page has a distinct descriptive title, one page-specific h1, exactly one correct aria-current="page", unique IDs, valid relative links, one visible main, and a logical heading and source order. Run Nu checker and keyboard navigation on every page, not just Home.

Recap and exit questions

Page architecture begins with user tasks and content. A plain outline becomes semantic regions in meaningful source order. Patterns can be reused consistently, but page state, IDs, titles, and content must remain specific to each document.

What should be planned before markup?
What belongs in a project article pattern?
Which fields differ across otherwise shared page templates?
Why should source order make sense without CSS?
When is a generic wrapper appropriate?

Try it with your own example

Apply the eight-step planning sequence to Rina's site on paper before touching an editor. That is the practical value of architecture: changing a plan on paper is cheap, while changing an established markup structure is expensive.

Write Rina's content brief in the same shape as Asha's:

Purpose: help nearby customers see today's menu, learn opening hours,
and order a custom cake.
Audience: neighbourhood regulars and people searching "bakery near me."
Tasks: check what's available today; check hours; order a cake ahead.
Content: shop name, primary nav, today's specials, opening-hours table,
cake order form, footer with address and hours.

Then write only the heading outline. Do not choose tags yet:

Rina's Kitchen (h1)
  Today's specials (h2)
  Opening hours (h2)
  Order a custom cake (h2)

Before writing any HTML, answer this out loud: does "Opening hours" deserve its own section, or is it small enough to sit directly in main under a heading without a wrapping section, as lesson 006 said was equally valid for Asha's introduction? There is no single correct answer. You should be able to defend the choice by pointing to the content, not to how you imagine the finished page will look. That is architecture rather than decoration.

Further reading: MDN — Structuring documents revisits this planning sequence with a news-article example, giving you a third point of comparison.