DEV Community

Cover image for 5 Semantic HTML Tags You're Probably Replacing With a Div (and Why Screen Readers Care)

5 Semantic HTML Tags You're Probably Replacing With a Div (and Why Screen Readers Care)

Semantic HTML tags describe what a piece of content is, not how it looks. Swap <div class="navigation"> for <nav> and nothing changes on screen, but a screen reader user can now jump straight to your menu with one keystroke.

Five semantic HTML tags do most of that work: <main>, <nav>, <article>, <section> and <aside>. Below is what each one means, a before/after for each, and the mistakes that show up most often in beginner code reviews.

Quick reference

Tag What it means How screen readers see it Typical use
<main> The page's primary content Main landmark Everything unique to this page (once per page)
<nav> A major block of navigation links Navigation landmark Site menu, breadcrumbs, table of contents
<article> A self-contained piece of content Article (not a landmark) Blog post, product card, comment
<section> A themed group with a heading Region landmark, only when it has an accessible name Parts of a long page
<aside> Related but non-essential content Complementary landmark (when top-level) Sidebar, related links, callouts

1. <main>: where the real page starts

Every page repeats the same header, logo and menu. Sighted users skip past them without thinking. Screen reader users can't, unless the HTML tells the browser where the actual content begins.

<!-- Before -->
<div class="main-content">
  <h1>Welcome to Our Website</h1>
  <p>Learn more about our services.</p>
</div>

<!-- After -->
<main>
  <h1>Welcome to Our Website</h1>
  <p>Learn more about our services.</p>
</main>
Enter fullscreen mode Exit fullscreen mode

With <main> in place, NVDA, JAWS and VoiceOver list it as a landmark users can jump to directly. It's also the natural target for a "Skip to content" link.

Rule of thumb: one visible <main> per page, and never nested inside <header>, <nav>, <article>, <aside> or <footer>.

2. <nav>: a menu that announces itself

A row of links inside a <div> works fine visually. To a screen reader it's just a few links, with nothing to say "this is the site menu".

<!-- Before -->
<div class="navigation">
  <a href="/">Home</a>
  <a href="/about">About</a>
  <a href="/contact">Contact</a>
</div>

<!-- After -->
<nav aria-label="Main">
  <ul>
    <li><a href="/">Home</a></li>
    <li><a href="/about">About</a></li>
    <li><a href="/contact">Contact</a></li>
  </ul>
</nav>
Enter fullscreen mode Exit fullscreen mode

Two small details in the "after" version are worth copying:

  • The label is "Main", not "Main navigation". Screen readers already announce the role, so aria-label="Main navigation" gets read out as "Main navigation navigation".
  • The links sit in a list. Users hear "list, 3 items" before they start, so they know how long the menu is.

The label matters most when a page has more than one <nav> (header menu, footer links, breadcrumbs). Give each a different label so users can tell them apart.

Common mistake: wrapping every group of links in <nav>. A row of social icons or a single "Read more" link doesn't need it. Keep it for major navigation blocks.

3. <article>: content that stands on its own

A useful test: if you lifted this block out and dropped it into an RSS feed or another page, would it still make sense? If yes, it's probably an <article>. That covers blog posts, news stories, forum posts, product cards and individual comments.

<!-- Before -->
<div class="blog-post">
  <h2>Understanding JavaScript</h2>
  <p>JavaScript is a popular programming language...</p>
</div>

<!-- After -->
<article>
  <h2>Understanding JavaScript</h2>
  <p>JavaScript is a popular programming language...</p>
</article>
Enter fullscreen mode Exit fullscreen mode

<article> is not a landmark, so it won't appear in a screen reader's landmark list. Its value is structure: each post gets a clear boundary, and the heading inside it becomes the starting point. On a blog listing page with ten posts, that makes skimming much easier.

Articles can also nest. Comments on a blog post can each be an <article> inside the post's own <article>.

