A Page That Looks Right but Says Nothing
Picture two versions of the same webpage. Both show a photo, a heading "AICI Annual Day 2026", a paragraph of details, a menu bar, and a footer with contact information. Rendered in a browser, the two pages look pixel-for-pixel identical. But Version A is built entirely out of <div> tags with CSS class names like class="top-bar" and class="content-box". Version B uses <header>, <nav>, <main>, <article>, <footer>.
To a sighted visitor scrolling through it, there is no difference at all. But hand the page to two very different "readers," and the gap becomes obvious. A blind student using a screen reader — NVDA, JAWS, or VoiceOver — can jump straight to "main content" or "navigation" in Version B with a single keystroke. In Version A, every block is just an anonymous "group"; the screen reader has no idea which div is the menu and which is the story, so the student has to listen through the entire page to find anything. Ask a search engine to show a rich result with a date and a venue instead of a plain blue link, and Version A gives its crawler nothing usable, while Version B — extended with one small addition we will build later in this chapter — can.
This chapter is about two related but genuinely different ideas hiding inside the word "meaning." The first is semantic HTML5, which makes the structure of one page meaningful to browsers, screen readers, and search engines. The second is the Semantic Web — a specific, older, much bigger idea proposed by Tim Berners-Lee, the inventor of the web — about giving data meaning that machines can share across independent websites, not just read inside one document. Many resources blur these two together, and that blur creates a real misconception: thinking that adding <article> tags to your page has already put you "on the Semantic Web." It hasn't. This chapter builds both ideas properly, and keeps them clearly apart — exactly the distinction a good exam answer needs to make.
HTML5, Briefly: Why the "5" Matters
HTML (HyperText Markup Language) is not a programming language — it has no loops, no variables, no conditionals. It is a markup language: you wrap content in tags that describe what the content is, and the browser decides how to display it. HTML5 is the version of this language that the W3C (World Wide Web Consortium, the body that sets web standards) finalized as an official Recommendation in October 2014, after the web had run for years on HTML4 (1997) and an interim standard, XHTML, that never fully replaced it.
HTML5's most important change for this chapter was not visual — it added a set of elements specifically designed to describe the role a block of content plays, replacing the old habit of writing everything as <div id="header"> or <div class="nav">. Why did this matter enough to justify a new standard? Because a <div> only ever tells a browser "here is a rectangular box." The string id="header" is just a label a human programmer typed — nothing in the browser's rulebook says that string is special. A screen reader cannot ask "where is the header?" because the markup never actually declared one. HTML5's semantic elements fix this by giving the tag itself a standard meaning that every compliant browser, screen reader, and search-engine crawler already understands, at zero extra effort from you.
The Core Semantic Elements, Worked Through One Page
Let's build something real: the announcement page for a CBSE school's Annual Day, the kind of page you might genuinely be asked to build for a school website.
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<title>AICI Annual Day 2026</title>
</head>
<body>
<header>
<h1>AI Computer Institute</h1>
<nav>
<ul>
<li><a href="#events">Events</a></li>
<li><a href="#contact">Contact</a></li>
</ul>
</nav>
</header>
<main>
<article id="events">
<h2>Annual Day 2026</h2>
<p>Join us on <strong>20 August 2026</strong> at the school auditorium.</p>
<p>The welcome address will open with <i lang="ta">vanakkam</i>, before continuing in English and Hindi.</p>
</article>
<aside>
<h3>Related</h3>
<p>Read last year's <a href="#">Annual Day 2025 report</a>.</p>
</aside>
</main>
<footer id="contact">
<p>© 2026 AI Computer Institute, Chennai, Tamil Nadu.</p>
</footer>
</body>
</html>Walk through what each element is actually claiming, not just what it is called:
- <header> — introductory content for whatever it sits inside (the whole page here). It does not have to be "a banner with a logo" — semantically it means "introductory or navigational material for what follows," which is why a
<header>can also appear inside a single<article>to hold that article's byline and date. - <nav> — a block of major navigation links. Not every group of links deserves this tag: a cluster of three small footer links (Privacy Policy, Terms, Contact) is usually left as plain links, because marking every link list as navigation would flood a screen-reader user's landmark list with stops that aren't really navigation menus.
- <main> — the one dominant content of the page. There should be exactly one visible
<main>per page. - <article> — content that is self-contained and independently distributable: it would still make complete sense if you cut it out and pasted it into an RSS feed or a different site. A news story, a blog post, a single forum comment — all
<article>. A random supporting paragraph is not. - <aside> — content related to, but separable from, the surrounding content: a "Related" box, a pull quote, an advertisement.
- <section> — a thematic grouping, usually with its own heading, more like a chapter inside a book than the whole book. Unlike
<article>, a<section>does not need to make sense pulled out of context. - <footer> — closing content for the page or for the sectioning element it sits inside: copyright, contact details, related links.
How the Browser Actually Builds This: The DOM as a Stack
When a browser reads HTML, it does not treat it as flat text — it builds a tree of nested objects called the DOM (Document Object Model), and it does this using a simplified rule you already know from computer science: a stack, where the most recently opened tag is the first one that must be closed. Trace this short, well-formed fragment token by token:
<section>
<h2>Notice</h2>
<p>PTM on Friday.</p>
</section>1. Token <section> -> push "section" stack: [section]
2. Token <h2> -> push "h2" stack: [section, h2]
3. Text "Notice" attached as a child of h2 (top of stack)
4. Token </h2> -> pop "h2" stack: [section]
5. Token <p> -> push "p" stack: [section, p]
6. Text "PTM on Friday." attached as a child of p (top of stack)
7. Token </p> -> pop "p" stack: [section]
8. Token </section> -> pop "section" stack: [] (empty — fragment complete)Every opening tag pushes onto the stack and becomes the parent of whatever comes next; every closing tag pops the stack. If your tags don't nest correctly — say you write <p><strong>text</p></strong> — the closing </p> arrives while strong is still on top of the stack, and the browser has to silently guess how to repair it. This is exactly why well-formed nesting matters: it's not a style preference, it's what keeps the DOM tree the browser builds predictable and matching what you intended.
Meaning for Machines That Read Aloud: The Accessibility Tree
Every semantic HTML5 element carries an implicit ARIA role (ARIA = Accessible Rich Internet Applications, a W3C standard for describing UI to assistive technology). A subset of these roles are called landmark roles — regions a screen-reader user can jump between directly. In NVDA, pressing the "D" key moves the cursor to the next landmark on the page, letting a blind user skip straight to the content they want instead of listening through the whole page linearly.
Notice the qualifier under the diagram: <header> only maps to the banner landmark, and <footer> only maps to contentinfo, when they sit at the top level of the page — direct children of <body>, not nested inside an <article>, <aside>, <main>, <nav>, or <section>. A <header> written inside a single <article> (say, to hold that article's byline) is not a page-wide banner, so it correctly does not get that role. And notice that <article> gets its own ARIA role, "article," but that role is not one of the classic landmark roles (banner, navigation, main, complementary, contentinfo) — it exists so a screen reader can offer "jump to next article," which is a different, more specific kind of navigation.
Bold Is Not Important, Italic Is Not Emphasis
HTML5 kept four visually similar tags but gave them precisely different meanings — a favourite short-answer question in CBSE papers, and one most students get wrong.
<p>Do <strong>not</strong> submit the form twice.</p>
<p>The password must contain a <b>special character</b>.</p>
<p>The peacock's scientific name is <i>Pavo cristatus</i>.</p>
<p>I <em>did</em> submit the assignment on time.</p>- <strong> marks real semantic importance. A screen reader typically changes its tone or emphasis when reading it aloud — "not" is genuinely more critical to the sentence's meaning.
- <b> is purely a visual, stylistic offset — bold text with no added importance. It's the right choice for something like a keyword being defined, where you want visual attention but you are not claiming the word is more important than the rest of the sentence.
- <em> marks stress emphasis — it can change how a sentence is meant to be read, even change its meaning ("I did submit it" pushes back against an accusation that you didn't).
- <i> marks text in an "alternate voice" with no added emphasis: technical terms, taxonomic names like Pavo cristatus (the Indian peafowl, India's national bird), or a foreign-language word — exactly the case for
vanakkamin our Annual Day page above.
The pattern to remember: strong/em are semantic (they change what assistive technology communicates), while b/i are purely visual (they change only how the text looks). Both pairs render as bold and italic by default in a browser — which is exactly why it's tempting, and wrong, to treat them as interchangeable.
Beyond One Page: What "the Semantic Web" Actually Means
Everything so far — <article>, ARIA landmarks, the "D" key — solves a real problem, but a strictly local one: making the structure of this one page legible to a machine reading this one page. In 2001, Tim Berners-Lee (who invented the web itself at CERN in 1989), together with James Hendler and Ora Lassila, published an article in Scientific American proposing something bigger, which they called the Semantic Web: an extension of the web in which information is given well-defined meaning, so that computers — not just people — can process and combine it, and crucially, combine data from independent websites that have never coordinated with each other.
Here is the precise gap semantic HTML leaves open. Our <article> tag tells a screen reader "this block is the main, self-contained content." It does not tell any machine that the event inside starts on 20 August 2026, or that it is an educational event rather than a concert or a cricket match. A human reading the English sentence "Join us on 20 August 2026" understands that instantly; a machine parsing only the HTML tags does not — <p> just means "paragraph," not "this paragraph contains a date." The Semantic Web's job is to state that fact in a form a machine can extract directly, without understanding English grammar at all.
Triples: The Grammar of Machine-Readable Facts
The Semantic Web's basic building block is a W3C standard called RDF (Resource Description Framework, first standardized in 1999 and refined since). RDF states every single fact as a triple: Subject – Predicate – Object, echoing the subject-verb-object shape of a simple sentence.
- AICI Annual Day 2026 — has start date — 2026-08-20
- AICI Annual Day 2026 — has location — School Auditorium, Chennai
- AICI Annual Day 2026 — is a — Education Event
Unlike an English sentence, a genuine RDF triple identifies the predicate — the middle term, like "has start date" — with a globally unique web address (a URI), not just a plain word. Why bother? Because the plain word "location" is genuinely ambiguous: it could mean a physical place, a line number in a program, or a legal jurisdiction, depending on who wrote it and what they meant. A URI removes the ambiguity by pointing to one specific, publicly agreed definition that anyone on the web can look up. That agreed dictionary of predicates — with stable meanings anyone can reuse — is called a vocabulary (or, when it also encodes relationships between categories, an ontology). This is the part of the Semantic Web that a page full of <article> and <section> tags simply does not provide: those tags describe roles within your own document, not a shared, cross-site dictionary of what "start date" or "location" mean.
schema.org and JSON-LD: The Semantic Web You Can Actually Write Today
Raw RDF, written directly, is verbose enough that few page authors touch it by hand. What most of the real, modern web actually uses is schema.org — a shared vocabulary of types and properties launched jointly in June 2011 by Google, Microsoft's Bing, and Yahoo! (Yandex joined soon after), specifically so that independent search engines would agree on one common set of terms instead of each one inventing its own. And the format most sites use to write it is JSON-LD (JSON for Linking Data): a block of plain JSON, dropped into a single <script> tag, that never touches your visible page at all.
Take our Annual Day page and add exactly this, just before the closing </body> tag:
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "EducationEvent",
"name": "AICI Annual Day 2026",
"startDate": "2026-08-20T17:00:00+05:30",
"location": {
"@type": "Place",
"name": "School Auditorium",
"address": "Chennai, Tamil Nadu"
},
"organizer": {
"@type": "Organization",
"name": "AI Computer Institute"
}
}
</script>Read it the way a machine does: "@context": "https://schema.org" says "every term below comes from the schema.org vocabulary" — pinning down exactly what "startDate" and "location" mean, removing the ambiguity a plain English word would carry. "@type": "EducationEvent" states, in a form no English parsing is needed for, that this is specifically an educational event, not a concert or a match. "startDate" gives the date and time in a fixed, unambiguous format (ISO 8601, with +05:30 marking Indian Standard Time) rather than the free-text sentence "Join us on 20 August 2026." A search engine's crawler can read this block directly and build a rich result — a date and venue shown right in the search listing — without ever parsing the surrounding English paragraph.
Now the actual "web-wide" part: this JSON-LD works precisely because thousands of other, completely independent websites — a stadium's booking page, a travel-aggregator site, a ticketing platform — describe their own events using the exact same schema.org terms: startDate, location, EducationEvent. Because everyone draws from the same public vocabulary, a machine can pull structured facts from any of these unrelated sites and combine them — say, list every education event happening in Chennai this month — without needing to understand a single sentence of any site's actual prose, and without those sites ever having agreed with each other directly. That combination across independently owned, uncoordinated websites, made possible only because they share one public vocabulary, is what "the Semantic Web" specifically means.
Common Misconception, Corrected
"Using <article>, <nav>, and <header> makes my page part of the Semantic Web." This is false, and it is the single most common confusion this topic produces. Semantic HTML earns you a well-structured, accessible single page — genuinely valuable, but entirely local to that page's own DOM. It does not, on its own, let Google know your event's date, let a ticketing site auto-import your venue, or let any machine outside your own browser combine your data with anyone else's. Semantic HTML answers the question "what role does this block play on my page?" The Semantic Web answers a different question entirely: "what real-world fact does this data state, in a form any machine anywhere can extract and trust the meaning of?" You need a separate, additional layer — structured data such as JSON-LD written against a shared public vocabulary like schema.org — to actually answer that second question.
CBSE Exam Angle
Board papers in CS/Informatics Practices tend to test three things around this chapter. First, converting "div soup" into correct semantic HTML5 — know the precise definitions, especially the distinction between <article> (must make sense standing alone) and <section> (a thematic grouping that need not). Second, the exact <b>/<strong> and <i>/<em> distinction, almost always as a short-answer question. Third, at Class 11–12 IP/CS level, "current trends" questions increasingly ask you to define the Semantic Web conceptually and distinguish it from ordinary HTML — having this distinction correctly formed now, at Class 9, means you won't have to unlearn the common "semantic tags = Semantic Web" conflation later. It also helps to know the standardizing bodies and dates precisely: HTML5 became a W3C Recommendation in October 2014; RDF, the Semantic Web's data model, is also a W3C standard, first published in 1999.
Check Your Understanding
- A page wraps its main news story in
<div class="content">instead of<article>. A blind user opens it in NVDA and presses "D" to jump between landmarks. What happens, and why, compared to a page that used<main><article>correctly? - Given
<p>The report is <b>due Friday</b>. Please <em>do not</em> submit late.</p>, explain which phrase carries real semantic weight for a screen reader and which is purely visual styling, and why the tag choice matters even though both render as bold/italic-style emphasis visually. - Why must "start date of an event" be represented using a shared, public vocabulary term (like schema.org's
startDate) rather than each website inventing its own field name, for machine-readable meaning to actually work across independent sites? - True or False, with a one-line justification: "Adding
<header>,<nav>, and<footer>to my page means my event data can now be automatically combined with a ticketing website's data." - Trace, step by step using a stack, how a parser processes:
<section><h2>Notice</h2><p>PTM on Friday.</p></section> - In the JSON-LD block for the Annual Day event, what does
"@type": "EducationEvent"communicate to a machine that the plain sentence "Join us for Annual Day" does not?
Summary
- HTML5 (a W3C Recommendation since October 2014) added elements —
header,nav,main,article,section,aside,footer— that declare a block's role, not just its box, replacing generic<div>soup. - A browser builds the DOM by pushing each opening tag onto a stack and popping it on the matching closing tag; correct nesting is what keeps this process predictable.
- Each semantic element maps to a specific ARIA landmark role (banner, navigation, main, complementary, contentinfo) that lets screen-reader users jump directly between page regions; banner/contentinfo apply only when header/footer sit at the top level, and
articlegets its own role but is not itself a landmark. <strong>/<em>carry real semantic importance/emphasis that assistive technology announces differently;<b>/<i>are purely visual or idiomatic, with no added semantic weight.- All of the above is meaning within one page. The Semantic Web, proposed by Tim Berners-Lee in 2001, is a different, larger idea: representing real-world facts as RDF triples (subject–predicate–object) using shared, public vocabularies — like schema.org — so that independent, uncoordinated websites can exchange machine-readable meaning, not just human-readable prose.
- JSON-LD is the practical, modern way to add this layer: a
<script type="application/ld+json">block that states facts using schema.org terms, letting search engines — and in principle any machine — extract structured data like an event's date and venue without parsing a single English sentence. - Semantic HTML and the Semantic Web solve related but genuinely different problems. Keep them separate in your own explanations: one is page structure for humans and assistive technology; the other is page-independent, machine-shareable fact representation at web scale.
Think About It
Think about this: How would you explain html5 and the semantic web: building meaningful pages to a friend who has never seen a computer? What real-world analogy would you use? Imagine you had to build a system using these concepts — what would be your first step? Try this: before moving on, write down three things you learned and one question you still have.