HTML5 tags for frontend developers: the tags list and what each one tells a screen reader

What are the HTML5 tags for frontend developers, and what does each one expose?#

HTML5 tags give content meaning, but only some change what a screen reader hears: nav, main and article map to roles, while q maps to a generic role. The W3C's HTML-AAM draft of 5 October 2026 lists the role for every element. In it, nav maps to the navigation role, main to main and article to article. However, q maps to generic, the same role a div gets.

So the useful split among HTML5 semantic tags is not old tags against new tags. Instead, it is tags that hand the browser a role against tags that only carry meaning in the source. A screen reader builds its view from the accessibility tree. That tree holds each element's role, name and state. Because of that, a tag with a named role gives a listener something to jump to or hear. A tag mapped to generic gives them only the text inside it.

The meaning still matters, though. For example, the WHATWG standard gives q a rule of its own. It says "The q element must not be used in place of quotation marks that do not represent quotes." In practice, the meaning is a promise to search engines, scripts and other developers. Meanwhile, the role is the promise to the person using a screen reader. So the HTML5 tags list below keeps both in view.

Why does the choice of HTML5 tag matter more than how the page looks?#

A native tag hands screen reader users a role with no ARIA to maintain, and WebAIM's February 2026 scan found pages using ARIA averaged 59.1 detected errors against 42 without. Two pages can look the same and still differ in what they expose. For example, a div styled as a menu bar looks like navigation, but it exposes the generic role. Yet a nav element exposes the navigation role with no extra code.

That gap in WebAIM's 2026 report is a link, not proof that ARIA causes errors. WebAIM itself puts it as an expected 17 more potential barriers on pages with ARIA present. Still, every role you add by hand is code to keep right as the page changes. Therefore, the cheapest role to maintain is the one the tag already carries.

Here is what that looks like on a plain blog page. If you use header, nav, main, aside and footer at body scope, the browser gives you five landmarks. Those are banner, navigation, main, complementary and contentinfo, straight from the HTML-AAM mappings, with no role attribute. Then a screen reader user can jump between those regions. But the same page built from divs gives them nothing to jump to. It stays that way until someone adds five role attributes and keeps them in sync.

Which HTML5 tags are on the list, and which ones were new in HTML5?#

The HTML5 tags list below pairs each tag with its meaning in the WHATWG standard and the role HTML-AAM maps it to, and flags the ones HTML5 introduced. The W3C's HTML5 differences note of 9 December 2014 names the new tags in HTML5 for page structure. They were section, article, main, aside, header, footer, nav and figure, with figcaption beside it. Also, that same note lists mark and time among the other new HTML5 tags.

In effect, the table is an HTML5 tags list with examples of what each tag does to the accessibility tree. Its meaning column follows the MDN element reference. Its role column follows HTML-AAM.

Source: W3C HTML-AAM, Working Draft 5 October 2026 (roles); MDN element reference, 16 September 2026 (meanings); W3C HTML5 differences note, 9 December 2014 (new elements).

Two rows need a note. First, not all HTML5 tags must be closed: the WHATWG standard gives br and wbr "No end tag" in their entries. Second, the HTML semantic tags in the upper half are where landmarks come from. Most text-level tags sit in the lower half.

When do header, footer, aside and section become landmarks?#

A header or footer is a landmark only at body scope, and a section becomes a region landmark only when it has an accessible name, such as a heading it points to. HTML-AAM gives header the banner role when it is scoped to the body element. But inside main or a sectioning element, the same header maps to sectionheader, which is not a landmark.

The rule for section is just as strict. HTML-AAM's draft of 5 October 2026 maps it to the "region role if the section element has an accessible name." Without one, it maps to generic. So a section with no name adds nothing to the landmark list. Also, an aside inside a section is complementary only when it is named. At body or main scope, an aside always is.

Take the blog page from earlier and add two section elements inside main. With no names, the landmark count stays at five, because both sections map to generic. Then point each section's aria-labelledby at its own h2. Now each one is a region, and the page has seven landmarks.

Real pages are moving this way, slowly. In WebAIM's February 2026 scan, more home pages had a landmark, a main landmark and a search landmark than in 2025.

Do screen readers announce q, mark, del, ins and s?#

Mostly not: MDN says mark is not announced by most screen readers by default, q maps to a generic role, and only JAWS and NVDA convey del, ins and mark. MDN's mark page was last modified on 28 September 2026. It says "The presence of the mark element is not announced by most screen reading technology in its default configuration." As for q, HTML-AAM gives it the generic role. So the quotation marks the browser draws are all a listener gets.

Vispero tested JAWS, NVDA, Narrator and VoiceOver on macOS and iOS, on default settings. Its report is dated 26 January 2023 and was updated 7 September 2023. Its summary reads "JAWS and NVDA convey ins, del and mark semantics." It also found that "Narrator does not convey any HTML semantics." In addition, VoiceOver on iOS conveys del and ins, but not mark.