4. <section>: a themed chunk with a heading

<section> groups content around one topic. A course page, for example, might have sections for Overview, Curriculum, Eligibility and FAQs.

<!-- Before -->
<div class="course-details">
  <h2>Course Details</h2>
  <p>Learn the fundamentals of web development.</p>
</div>

<!-- After -->
<section aria-labelledby="course-details-heading">
  <h2 id="course-details-heading">Course Details</h2>
  <p>Learn the fundamentals of web development.</p>
</section>
Enter fullscreen mode Exit fullscreen mode

Here's the part most tutorials skip: a <section> without an accessible name is treated much like a <div> by assistive technology. Connect it to its heading with aria-labelledby and it becomes a named region landmark users can navigate to.

Don't do this for every section, though. Too many landmarks make the list noisy. Name the sections someone would actually want to jump to, and if you only need a wrapper for styling or a grid, use a <div>. That's what it's for.

5. <aside>: related, but not the main point

Related posts, author bios, ads, glossary callouts: content connected to the page that could be removed without breaking it.

<!-- Before -->
<div class="sidebar">
  <h2>Related Articles</h2>
  <ul>
    <li><a href="/html-basics">HTML Basics</a></li>
    <li><a href="/css-fundamentals">CSS Fundamentals</a></li>
    <li><a href="/javascript-guide">JavaScript Guide</a></li>
  </ul>
</div>

<!-- After -->
<aside aria-labelledby="related-heading">
  <h2 id="related-heading">Related Articles</h2>
  <ul>
    <li><a href="/html-basics">HTML Basics</a></li>
    <li><a href="/css-fundamentals">CSS Fundamentals</a></li>
    <li><a href="/javascript-guide">JavaScript Guide</a></li>
  </ul>
</aside>
Enter fullscreen mode Exit fullscreen mode

A top-level <aside> is exposed as a complementary landmark. The choice is about meaning, not position: a left-hand column holding your site menu is a <nav>, not an <aside>, while a pull quote in the middle of an article can be one.

Why screen readers care

A screen reader doesn't see your layout. It reads the accessibility tree the browser builds from your HTML, and semantic tags fill that tree with roles: main, navigation, article, region, complementary. Users rely on those roles to skim a page the way sighted users scan it, jumping between landmarks and headings instead of listening to everything from the top.

Build the same page entirely from <div>s and you'd have to add role="main", role="navigation" and the rest by hand. The W3C's first rule of ARIA use is to reach for a native HTML element whenever one exists.

One honest caveat: semantic tags don't make a site accessible on their own. Heading order, descriptive link text, form labels, alt text, keyboard support and color contrast still matter just as much.

How to check your own page

  • Chrome DevTools: Elements panel → Accessibility pane. Turn on the full-page accessibility tree to see every role the browser exposes.
  • NVDA (Windows, free): press D to cycle through landmarks.
  • VoiceOver (Mac): open the rotor with VO + U and choose Landmarks.

Five minutes with any of these will show you exactly what a screen reader user hears.

Semantic HTML checklist

  • One <main> per page, wrapping the content unique to that page
  • Major link groups in <nav>, each with its own label if there's more than one
  • Self-contained content (posts, cards, comments) in <article>
  • <section> only for themed groups with a heading, named with aria-labelledby when users need to jump to it
  • Tangential content in <aside>, chosen for meaning rather than position
  • Headings in order (h1 → h2 → h3, no skipped levels)
  • Native elements before ARIA roles
  • <div> kept for layout and styling wrappers

None of these tags change how your page looks. They change how it's understood: by screen readers, by search engines, and by the next developer who opens your code.

Which of these five do you forget most often? And if you've ever tested your own site with a screen reader, what surprised you? Tell us in the comments.


Written by the web development team at Solitaire Infosystems, an IT training and software development company in Mohali, Punjab. HTML, accessibility and front-end fundamentals are part of our web development training.

Top comments (0)