When the semantic element <section> met style

Previously on the CogitActive Saga:
Because sectioning elements wrap their contents, we know exactly where they begin—and more importantly—where they end. We know what content belongs to what. Or at least, assistive technologies and indexing parsers do. What about sighted readers?

Introduction

I recently published a deep dive on one of the most misunderstood semantic elements introduced in HTML5: the <section> element. A 29-minute read—for you. A several man-months marathon—for me. Hence, the well-deserved pause that followed its publication (yes, that previous post was real).

Why such a long drafting process? Because of the exhaustive research and persistent fog I had to navigate to untangle the confusion surrounding this elusive tag. Figuring out when and how to use <section> properly wasn’t just about reading the specs—it was a journey through contradictory tutorials, outdated examples, and a surprising lack of consensus.

The confusion stems primarily from the overwhelming number of articles attempting to explain how to use the <section> element— but not in the way I needed (see next paragraph); often by contrasting it with <div> or <article>—and, more fundamentally, from its dual identity: one semantic (i.e., when used as a landmark), one structural. While this distinction is technically documented, many developers overlook it or assume that <section> automatically behaves as a landmark (i.e., role="region"), which it doesn’t unless certain conditions are met 1. That assumption leads to misuse, ambiguity, and a lingering haze around its true purpose. The result? A persistent fog of misunderstanding that continues to cloud its proper application.

In my case, I wasn’t trying to create a landmark. I was after something more fundamental: a clean, semantic way to structure my content and provide meaningful IDs for deep linking. In fact, Google’s developer documentation style guide recommends wrapping a heading in a <section> element with an id attribute as the proper way to anchor it.

Recommended:
 <section id="introduction-to-everything">
  <h2>Introduction to everything</h2>
  ...
 </section>

But <section> isn’t just the recommended method—it excels at this task because it provides clear semantic boundaries, grouping related content and signaling its purpose. Thanks to this element, we can pinpoint the start and—crucially—the end of a content block. For assistive technologies and indexing parsers, this clarity is invaluable. They can interpret the document’s structure with confidence, knowing precisely what belongs to what. Structure is no longer a guessing game, as illustrated below (visual grouping of sections is simulated using red-dashed borders):

Heading Level 1

This paragraph belongs to heading level 1.

Heading Level 2

This paragraph belongs to heading level 2.

Heading Level 2

This paragraph belongs to heading level 2.

This paragraph belongs to heading level 1, not level 2!

Surely they, too, should benefit from this newfound clarity, right? Unfortunately, they rely solely on visual cues—headings, spacing, typography—to navigate a page, not on markup. In the example above, they don’t see the red-dashed boxes. Screen readers and search engines do—well, not the boxes per se (there are no such boxes, of course), but they do see the opening and, more importantly, the closing tags.

Now, strip away those red-dashed borders, and what’s left? A sighted reader will confidently assume that the paragraph following the third-level heading belongs to it. Fooled by proximity. So, how do I tackle this? Of course, I’m not going to slap red-dashed boxes around every section just to make things clearer. That might work in a contained illustration like the one above—though it’s visually aggressive—but it would be utterly impractical for long-form posts like mine.

As you can imagine, I did toy with the idea of using indentation to reflect hierarchy. Remember, I spent man-months working on this element—and nearly as much time trying to find a solution for sighted readers. But I quickly ran into two major caveats. First, with five theoretical levels of headings (from <h2> to <h6>), indentation can spiral out of control. Valuable screen space on the left vanishes, and paragraphs become awkwardly narrow—especially on smartphones, where every pixel counts. Second, even if the top of the post might resemble a neat staircase of nested content, the bottom remains a guessing game. If I’m at level <h6> and suddenly insert a paragraph that belongs to <h4>, how is the reader supposed to know it belongs to <h4> and not <h3> or <h5>? They don’t have a ruler—or as we say in French, le compas dans l’œil (“literally, a compass in the eye—meaning an innate sense of proportion”)—to measure indentation with precision.

