02 — HTML — Describing Meaning, Not Painting Pixels

"The tags that make text bold or draw a box" was how I treated HTML, which explained nothing about why the tags exist. The line that everything else hangs off: HTML describes meaning. How it looks is someone else's job. [1]

An <h1> doesn't mean "big bold text." It means "this is the top-level heading of the page." Big and bold is just what the browser's built-in stylesheet happens to do with that meaning. Swap the stylesheet (CSS) and the looks change completely; the meaning doesn't budge. I had the relationship backwards for years — I was picking tags for the appearance I wanted, when the only question I needed to answer was what is this content?

The payoff of getting that right is that three things I used to think were separate collapse into one. Semantic markup, accessibility, and SEO aren't three skills — they're one activity, "describe the meaning correctly," read by three different machines:

This post you're reading is, at the bottom of the stack from last time, just such a document — the server sends HTML, and the browser turns meaning into the page on your screen. So what's actually in it?

Elements, attributes, and the tree

HTML is made of elements — usually an opening tag, some content, and a closing tag, like <p>some text</p>. Elements carry attributes, key/value pairs on the opening tag that refine meaning or attach data: <a href="...">, <img src="..." alt="...">, <input type="email" required>. A handful of elements are void — <img>, <br>, <meta> — they have no content and no closing tag [2].

The thing I had to see clearly is that elements nest, and the nesting forms a tree. A <ul> contains <li>s; a <section> contains a heading and paragraphs. That parent/child structure is the source of the DOM the browser builds and everything (CSS, JavaScript, accessibility) reads from. Tags aren't a flat list of styling hints; they're a tree of meaning, where a tag's role depends on where it sits.

Semantic HTML — describing what things are

This is the part I had to straighten out most. For years I reached for <div> for every block and <span> for every inline bit, because it "worked." But <div> and <span> carry zero meaning — they're generic containers, the fallback for when nothing semantic fits [3]. Wrapping a navigation menu in <div class="nav"> tells a browser nothing; the word nav in the class name is for me, not for the machine.

The semantic elements describe roles instead [3][4]:

• <article> — a self-contained piece that would make sense on its own (a blog post, a product card).
• <section> — a thematic grouping, almost always with a heading of its own.
• <nav> — a set of navigation links.
• <header> / <footer> — introductory / closing material for a page or a section.
• <main> — the dominant content of the page, exactly once per page, with nothing repeated across the site.
• <aside> — tangentially related content (a sidebar, "related posts").
• <figure> / <figcaption> — an image or diagram with a caption tied to it.

The test I use now: before I write a <div>, I ask what is this block, in one word? If I can name it — it's a navigation, an article, the page's main content — there's almost always a tag that already says that. Only if there genuinely isn't do I fall back to <div>.

A page laid out this way has a recognizable skeleton, and once you've seen it you start spotting it everywhere:

Accessibility is semantics done well

This is where the model pays off first. A screen reader doesn't look at pixels — it reads the meaning the tags declare [5]. The heading elements <h1> through <h6> build an outline that a blind user navigates like a table of contents. The landmark elements — <main>, <nav>, <aside>, <header>, <footer> — let them jump straight to the part of the page they want, skipping chrome they've heard a hundred times. The alt attribute on <img> describes the image when it can't be seen; a <label> ties a caption to its form field so the field announces itself correctly.

The flip side matters as much: skipping heading levels for visual effect, or using <div onclick> instead of <button>, doesn't just look sloppy — it erases the meaning that someone's navigation literally depends on. A <button> is focusable, keyboard-operable, and announced as "button" to assistive tech; a clickable <div> is none of those unless you rebuild them by hand. Accessibility isn't a separate layer bolted on later. It's a question of whether the semantics actually made it onto the page.

SEO is the same trick again

A search crawler is just another reader of the same meaning [6]. <title> and <meta name="description"> are the first thing it sees. A single <h1> tells it what the page is fundamentally about; well-structured headings and <article> tags tell it how the content is organized. Writing good semantics for humans and writing good semantics for Google turn out to be the same activity — which is exactly what you'd expect if the tags are describing meaning rather than painting pixels.

Forms — where meaning gets interactive

Forms are the one corner of HTML where the meaning does something without JavaScript. <form> groups fields; <input> types like email, number, date, range, and color give the right on-screen control; <label>, required, pattern, and <select> wire up captions and validation [7]. Declaring type="email" on an input gets me the right mobile keyboard and built-in validation and an accessible control — one attribute, three wins. I reach for a native input before a JavaScript reimplementation almost every time. The browser already did the work; the trick is to tell it what I mean instead of reimplementing it.

How I use this

The habit these notes left me with is a single pause: when I reach for a <div>, I stop and ask what is this thing? Most of the time a semantic tag already exists for the answer, and I should use it — the looks get sorted out later in CSS, and accessibility and SEO come along for free. <div> and <span> are the last resort, not the default.

That pause is the whole reason HTML ever felt hard. I was using it for a job it isn't meant to do — controlling appearance — and finding it arbitrary. Used for what it actually is, a way to describe meaning, it's almost embarrassingly straightforward.

References

[1] Mozilla, "HTML basics," MDN Web Docs, 2024. [Online]. Available: https://developer.mozilla.org/en-US/docs/Learn/Getting_started_with_the_web/HTML_basics

[2] WHATWG, "HTML Living Standard," 2024. [Online]. Available: https://html.spec.whatwg.org/

[3] Mozilla, "HTML elements reference," MDN Web Docs, 2024. [Online]. Available: https://developer.mozilla.org/en-US/docs/Web/HTML/Element

[4] Google, "Use semantic HTML," web.dev, 2023. [Online]. Available: https://web.dev/articles/semantic-html

[5] Mozilla, "HTML: A good basis for accessibility," MDN Web Docs, 2024. [Online]. Available: https://developer.mozilla.org/en-US/docs/Learn/Accessibility/HTML

[6] Google, "Discover semantic HTML for better search results," web.dev, 2023. [Online]. Available: https://web.dev/articles/discover-semantic-html

[7] Mozilla, "Web forms — Working with user data," MDN Web Docs, 2024. [Online]. Available: https://developer.mozilla.org/en-US/docs/Learn/Forms