Session 1: Semantic HTML
HTML is the structure of every page on the web, and semantic HTML — using elements for what they mean rather than how they look — is what separates a page that works from one that works for everyone, including search engines and assistive technology.
Learning objectives
By the end of this session you will be able to do each of these without prompting.
- Explain what HTML is and how a browser turns it into a page
- Structure a document with the right elements in the right order
- Use semantic elements so meaning is carried by the markup
- Write headings, links, images, lists and tables correctly
- Understand why semantics matter for accessibility and search
- Build a complete, valid multi-section page
The taught content
What HTML actually is
HTML is not a programming language and it does not do anything. It is a description of structure — a set of labelled boxes saying 'this is a heading', 'this is a paragraph', 'this is a link to somewhere else'. The browser reads that description and decides how to present it. That division matters: you describe the meaning, the browser and the stylesheet decide the appearance.
Every element is written the same way: an opening tag, the content, and a closing tag — `<p>Hello</p>`. Some elements have no content and close themselves, like `<img>` and `<br>`. Elements nest inside each other, and correct nesting is what gives a document its shape: a list item inside a list, a paragraph inside a section. Mismatched tags are the most common beginner error and the browser will try to guess what you meant, usually wrongly.
Then the anatomy of a page. `<!DOCTYPE html>` tells the browser which rules to use. `<html>` wraps everything. `<head>` holds information about the page — its title, character set, and links to stylesheets — none of which is displayed. `<body>` holds everything the visitor sees. Getting this skeleton right is the first thing, because everything else lives inside it.
Semantic versus presentational markup
Semantic HTML means using an element because of what it means, not because of how it happens to look. `<h1>` means 'this is the main heading', not 'this is big bold text'. `<nav>` means 'this is navigation'. `<button>` means 'this does something when activated'. The visual result is a consequence, not the purpose.
The alternative — using `<div>` and `<span>` for everything and styling it to look right — produces a page that appears identical and works far worse. A screen reader navigating by headings finds nothing. A search engine cannot tell your navigation from your content. A keyboard user cannot tab to the thing that looks like a button because it is not one. The page looks finished and is broken for anyone not using a mouse and eyes.
The practical test is simple: strip the CSS and read the markup. If the document still makes sense as an outline — headings in order, lists as lists, navigation identifiable — it is semantic. If it collapses into an undifferentiated wall of divs, the meaning was only ever in the styling, and styling can fail, be turned off, or be replaced by an assistive technology that ignores it entirely.
Headings, paragraphs and text
Headings are an outline, not a size picker. There is one `<h1>` per page — the subject of the page — and every heading below it is nested logically: `<h2>` for main sections, `<h3>` for subsections within those. Skipping levels because a size looks better breaks the outline, and the outline is what a screen reader user navigates by and what a search engine uses to understand the page.
If a heading is the wrong size, change the CSS, not the element. That single habit solves most heading misuse. `<h3>` styled to look like an `<h1>` is correct when it is third in the outline; `<h1>` used because it is biggest is wrong however good it looks.
Then the text elements, each with a job. `<p>` for a paragraph — and note that a line break is not a paragraph, so `<br>` between lines of prose is a common mistake. `<strong>` for genuine importance and `<em>` for emphasis, which are semantic, rather than `<b>` and `<i>`, which are only visual. `<a>` for a link, `<ul>` or `<ol>` for a list — and a list of things is a list even when it does not have bullets, because the structure is the point.
Links, images and media
A link is an anchor element with an href pointing somewhere and text between the tags, and the link text should describe the destination. 'Read our pricing' tells someone where they are going; 'click here' tells them nothing, and it is useless to a screen reader user scanning a list of links out of context, which is exactly how many people navigate. If a link's destination cannot be guessed from its text alone, the text is wrong.
Images require an `alt` attribute, and it is not optional decoration — it is the text that replaces the image when it cannot be seen. Write what the image conveys: `alt="Two students reviewing a spreadsheet in class"` rather than `alt="image"` or `alt="photo1.jpg"`. If an image is purely decorative and adds no information, use an empty `alt=""` so assistive technology skips it rather than announcing something meaningless.
Then the practical details. Set `width` and `height` so the browser reserves the space before the image loads, which prevents the layout jumping around — a real usability problem on a slow connection, which is most connections here. Use relative paths for your own files (`images/logo.png`) rather than absolute ones, or the page breaks the moment it moves to a different folder or server.
Lists, tables and document sections
Lists come in three kinds and choosing correctly is a semantic decision. `<ul>` for items with no meaningful order — a menu, a set of features. `<ol>` for items where the order matters — steps in a process, a ranking. `<dl>` for terms and definitions. Using a `<ul>` for a numbered procedure loses the information that the order matters.
Tables are for tabular data — rows and columns that genuinely relate — and never for layout. A table used for layout produces a page that cannot be read in a sensible order by assistive technology and collapses badly on a phone. Within a real table, `<th>` marks a header cell and `<caption>` names the table; both are what makes the data comprehensible rather than a grid of unexplained numbers.
Then the sectioning elements that give a document its shape: `<header>` for the introductory area, `<nav>` for navigation, `<main>` for the primary content — exactly one per page — `<section>` for a themed grouping, `<article>` for something self-contained that would make sense on its own, `<aside>` for related but tangential content, and `<footer>` for the closing area. These are not decoration; they let assistive technology jump between regions, and they let a search engine understand what the page is actually about.
Instructor demonstration
The instructor builds a real page from an empty file: the document skeleton, then the same content marked up twice — once with divs and styling, once semantically — so the class can strip the CSS from both and see which one still makes sense.
- 01
Write the document skeleton
Type doctype, html, head and body from scratch. Explain what each part is for and why the head holds information that is never displayed.
- 02
Add the metadata
Set the charset, the title and the viewport. Explain that the title is what appears in a browser tab and in search results, so it is content rather than configuration.
- 03
Mark up a heading hierarchy
Write one h1 and nested h2 and h3 elements. Explain that headings are an outline and that levels are never skipped for size.
- 04
Fix a skipped level
Deliberately use an h1 for a subsection because it looks bigger, then correct it by styling an h3 instead. Explain that size is a CSS decision.
- 05
Write paragraphs and emphasis
Use p, strong and em. Show br between prose lines and explain why that is a mistake — a line break is not a paragraph.
- 06
Write links that describe themselves
Compare 'read our pricing' with 'click here'. Explain how a screen reader user scanning links out of context experiences the difference.
- 07
Add images with real alt text
Write descriptive alt text, then set alt empty on a decorative image. Explain that both are correct and 'image' is neither.
- 08
Set image dimensions
Add width and height and reload on a throttled connection. Show the layout jumping without them and explain why this matters on slow connections.
- 09
Choose the right list type
Mark a menu as ul and a procedure as ol. Explain that using ul for ordered steps loses the information that order matters.
- 10
Build a real table
Use th for headers and add a caption. Explain that tables are for tabular data and never for layout.
- 11
Add the sectioning elements
Wrap the page in header, nav, main, section, article, aside and footer. Explain that these let assistive technology jump between regions.
- 12
Mark the same content with divs
Rebuild an identical-looking page using only div and span with CSS. Explain that it appears the same and is broken for anyone not using a mouse and eyes.
- 13
Strip the CSS from both
Disable the stylesheet on each version and read them. Show that the semantic page still reads as an outline while the div version collapses into a wall of text.
Guided practice
Build a semantic multi-section page
You build a complete, valid page for a real business or organisation using only semantic elements: a correct document skeleton, a logical heading outline with no skipped levels, self-describing links, images with meaningful alt text, correctly typed lists, a real data table, and full sectioning structure — verified by stripping the CSS and reading the result.
- 01Write the document skeleton from scratch: doctype, html, head, body.
- 02Set the charset, a descriptive title, and the viewport meta tag.
- 03Write one h1 stating the subject of the page.
- 04Add h2 headings for each main section, nested logically.
- 05Add h3 headings for subsections, never skipping a level for size.
- 06Write the content in p elements, using strong and em for meaning.
- 07Write every link so its text describes the destination.
- 08Add images with alt text describing what each conveys.
- 09Use empty alt on any purely decorative image.
- 10Set width and height on every image.
- 11Use relative paths for all your own files.
- 12Mark unordered content as ul and any ordered procedure as ol.
- 13Build one genuine data table with th headers and a caption.
- 14Wrap the page in header, nav, main, sections, and footer.
- 15Use exactly one main element.
- 16Strip the CSS and read the markup as an outline to confirm it still makes sense.
The standard we hold you to
A valid page with a correct document skeleton and descriptive title, one h1 and a heading outline with no skipped levels, prose in p with strong and em used for meaning, every link's text describing its destination, images with meaningful alt text and empty alt where decorative plus explicit dimensions and relative paths, ul and ol chosen by whether order matters, one real data table with th headers and a caption, and full sectioning structure with exactly one main — verified by disabling the stylesheet and confirming the markup still reads as a sensible outline.
Common mistakes and how to fix them
You use div and span for everything
Fix: Use elements for their meaning. A page built from divs looks identical and is broken for anyone using assistive technology, a keyboard, or a search engine, because the meaning was only ever in the styling.
You pick headings by size
Fix: Pick by outline position and change the CSS for size. There is one h1 per page, and skipping levels because a size looks better destroys the outline that screen readers and search engines navigate by.
You use br between lines of prose
Fix: Use p for a paragraph. A line break is not a paragraph, and a wall of br-separated lines has no structure that anything can navigate.
Your links say 'click here'
Fix: Describe the destination in the link text. A screen reader user scanning links out of context gets nothing from 'click here', which is how many people navigate.
Your alt text says 'image' or repeats the filename
Fix: Describe what the image conveys, or use empty alt if it is purely decorative. Alt text replaces the image when it cannot be seen, so 'photo1.jpg' is useless.
You omitted width and height on images
Fix: Set both so the browser reserves the space. Without them the layout jumps as images load, which is a real usability problem on the slow connections most people here have.
You used a table for layout
Fix: Use CSS for layout. A layout table cannot be read in a sensible order by assistive technology and collapses badly on a phone.
You used ul for a numbered procedure
Fix: Use ol when order matters. The element carries the information that the sequence is significant, and a ul silently discards it.
Expert notes
The habits that separate someone who can do this from someone who does it well.
- Test your markup by disabling the stylesheet and reading it. If the page still reads as a sensible outline, the meaning is in the markup; if it collapses into a wall of text, the meaning was only ever in the styling and will fail for assistive technology.
- Choose heading levels by outline position and use CSS for size. This one habit eliminates most heading misuse, and the outline is what screen reader users navigate by and what search engines use to understand the page.
- Write link text that describes the destination and alt text that describes the image. Both are read out of context by assistive technology, and 'click here' and 'image' convey nothing in either case.
- Set width and height on every image. It reserves space before the image loads and prevents the layout jumping, which is a genuine usability problem on the slow connections most Nigerian users have.
Key terms
- Element
- An opening tag, content and closing tag. The unit HTML is built from.
- Semantic HTML
- Using elements for what they mean rather than how they look. The difference between a page that works and one that works for everyone.
- Nesting
- Elements inside elements, correctly closed. Gives a document its shape.
- Heading outline
- The hierarchy of h1 to h6. Navigated by screen readers and used by search engines.
- alt attribute
- Text replacing an image when it cannot be seen. Empty for decorative images, descriptive for meaningful ones.
- Sectioning element
- header, nav, main, section, article, aside, footer. Lets assistive technology jump between regions.
- Relative path
- A file location relative to the current page. Survives moving to another folder or server.
- Layout shift
- Content moving as images load. Prevented by setting width and height.
Homework before the next session
Write a document skeleton from memory
Doctype, html, head with charset, title and viewport, and body. Do it without looking anything up, then check. This is the frame everything else goes in.
Convert a div page to semantic HTML
Take any page you have built with divs and replace each one with the element that matches its meaning. Note how many divs you actually needed.
Audit your headings and alt text
Check for one h1, no skipped levels, and alt text that describes rather than names. Then strip the CSS and read the page as an outline.
Build one real data table
With th headers and a caption, containing data that genuinely relates in rows and columns. Do not use a table for layout anywhere in the page.
Assessment rubric
How this session is marked. The certificate for Web Development is awarded on the deliverable, not on attendance.
| Criterion | Passing | Excellent |
|---|---|---|
| Document structure | Renders a page. | A correct skeleton written from scratch with charset, descriptive title and viewport, and elements nested and closed correctly throughout. |
| Semantics | Uses some semantic tags. | Elements chosen for meaning throughout, verified by disabling the stylesheet and confirming the markup still reads as a sensible outline. |
| Headings and text | Has headings. | One h1, a logical outline with no skipped levels, size controlled by CSS, and prose in p with strong and em used for meaning rather than appearance. |
| Links and images | Has both. | Every link text describing its destination, alt text meaningful or deliberately empty, explicit width and height, and relative paths throughout. |
| Lists, tables and sections | Uses them. | ul and ol chosen by whether order matters, a real data table with th headers and a caption, and full sectioning structure with exactly one main. |
Session questions
Does semantic HTML really matter if the page looks the same?+
It looks the same only to a sighted person using a mouse with CSS enabled. A screen reader navigating by headings finds nothing in a page of divs, a keyboard user cannot reach a div styled as a button, and a search engine cannot tell your navigation from your content. The page appears finished and is broken for everyone else.
How many h1 elements should a page have?+
One, stating the subject of the page. Everything below it nests logically — h2 for main sections, h3 for subsections. If a heading is the wrong size, change the CSS rather than the element.
What do I put in alt text?+
What the image conveys: 'two students reviewing a spreadsheet in class', not 'image' or the filename. For a purely decorative image that adds no information, use an empty alt so assistive technology skips it rather than announcing something meaningless.
When should I use a table?+
Only for data that genuinely belongs in rows and columns. Never for layout — a layout table cannot be read in a sensible order by assistive technology and collapses badly on a phone. Use CSS for layout instead.
My page looks right but the validator reports errors. Does it matter?+
Usually yes. The browser guesses at malformed markup and usually guesses wrong, which produces inconsistent behaviour between browsers and breaks assistive technology. Fix the errors — it is nearly always a mismatched or unclosed tag and takes seconds.
This session is part of
Web Development
6 weeks · 12 sessions · ₦60,000 · you leave with a working, published web project