So yes, I had to come up with something better. But what? That’s precisely what this post is about: finding a way to visually convey semantic structure to sighted readers—without compromising readability, layout, or sanity.

Background color as a visual cue

The first suggestion it offered was to use background color to visually group sections. The idea is simple: apply a soft tint behind each section so sighted readers can more easily perceive where one block ends and another begins. It’s a common design technique, often used to reinforce structure without relying solely on headings.

I immediately dismissed the idea, pointing out the obvious risk of creating an “ugly patchwork”. Copilot countered with a workaround: use extremely faint colors to keep things subtle. But no matter how delicate the palette, it would still look like a patchwork.

Worse still, this strategy simply doesn’t replicate the clarity of the above HTML illustration. Imagine replacing the red-dashed boxes with shaded backgrounds—patchwork. Ugly. Now strip away the indentation, the margin, the padding… even the red-dashed boxes lose their effectiveness. Unless each paragraph is individually wrapped in its own background (which would be absurd, and would require a legend—H2 is blue, H3 is green, H4 is beige… really?), the grouping falls apart.

And here comes the final nail in the coffin: I already use background styling for certain elements like textboxes. Layering additional background colors would only create visual chaos.

Verdict: not an option.

Left borders as a visual cue

The next suggestion by Copilot was to use left borders to visually group sections. The idea is straightforward: draw a thin vertical line along the left edge of each block to signal its boundaries. It’s a familiar design convention, often seen in documentation and editorial layouts, and it promises a cleaner alternative to the background-color strategy.

The rationale was compelling. Unlike background shading, borders don’t interfere with existing background styles—like textboxes—and they’re less likely to create visual clutter if applied subtly. A single line can suggest structure without overwhelming the layout. In theory, this solves the patchwork problem.

Still ugly. A lot of lines on the left. And here’s where things get murky: how do you handle hierarchy? Do you stack multiple lines next to each other—the deeper you go, the more lines? Or do you show only the border of the current paragraph? If it’s the latter, do you provide a legend again? H2 is thick gray, H3 is thin blue, H4 is… oh please.

But worse still: my cherished “aside left” in Twenty Seventeen. When I tried to implement this approach, the borders didn’t respect the aside—they just kept going, slicing right through it like a rogue timeline. It looked like the text was being impaled. No way.

Not an option.

Typographic cues as a visual strategy

The next suggestion by Copilot was to use typographic cues to visually structure the post. The idea: vary font size, weight, or style to signal hierarchy. It’s a classic design move—elegant, lightweight, and widely used in both print and digital formats. Headings get larger, bolder, or more stylized as their importance increases, guiding the reader’s eye through the content. You can vary font size, weight, or style to reflect structure (e.g., bold for H2, italic for H3).

“Wait, what are you talking about? You’re talking about headings. My headings are already styled. That’s not helping at all.”

When I stopped him, he conceded: if the differences are too subtle—say, H3 is just 1pt smaller than H2—readers might miss the hierarchy entirely. Fair. But that wasn’t the real issue. Headings, even when styled well, don’t visually wrap or group content the way indentation or borders can. They signal importance, not containment.

Headings alone can only show where a piece of content starts, not where it ends, which makes it difficult to tell what belongs to what.Heydon Pickering

Once he recentered, he recycled the idea: apply typographic variation to the paragraphs themselves. That way, readers could visually distinguish H3 content from H4 content, and so on. But here’s the catch: I’d need to invent four new paragraph styles. Seriously. One for each heading level’s content. And do we really think readers will notice that a paragraph in font-size 1.1rem is “structurally distinct” from one in 1.2rem? Or that a sans-serif paragraph is somehow conceptually different from a serif one? Come on.

Worse still, if we go the style route—say, switching from Inter to Georgia or from system-ui to Garamond—it’s not just ineffective. It’s ugly. So ugly. And what about non-text content? Am I supposed to change the font of an embedded video? Or resize an image caption to suggest hierarchy? It’s absurd.

