HTML The nav Element

The nav element is a semantic HTML5 container used to mark up a section of a page that provides navigation links — such as a main menu, a table of contents, or pagination controls. Unlike a plain div, nav tells browsers, search engines, and assistive technology that the links inside it form a major navigation block, not just a random group of links. Using it correctly makes your site more accessible to screen reader users and easier for search engines to understand.

Overview / How it works

Before HTML5, developers wrapped navigation menus in generic elements like <div id="nav"> or <div class="navigation">. This worked visually, but it gave browsers and assistive technology no built-in way to know that the content inside was navigation. HTML5 introduced nav as one of several sectioning elements — alongside header, footer, main, article, and aside — specifically so that document structure could be expressed in the markup itself, not just implied by class names.

When the browser parses a <nav> tag, it creates a corresponding node in the DOM tree just like any other element — there is no special rendering behavior by default. A bare nav element has no default visual styling beyond being a block-level element (it stacks vertically and takes the full available width, similar to a div). All the visual styling you associate with navigation bars — horizontal menus, backgrounds, hover states — comes entirely from CSS, which is a separate concern from the semantic meaning nav provides. What makes nav different is not how it looks, but how it is exposed in the accessibility tree, a parallel structure the browser builds alongside the DOM specifically for assistive technology.

Every browser that supports HTML5 semantics exposes elements marked with <nav> with an implicit ARIA role of navigation. Screen readers use this role to let users jump directly between navigation landmarks with a single keystroke, skipping over the rest of the page. Search engine crawlers also use semantic landmarks like nav as a signal for understanding page structure, which can subtly help with how a page is indexed and understood, though it is not a ranking factor by itself.

Not every group of links needs to be a nav. The HTML specification says nav is intended for major navigation blocks — the kind of navigation a user would want to jump straight to. A handful of links buried in a footer’s copyright line, or a single inline link within a paragraph, does not need nav. A good rule of thumb: if you would put it in a menu, table of contents, or breadcrumb trail, it probably belongs in a nav.

Syntax

<nav>
  <ul>
    <li><a href="/">Home</a></li>
    <li><a href="/about">About</a></li>
  </ul>
</nav>

The general parts of a nav element:

Opening and closing tags: <nav> and </nav> — both are required; nav is not a void element.
Content model: nav is a flow-content container, meaning it can hold headings, lists, paragraphs, and links — most commonly an unordered list (<ul>) of links, but a plain sequence of <a> elements works too.
Global attributes: nav accepts standard global attributes like id, class, and title, just like any other element. It does not have any attributes unique to itself.
Implicit role: browsers automatically assign the ARIA role navigation to nav elements — you do not need to add role="navigation" manually.

Examples

Example 1: A simple site-wide navigation menu

<nav>
  <ul>
    <li><a href="/">Home</a></li>
    <li><a href="/products">Products</a></li>
    <li><a href="/contact">Contact</a></li>
  </ul>
</nav>

Result: The browser renders a vertical, bulleted list of three links — Home, Products, and Contact — stacked one per line, since no CSS has been applied yet. Visually it looks like a plain list, but in the accessibility tree it is exposed as a navigation landmark containing three links, letting screen reader users jump to it directly and identify it as the site’s main menu.

This is the most common pattern: a ul inside a nav. The list gives you individual list items to style as menu buttons later with CSS, while nav declares the whole group’s purpose.

Example 2: Multiple nav elements with distinct purposes

<header>
  <nav>
    <ul>
      <li><a href="/">Home</a></li>
      <li><a href="/blog">Blog</a></li>
    </ul>
  </nav>
</header>
<main>
  <article>
    <h2>Article Title</h2>
    <p>Article content goes here.</p>
  </article>
</main>
<nav aria-label="Pagination">
  <ul>
    <li><a href="/page/1">Previous</a></li>
    <li><a href="/page/3">Next</a></li>
  </ul>
</nav>

Result: The page renders a header menu at the top with Home and Blog links, an article body in the middle, and a Previous/Next pagination control at the bottom. Visually these are three separate blocks stacked vertically. In the accessibility tree, however, there are now two navigation landmarks. Because a page can legitimately have more than one nav, the second one is given an aria-label="Pagination" so that a screen reader announces it as “Pagination navigation” instead of a second, indistinguishable “navigation” landmark.

This demonstrates a key real-world pattern: it is completely valid to use multiple nav elements on one page — a main menu, a footer sitemap, a table of contents, and pagination controls can each be their own nav — as long as each one is labeled clearly when there is more than one.

Example 3: A breadcrumb trail using nav