Source: Vispero (TPGi), "Screen Readers support for text level HTML semantics", 26 January 2023, updated 7 September 2023; default settings.

So when a price was cut or a word was flagged, and the meaning matters, put it in words too. For example, write "was" before an old price inside del, or add a short visible label beside a mark. In short, the tag is for machines and sighted readers, and the words are for everyone.

Is HTML5 still a version, or is it just HTML now?#

HTML5 is now the WHATWG HTML Living Standard, and WebAIM's February 2026 scan found a valid HTML5 doctype on 93.2% of the top million home pages. Since then, the standard has not shipped numbered versions. Instead, the WHATWG updates one living document, and new tags join the same list. So the HTML5 new tags from the 2014 note and the later search element now sit in one standard.

The search element shows how the list grows. The WHATWG standard says "The search element represents a part of a document or application" that holds search or filter controls. And MDN's search page says it has been "available across browsers since October 2023." As a result, an HTML 5 tags list from 2014 and one from today differ, even though both are filed under HTML5.

Whether you call them HTML5 tags, HTML 5 tags or HTML5 keywords, they are one set of elements. The WHATWG element index holds every one of them. Meanwhile, the doctype stays a single short line, which is why nearly every page now declares it.

Which documentation pages should you build your markup from?#

Build from three pages in order: MDN's element reference to pick the tag, the MDN page for that tag to check its usage, then HTML-AAM to confirm the role it exposes. Since each page answers one question, keep them open in that order.

1. MDN element reference: pick the tag by purpose, from the grouped list of what each element represents.
2. The section page: sections "should always have a heading", and naming one is what turns it into a region.
3. The details page: a disclosure widget with no script, labelled by its summary.
4. The search page: the search landmark, which "removes the need for adding role=search" to a form.
5. HTML-AAM: confirm the role each element maps to, scope rules included.

Then check the result in your browser. Google's web.dev guide shows how Chrome DevTools lets you explore an element's place in the accessibility tree. The roles there should match HTML-AAM.

How do you mark up a page skeleton so the landmarks come out right?#

The skeleton below uses header, nav, search, main, a named section, aside and footer, so the browser builds the landmarks with no ARIA role attributes at all. That is how to use HTML5 tags in practice. First pick the tag, then place it in the right scope, then name the parts that need a name. Like the table, it gives HTML5 tags with examples, this time ready to paste. The comments mark the five steps.

<!doctype html>
<html lang="en">
<head><meta charset="utf-8"><title>Tags list demo</title></head>
<body>
  <!-- Step 1: body-scope header with nav = banner + navigation -->
  <header>
    <a href="/">Home</a>
    <nav aria-label="Main"><a href="/blog/">Blog</a></nav>
  </header>
  <!-- Step 2: search wraps the form = search landmark -->
  <search>
    <form action="/search/">
      <label for="q">Search</label>
      <input id="q" name="q" type="search">
    </form>
  </search>
  <!-- Step 3: main, and a section named by its heading = main + region -->
  <main>
    <section aria-labelledby="tags-h">
      <h2 id="tags-h">Tags list</h2>
      <!-- Step 4: details and summary = a disclosure with no script -->
      <details>
        <summary>What does q expose?</summary>
        <p>The generic role, so keep words that say it is a quote.</p>
      </details>
    </section>
  </main>
  <!-- Step 5: body-scope aside and footer = complementary + contentinfo -->
  <aside aria-label="Related posts"><a href="/blog/">More posts</a></aside>
  <footer><p>Site footer</p></footer>
</body>
</html>

Once it is open, count the landmarks in the accessibility tree. By the HTML-AAM mappings, you should see seven: banner, navigation, search, main, region, complementary and contentinfo. If the region is missing, the section lost its name. Also, if banner shows as sectionheader, the header moved inside main.

When not to use a semantic tag, and when is a div still right?#

Use a div or span when no tag's meaning fits, because a wrong semantic tag adds a false role that is worse than a generic one. HTML-AAM maps div and span to generic, which tells assistive technology nothing at all. And that is the honest answer for a wrapper that exists only for layout.

The W3C's ARIA in HTML note also warns against the opposite habit. Its rule reads "Avoid specifying redundant roles", which covers role="main" on a main element. Meanwhile, div is still by far the most used element. The HTTP Archive's 2024 Web Almanac counts it at 28.7% of elements on mobile pages. Still, most of those are fine, because most wrappers have no meaning to express.

What should you read next on accessible markup?#

The next step after the tags list is checking roles by hand and testing with a real screen reader, and the posts below cover both. The roles in the table above are ARIA roles, and the guide to ARIA roles explains when to add one yourself. Then, to hear what your markup says, screen reader compatibility testing walks through the products in the matrix.

Then move to behaviour. The keyboard navigation and focus management post covers details, dialog and focus order. Since the search element wraps a form, accessible forms covers the labels inside it.

If a team wants a second pair of ears on its markup, accessibility testing is one route. Others want a frontend developer who writes these tags from the first commit. Either way, MDN and HTML-AAM are enough to get the tags right on your own.