Again, not an option.

Small icons to signal structure

“What if each section of your blog had a tiny icon next to it? A folder for H2s, a paperclip for H3s, maybe a glittery star for bonus thoughts. These icons could visually cue readers into the hierarchy of your content—like a breadcrumb trail, but cuter. It’s a subtle way to add structure without relying solely on typography.”

“Are you kidding me?”

“Icons are fast to interpret and can add a layer of visual organization. They’re customizable, scalable, and—if done tastefully—can reinforce your blog’s aesthetic. Plus, they’re non-invasive: just a little glyph tucked beside each heading or paragraph. Think of it as UX meets editorial design.”

“I’m running a blog, not decorating my teen girl diary. What’s next—should I dig out my glitter gel pens and Lisa Frank sticker sheet?”

The idea isn’t just juvenile—it’s aggressively juvenile. Icons might work in a productivity app or a children’s book—but not in a blog that dissects technology through real-life experience and meticulous research. And let’s talk logistics: one icon next to every paragraph? Seriously. Again, a legend? A glossary of emojis? If you’ve followed this blog— particularly the story behind my reaction buttons—you already know how I feel about emojis. No. Absolutely not. I’m writing content that’s meant to be informative, not hosting a Slack thread or moderating a group chat.

Frustration, despair, and the void

I tried. I really did. I scoured design blogs, poked around forums, and even asked my readers for suggestions (in the previous post—yes, even during my so-called break, I still work). And what did I come up with? Nothing. Nada. Zilch.

Of course, I summoned Gemini. But alas, the oracle offered the same recycled ideas:

  • Background colorbut only on hover. A nice upgrade, sure, but not good enough.
  • Border or shadow—still not it.
  • Heading style tweaks—Seriously, I thought the “I” in AI stood for Intelligence!

I’ll spare you the rest of the Copilot’s suggestions, but just for the record:

  • “A vertical line or bracket on the left side to visually group content under a heading.” How is that not just a left border in disguise?
  • “A subtle marker inside the content block to avoid aside-left collision.” Oh, you mean smaller emojis? Groundbreaking.
  • “Left margin instead of a border.” I call that indentation, thank you very much.
  • “Add a tiny icon next to the heading.” And we’re back to emojis. Again. Not to mention targeting the heading. Intelligence, right!

When I published my 29-minute post, I was already starting to think: Maybe there’s no elegant solution. I would’ve loved to unveil a breakthrough in that post, but instead I had to settle for: “That’s a problem I’ve yet to tackle.” Still, I kept searching. I kept asking Copilot, refining my prompts, hoping that maybe—just maybe—the new ChatGPT 5.0 brain would be smarter. Would it finally understand the nuance? The aesthetic restraint? The refusal to slap on a gimmick?

Spoiler: it didn’t. But I didn’t give up. Not me. Not yet. So here I am—still searching, still refining. The solution remains out of reach, but the journey continues.

To be continued…2


1 The <section> element has an implicit ARIA role of region only if it has an accessible name provided via aria-label, aria-labelledby, or the title attribute. If no accessible name is present through these attributes, the role defaults to generic, which offers no landmark functionality. ^
2 Sorry about that—another multi-part post, I know! As explained in The <section> Element (see footnote #1), these often emerge organically, when I realize—mid-post—that the issue is more complex than expected. This time, the “To be continued…” ending wasn’t planned; it was forced by circumstance. Not because the search turned out to be more intricate (though it did), but because time ran out during drafting. You may have noticed that the final section was already a bit rushed—its quality not quite up to par. I had hoped to present a complete solution here, but couldn’t finish in time. Rather than sacrifice another night on the altar of CogitActive, I resorted to the “To be continued…” trick. On the bright side, this gives you more time to suggest a more elegant solution than the one I’ve kept in reserve (as invited in the previous post). ^