Two articles published the exact same day:
- Bruce Lawson on Smashing Magazine: Why You Should Choose HTML5
<article>
Over<section>
- Adam Laki on Pine: The Difference Between
<section>
and<div>
Element
They are comparing slightly different things, but they both involve the <section>
element.
I find it pretty clear when you reach for a <div>
: When you want that element to be essentially meaningless. You’re only using it for styling purposes.
I always think of RSS when I think of <article>
: Would this little bit of stuff make sense as an entry (which doesn’t necessarily need to be the entire content of the article)? If yes, use <article>
; if not, don’t.
Bruce has a go-to answer:
[…] think of
<article>
not just as a newspaper article, or a blog post, but as an article of clothing — a discrete entity that can be reused in another context. So your trousers are an article, and you can wear them with a different outfit; your shirt is an article, and can be worn with different trousers; your knee-length patent leather stiletto boots are an article.
More importantly, it has some actual functionality. Bruce mentions that Apple WatchOS specifically uses it to find content on pages.
But <section>
is more nebulous. At one point, you were supposed to think of sections as places where your <h1>
–<h6>
headings would reset, but that never came to fruition because it required a thing called “HTML5 Outlining” which zero browsers support.
So should we use <section>
it at all? According to Bruce, sometimes! Smashing Magazine’s design for articles has a summary at the beginning of the article. Visually, that’s fairly clear, but less-so for screen reader users. The solution was wrapping the summary in an element with an aria-label
to make that clear. But you aren’t supposed to use aria-label unless that element also has a role
. You could apply a role to a <div>
, but <section>
already has a good default role, so:
<section aria-label="quick summary">
Summary text
</section>
Adam’s article (sorry, Adam) is very vague on the points.
The main difference comes from the semantic. If you have a part in your site or application which has its logic you need to use the
<section>
tag to declare it…… use
<section>
when it is logically correct to make a part of your site or app readable to the assistive technology. It is an excellent approach if you keep in mind the screen readers.
So you get a role="region"
automatically for sections, but I’m not sure that does anything for screen readers, sans the label. In a quick test (Chrome for desktop with VoiceOver enabled), a <section>
without an aria-label
just wasn’t there in the Landmarks section of the Web Rotor, but it showed up once it had an aria-label
.
Point is: don’t just use <section>
and assume you’re doing something good for accessibility. Its purpose is pretty limited and only useful for establishing landmarks. Even then, you aren’t helping that much. Leonie Watson in the comments:
When the choice is between a visually hidden heading and a section element with an accessible name there are a couple of things to consider before deciding which approach is the right one.
When a section element has an accessible name it becomes a navigable landmark element, so a screen reader user can use their screen reader’s shortcut key for navigating from one to the next – just like they can do with headings.
According to the most recent WebAIM screen reader user survey though, 68% of screen reader users prefer to navigate by headings compared to 2.9% who prefer landmarks.
So from a strict accessibility point of view, you could probably drop the heading, but from a usability point of view you really want to keep the heading – at least until more screen reader users express a preference for using landmarks to navigate content.
This has opened my eyes a bit.
I’m working through some thoughts for creating breakout sections in articles and was defaulting to section to group together the content of the breakout area. I still feel like that’s right even with the context of this article, but… I’m no sure.
I want to group the content into one HTML element for both styling and for meaning, because the content would work as one entity, but is
<section>
the best HTML… I was 100% sure before… now, I’m like 75% sure…What does everyone think?
Squarespace just upgraded their platform to Squarespace 7.1 and their markup now includes
<section>
s within an<article>
on every page (example: look at the markup on my website will-myers.com).As more websites on the internet are built from code from companies like Squarespace, what responsibility do these companies have to follow the standard convention for markup rather than the standard convention for markup becoming what these companies dictate?
No problem, Chris! About your point: “don’t just use
<section>
and assume you’re doing something good for accessibility. Its purpose is pretty limited and only useful for establishing landmarks.” I agree; this summary is missing from my article. The<section>
is your last resort when you build with landmarks. First, you must place more meaningful elements like<header>
,<footer>
,<main>
,<aside>
,<nav>
,<article>
and try to fill the holes with sections if you can.I tried to show just the difference (or compare somehow) between the
<div>
and the<section>
, but without the broader context, it can be misleading. Because alone, the<section>
doesn’t add much.Thanks!
I’ve always used section elements to group related content – e.g a bunch of articles, or related/recommended products in an ecommerce site. And I’ve always added an HTML heading rather than aria-label.
NVDA on Windows then announces a landmark region with the heading text… so a user can easily identify what this particular landmark is.
I’m confused by Bruce’s article and the comments about whether my usage is correct or even helpful for screen reader users?
I’m doing the same thing with
<section>
. If it doesn’t have any heading right after the tag then I’m usingaria-label
oraria-labelledby
.This is better in my opinion than using
<div role="region" aria-label="....." ..... >
for sectioning content.Specification can be confusing, and talking about accessibility it is like 2x confusing.