012: HTML Page Architecture

Learning outcomes

By the end of this lesson, you can plan content before markup, turn a content inventory into a heading and landmark architecture, maintain consistent navigation across pages, identify reusable patterns without copying inappropriate IDs/state, and separate content/structure from presentation.

Prerequisites and retrieval

Review the portfolio landmarks and accessibility audit. Without opening code, describe the site's purpose, primary audience, top three tasks, and major content. If those answers are unclear, adding containers will not fix the architecture.

Terminology

Content inventory: list of content and functionality that must exist (course term).
Information architecture: organization, hierarchy, and naming that help users find and understand content (course term).
Page architecture: a document's landmarks, sections, heading hierarchy, and meaningful order (course term).
Content brief: required content and purpose, independent of visual layout (course term).
Reusable pattern: a consistently structured unit such as a project article (course term).
Template: shared page skeleton whose page-specific content changes (course term).
Source order: The order elements appear in markup, which drives reading and focus order. — Source: WCAG 2.2: Meaningful Sequence
Presentation: Visual treatment belonging to CSS rather than HTML structure. — Source: WHATWG: HTML Introduction
Progressive enhancement: start with robust content/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

Architects decide rooms and routes before wall colors. For a page, identify user goals, content, hierarchy, and reading order before visual styling. A screenshot can suggest grouping, but it cannot reveal intended semantics. Ask what each region is, not where it appears.

Use this sequence:

Define page purpose and primary user tasks.
Inventory required content and controls.
Group related content and name each group.
Write a plain-text heading outline.
Choose landmarks and semantic elements.
Put content in a meaningful source order.
Add links/forms/media with established rules.
Validate and accessibility-test before styling.

Reusable page shells without duplicate semantics

A multi-page site usually repeats a shell: site header, primary navigation, main content area, and footer. Reuse the structure, but keep page-specific semantics page-specific.

Common mistakes appear when markup is copied mechanically:

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 survives after its section content was removed;
form controls are cloned with duplicate id values while their labels still point to the first one.

When a server-side template or component system later generates the shell, the same rules still apply. Reuse must preserve valid document-wide relationships, not only produce matching visuals.

Think of architecture in two layers:

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

That distinction prepares your HTML to move into templates or components without losing correctness.

Guided example: plan a portfolio page

Content brief:

text
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.

Proposed outline:

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

Architecture map:

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

Translate it:

html
<!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>

This is intentionally unstyled. It remains understandable in source order and works as a document. Ordinary sections do not need ARIA labels here; visible headings already structure the content, and promoting every section to a region landmark would add noise. The important point is that every section has a clear topic and the headings create explicit hierarchy.

Reusable structures and consistency

The two project articles share a pattern: heading, summary, detail link. Reuse the pattern, not exact content or IDs. If article headings need IDs, make each unique. A static HTML site repeats navigation manually, so consistency requires a checklist or later templating system. Keep order, wording, and destinations stable. Update only aria-current="page" and document-specific title/heading.

Navigation consistency does not mean every page must contain every link. It means repeated mechanisms appear in the same relative order and use consistent identification. If Contact becomes “Get in touch” on only one page, users may wonder whether it differs.

Separate presentation: do not add empty divs for columns, <br> for card spacing, heading levels for type sizes, tables for layout, or inline style attributes while planning architecture. Neutral wrappers may be added later when CSS truly needs them, but they should not replace semantics.

Intermediate example: multi-page template audit

Compare index.html, about.html, and contact.html:

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

Create each page from this distinction. About should not retain Home's aria-current. Contact should not retain title>Home. Each document needs one clear main topic and unique title. Shared footer contact information should be accurate everywhere.

Test from the keyboard and with CSS disabled (or before CSS exists). The DOM/source order should match intended reading. A visual design might later place an aside beside projects; it should still occur at a sensible point in source and not interrupt a project article.

Advanced optional extension: content model and maintenance decisions

Suppose project cards will be generated by a server later. Define a content contract, not a presentational component API:

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

For each field, choose semantics: title h3, summary p, URL a, image figure/img if useful, status text in a paragraph, technologies ul. Validate data and encode untrusted output server-side. This contract makes future rendering consistent without freezing visual layout.

Architecture is not maximum abstraction. Two static pages do not need a new build system during HTML lessons. Recognize repetition now; automate only when benefits outweigh complexity.

Common mistakes and debugging

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

Accessibility, security, and performance

Meaningful source order, consistent navigation, descriptive titles, headings, landmarks, and bypass mechanisms support WCAG. Architecture reduces cognitive load by making pages predictable. Avoid over-labeling every region; landmark noise can hinder navigation. Test reading and focus order before visual rearrangement.

Content planning includes data minimization and threat thinking. A contact section should not expose unnecessary personal details; generated content must be safely encoded; external media can track users. Reusable, lean markup reduces repeated defects and bytes, while a content-first page remains useful before slow CSS/scripts arrive. Performance does not justify removing semantic text or alternatives.

Tiered exercises

Level 1: inventory and outline

Write the portfolio 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/check three pages against shared versus unique fields, source order, links, IDs, current state, headings, and validation.

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

Level 2: use the guided complete document. Both projects are independent articles under Projects; skills are a list; contact uses a link; page-wide regions are header/nav/main/footer. No visual-layout markup is needed.

Level 3: all pages share skeleton, navigation order/names, and footer. Each 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/source order. Run Nu checker and keyboard navigation on every page, not only Home.

Recap and exit questions

Page architecture starts with user tasks and content. An outline becomes semantic regions in meaningful source order; patterns are reused consistently while page state, IDs, titles, and content remain specific.

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

Run the eight-step planning sequence from this lesson on Rina's site for real, on paper, before you touch an editor — the whole point of architecture is that it's cheap to redo on paper and expensive to redo in markup.

Write your own content brief for Rina, in the same shape as Asha's:

text
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.

Now write only the heading outline — no tags yet:

text
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 live directly in main under a heading with no wrapping section at all, the way lesson 006 said was equally valid for Asha's introduction? There is no single correct answer — but if you can defend your choice by pointing at the content rather than at how you imagine it will look, you have done real architecture, not decoration.

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