Section, Article, Div: Who Needs Which?

Two separate pieces landed on the same day arguing one side or the other of the <section> question. Bruce Lawson made the case for <article> over <section> on Smashing Magazine, while Adam Laki compared <section and <div> on Pine. Different pairings, same core element — and the guidance for when it actually helps is thinner than the marketing around it.

Three Distinct Tools

<div> is straightforward. Use it when the element is meaningless — a styling hook, not a semantic container. No document structure, no assistive-tech value.

<article> has a practical test: think of RSS. Would this piece of content work on its own as an entry in a feed? If yes, <article> fits, even if the entry doesn't represent the entire page's content. Lawson frames it as "an article of clothing — a discrete entity that can be reused in another context." Your trousers are an article, re-wearable with a different outfit; your shirt is an article for other trousers; your knee-length patent leather stiletto boots are an article.

There is also concrete behavioral value here: Apple's WatchOS looks for <article> content specifically when pulling content from pages.

<section> was originally pitched as a container where the <h1> through <h6> heading hierarchy would reset. That depended on "HTML5 outlining" — a feature no browser ever shipped. The element became an answer in search of a question.

When a Naked Section Does Nothing

One legitimate use: Smashing Magazine's article summaries. Visually, a summary calling out at the top of an article reads clearly, but not to screen reader users. The fix involves an aria-label. But convention forbids aria-label on elements without a role. You could bolt a role onto a <div>, but <section> ships with a decent default role already:

<section aria-label="quick summary">
  Summary text
</section>

<section> thus auto-provides role="region". That sounds promising, but testing reveals its limits. With Chrome on desktop plus VoiceOver enabled, a <section> missing an aria-label didn't even register in the Landmarks section of the Web Rotor. Add the label and it showed up. So the region role on its own doesn't surface for landmark navigation.

The implication is to not reach for <section> as an automatic accessibility win. Its purpose is narrow: establishing landmarks. Even properly labeled, a landmark may not be the navigation aid you imagine. In the comments on Lawson's article, Leonie Watson pointed to WebAIM's screen reader survey: 68 percent of users navigate primarily by headings, versus just 2.9 percent who prefer landmarks. A visually hidden heading gives users the navigation method they actually use; a labeled <section> gives them a landmark they typically skip.

The Practical Trade

So the decision trees collapse quickly:

  • Need a semantically neutral styling hook? <div>.
  • Content that could standalone as an entry in some other context? <article>.
  • A chunk that genuinely needs to be a landmark for assistive tech, and you've added an accessible name? <section> is defensible.

The third case deserves extra scrutiny. If you're labeling a <section>, the heading-based alternative may serve your users far better. Landmark navigation is technically possible, but the overwhelming majority of screen reader users aren't choosing it. Drop the heading at the cost of usability for the majority who navigate headings; keep the heading and lose the landmark designation for the minority who prefer it.