<nav aria-label="Breadcrumb">
  <ol>
    <li><a href="/">Home</a></li>
    <li><a href="/shoes">Shoes</a></li>
    <li>Running Shoes</li>
  </ol>
</nav>

Result: The browser displays a numbered list rendered inline-like by default styling conventions (though by default ol renders as a vertical numbered list unless styled otherwise): “1. Home”, “2. Shoes”, “3. Running Shoes”, with the first two as clickable links and the last as plain text representing the current page. Semantically, this whole trail is exposed as a labeled navigation landmark named “Breadcrumb”.

Breadcrumbs are a good example of navigation that is not a main menu but still deserves a nav wrapper, because it is a block a user might want to jump to directly to understand or change their location within a site hierarchy.

How it works step by step

The HTML parser encounters the <nav> start tag and creates a new element node in the DOM tree as a child of its parent.
Any content inside — lists, links, headings — is parsed normally and attached as descendant nodes of the nav node.
The parser encounters </nav> and closes that branch of the tree.
During accessibility tree construction (which happens alongside DOM construction), the browser inspects the tag name and assigns the implicit ARIA role navigation to that node.
If an aria-label or aria-labelledby attribute is present, it is attached as the accessible name for that landmark; otherwise, assistive technology announces it generically as “navigation”.
By default, no CSS is applied by the browser’s user-agent stylesheet beyond treating nav as a block-level element — all visual menu styling must come from your own CSS.

Common Mistakes

Mistake 1: Wrapping every group of links in nav

<footer>
  <nav>
    <p>&copy; 2026 MyCompany. <a href="/privacy">Privacy Policy</a></p>
  </nav>
</footer>

This is technically valid markup, but it misuses nav‘s intent. A single incidental link inside a copyright line is not a major navigation block, and wrapping it in nav adds noise to the accessibility tree — screen reader users who jump between landmarks will encounter a “navigation” region that contains almost nothing useful. Reserve nav for genuine link groups; a lone link can simply sit in the footer or a paragraph.

<footer>
  <p>&copy; 2026 MyCompany. <a href="/privacy">Privacy Policy</a></p>
</footer>

Mistake 2: Multiple unlabeled nav elements

<nav>
  <ul><li><a href="/">Home</a></li></ul>
</nav>
<nav>
  <ul><li><a href="/sitemap">Sitemap</a></li></ul>
</nav>

This is well-formed HTML, but both landmarks are announced identically as just “navigation” to a screen reader, leaving the user unable to tell them apart without exploring each one’s contents. When a page has more than one nav, distinguish them with aria-label:

<nav aria-label="Main">
  <ul><li><a href="/">Home</a></li></ul>
</nav>
<nav aria-label="Sitemap">
  <ul><li><a href="/sitemap">Sitemap</a></li></ul>
</nav>

Mistake 3: Using nav for a non-navigation link list

A list of external article citations or a tag cloud unrelated to site navigation is not what nav is for — nav specifically implies links a user would use to move around the site or document, not just any cluster of anchors. For those cases, a plain ul or an aside is more appropriate.

Best Practices

Use nav only for major, block-level navigation — main menus, tables of contents, breadcrumbs, and pagination — not for every isolated link.
When a page has more than one nav element, add aria-label (or aria-labelledby pointing to a heading) to each so assistive technology can distinguish them.
Structure the links inside nav as a list (ul or ol) when they represent a set of equally-weighted destinations — this gives screen readers a count of items and lets users navigate item by item.
Do not nest a nav inside another nav; keep navigation landmarks flat and distinct.
Remember that nav carries no default visual styling — menu bars, dropdowns, and hover effects are entirely a CSS concern layered on top of the semantic markup.
Place a site’s primary nav inside header when it represents global site navigation, which reinforces the page’s overall landmark structure.

Practice Exercises

Build a nav containing an unordered list with four links: Home, Services, Portfolio, and Contact. Wrap it inside a header element.
Create a page with two nav elements — one for a main menu and one for a footer sitemap — and label each with aria-label so they are distinguishable to a screen reader.
Given a paragraph in a footer that contains a single “Back to top” link, decide whether it should be wrapped in nav, and explain your reasoning.

Summary

The nav element semantically marks up a major block of navigation links, such as a main menu, breadcrumb trail, or pagination controls.
Browsers assign an implicit ARIA role of navigation to nav elements, exposing them as landmarks in the accessibility tree so screen reader users can jump straight to them.
nav has no default visual styling beyond being block-level; all menu appearance comes from CSS.
A page can contain multiple nav elements, but each should be labeled with aria-label when there is more than one, so they can be told apart.
Not every group of links needs nav — reserve it for genuinely major navigation blocks, not incidental single links.