HTML Guides for article

The <article> element is meant to wrap independent, self-contained content such as blog posts, news stories, forum posts, product cards, or user comments. The W3C validator raises this warning because an <article> without a heading has no programmatic label, making it harder for users—especially those relying on screen readers—to understand what the article is about and to navigate between multiple articles on a page.

Screen readers often present a list of landmarks and headings to help users jump through a page’s structure. When an <article> has no heading, it appears as an unlabeled region, which is confusing and defeats the purpose of using semantic HTML. A heading inside the <article> acts as its identifying title, giving both sighted users and assistive technology a clear summary of the content that follows.

This is a warning rather than a hard validation error, but it signals a real accessibility and usability concern. In nearly all cases, every <article> should contain a heading. The heading level you choose should fit logically within the document’s heading hierarchy—typically <h2> if the <article> sits directly under the page’s main <h1>, or <h3> if it’s nested inside a section that already uses <h2>.

How to fix it

1. Add a heading element (<h2>–<h6>) as one of the first children inside each <article>.
2. Choose the correct heading level based on the document outline. Don’t skip levels (e.g., jumping from <h1> to <h4>).
3. Make the heading descriptive. It should clearly summarize the article’s content.

If your design doesn’t visually display a heading, you can use CSS to visually hide it while keeping it accessible to screen readers (see the examples below).

Examples

❌ Article without a heading (triggers the warning)

<h1>Latest news</h1>
<article>
  <p>Our new product launched today with great success.</p>
</article>
<article>
  <p>We are hiring frontend developers. Apply now!</p>
</article>

Each <article> here has no heading, so assistive technologies cannot identify them, and the validator raises a warning.

✅ Articles with proper headings

<h1>Latest news</h1>
<article>
  <h2>Product launch a success</h2>
  <p>Our new product launched today with great success.</p>
</article>
<article>
  <h2>We're hiring frontend developers</h2>
  <p>We are hiring frontend developers. Apply now!</p>
</article>

✅ Nested articles with correct heading hierarchy

<h1>Our blog</h1>
<article>
  <h2>How to validate accessibility</h2>
  <p>Use automated tools for an in-depth scan of your site.</p>
  <section>
    <h3>Comments</h3>
    <article>
      <h4>Comment by Alex</h4>
      <p>Great article, very helpful!</p>
    </article>
  </section>
</article>

When articles are nested (e.g., comments inside a blog post), each level gets the next heading level to maintain a logical outline.

✅ Visually hidden heading for design flexibility

If your design doesn’t call for a visible heading but you still need one for accessibility, use a CSS utility class to hide it visually while keeping it in the accessibility tree:

<style>
  .visually-hidden {
    position: absolute;
    width: 1px;
    height: 1px;
    padding: 0;
    margin: -1px;
    overflow: hidden;
    clip: rect(0, 0, 0, 0);
    white-space: nowrap;
    border: 0;
  }
</style>

<article>
  <h2 class="visually-hidden">Featured promotion</h2>
  <p>Save 20% on all items this weekend only!</p>
</article>

This approach satisfies both the validator and assistive technologies without affecting your visual layout. Avoid using display: none or visibility: hidden, as those also hide the heading from screen readers.

The W3C HTML validator enforces rules about which ARIA roles can be applied to specific HTML elements. The <section> element carries implicit semantics — it maps to the ARIA region role when it has an accessible name (e.g., via aria-label or aria-labelledby). While article is indeed a valid ARIA role defined in the WAI-ARIA specification, the HTML specification restricts which roles can override a <section> element’s native semantics. The allowed roles for <section> include alert, alertdialog, application, contentinfo, dialog, document, feed, log, main, marquee, navigation, none, note, presentation, search, status, tabpanel, and region — but not article.

This restriction exists because HTML already provides the <article> element, which carries the implicit article ARIA role natively. Using role="article" on a <section> creates a confusing mismatch: the element’s tag name suggests one semantic meaning while the role attribute declares another. This can confuse assistive technologies like screen readers, which may announce the element inconsistently depending on whether they prioritize the tag name or the explicit role.

The best fix depends on your intent:

• If the content is self-contained and independently meaningful (like a blog post, comment, or news story), replace the <section> with an <article> element. The <article> element already has the implicit article role, so no role attribute is needed.
• If the content is a thematic grouping within a page, keep the <section> element and remove the role attribute. Give it a heading or an aria-label so it functions as a meaningful landmark.
• If you specifically need the article role on a non-semantic element, use a <div> with role="article" instead, since <div> has no implicit role and allows any ARIA role to be applied.

Examples

Incorrect: role="article" on a <section>

This triggers the validation error because article is not a permitted role for <section>.

<section role="article">
  <h2>Breaking news</h2>
  <p>Details about the event.</p>
</section>

Correct: use <article> for self-contained content

The <article> element has the implicit article role, making the explicit role attribute unnecessary.

<article>
  <h2>Breaking news</h2>
  <p>Details about the event.</p>
</article>

Correct: use <section> without a conflicting role

If the content is a thematic grouping rather than a standalone piece, keep <section> and drop the role attribute. Adding an accessible name via aria-labelledby makes it a region landmark.

<section aria-labelledby="news-heading">
  <h2 id="news-heading">Latest news</h2>
  <p>Details about the event.</p>
</section>

Correct: use a <div> when you need an explicit article role

In rare cases where you cannot use the <article> element but need the article role, a <div> accepts any valid ARIA role.

<div role="article">
  <h2>Breaking news</h2>
  <p>Details about the event.</p>
</div>

Correct: nest <article> inside <section> for grouped articles

If you need both a thematic grouping and individual self-contained items, nest <article> elements inside a <section>.

<section aria-labelledby="stories-heading">
  <h2 id="stories-heading">Top stories</h2>
  <article>
    <h3>First story</h3>
    <p>Story content.</p>
  </article>
  <article>
    <h3>Second story</h3>
    <p>Story content.</p>
  </article>
</section>

As a general rule, prefer native HTML elements over ARIA roles whenever possible. The <article> element communicates the article role more reliably than any ARIA override, and it works consistently across all browsers and assistive technologies without additional attributes.

The article element is a sectioning content element that represents a self-contained composition — a blog post, a news story, a forum entry, or similar independent content. Because it carries the implicit ARIA role of article, it functions as a landmark that assistive technologies recognize and expose to users for navigation. Overriding this landmark role with listitem creates a conflict: the element loses its article semantics for assistive technology users, and the listitem role itself becomes invalid because ARIA’s role mapping rules don’t permit it on article.

According to the ARIA in HTML specification, each HTML element has a set of allowed ARIA roles. The article element only permits a narrow set of roles (such as application, document, feed, main, none, presentation, and region). The listitem role is not among them. This restriction exists to prevent authors from creating confusing or contradictory semantics that would degrade the accessibility experience.

Beyond validation, this matters for real users. Screen readers rely on role information to convey structure. An article announced as a listitem is misleading — the user loses the ability to navigate by article landmarks, and the listitem may not function correctly without a proper parent list context. Browsers and assistive technologies expect listitem roles to appear as direct children of an element with role="list" (or within native ul/ol elements).

How to fix it

The solution depends on your intent:

• If you want a list of articles, use native HTML list markup (ul or ol with li) and place each article inside a list item. This gives you both list semantics and article landmarks without any ARIA overrides.
• If you can’t use native list elements, use neutral div elements with role="list" and role="listitem", and nest the article inside each listitem container.
• If the content isn’t truly a list, simply remove the role="listitem" attribute and let the article element use its native semantics.

Examples

Invalid: role="listitem" on an article element

This triggers the validator error because listitem is not an allowed role for article.

<article role="listitem">
  <h2>News item</h2>
  <p>Details about this story.</p>
</article>

Valid: native list with article elements inside

Using ul and li provides proper list semantics while preserving the article landmark role.

<ul>
  <li>
    <article>
      <h2>News item</h2>
      <p>Details about this story.</p>
    </article>
  </li>
  <li>
    <article>
      <h2>Another item</h2>
      <p>More details here.</p>
    </article>
  </li>
</ul>

Valid: ARIA list roles on neutral containers with nested article elements

When native list elements aren’t suitable for your layout, use div elements for the list structure and nest each article inside.

<div role="list">
  <div role="listitem">
    <article>
      <h2>News item</h2>
      <p>Details about this story.</p>
    </article>
  </div>
  <div role="listitem">
    <article>
      <h2>Another item</h2>
      <p>More details here.</p>
    </article>
  </div>
</div>

Valid: standalone article without a list role

If the content doesn’t belong in a list, simply remove the invalid role.

<article>
  <h2>News item</h2>
  <p>Details about this story.</p>
</article>

In every case, the key principle is the same: let the article element keep its native semantics, and use the appropriate list structure around it rather than forcing a conflicting role onto it.

The article element has an implicit ARIA role of article, which signals to assistive technologies that it contains a self-contained, independently distributable piece of content—like a blog post, news story, or forum entry. When you add role="tabpanel" to an article, you’re attempting to override this strong semantic meaning with a widget role, which the HTML specification does not permit. The ARIA in HTML specification defines a strict set of allowed roles for each HTML element, and tabpanel is not in the list of permissible roles for article.

This matters for several reasons. First, assistive technologies like screen readers rely on accurate role information to communicate the purpose of elements to users. An article element claiming to be a tabpanel creates a confusing and contradictory signal. Second, the W3C validator flags this as an error, meaning your markup is technically invalid. Third, browsers may handle this conflict inconsistently—some might honor the explicit role, while others might prioritize the element’s native semantics, leading to unpredictable behavior across platforms.

The tabpanel role is designed for use in a tab interface pattern alongside role="tablist" and role="tab". According to the WAI-ARIA Authoring Practices, a tab panel should be a generic container that holds the content associated with a tab. Elements like div and section are ideal because they don’t carry conflicting implicit roles (div has no implicit role, and section maps to region only when given an accessible name, which gets properly overridden by tabpanel).

To fix the issue, simply change the article element to a div or section. If you genuinely need the semantic meaning of article within a tab panel, nest the article inside the div that carries the tabpanel role.

Examples

Incorrect: tabpanel role on an article element

<article role="tabpanel" id="panel1">
  <h2>Latest News</h2>
  <p>Tab panel content here.</p>
</article>

This triggers the validation error because article does not allow the tabpanel role.

Correct: tabpanel role on a div

<div role="tabpanel" id="panel1">
  <h2>Latest News</h2>
  <p>Tab panel content here.</p>
</div>

Correct: Nesting an article inside the tab panel

If you need the article semantics for the content within the panel, nest it:

<div role="tabpanel" id="panel1">
  <article>
    <h2>Latest News</h2>
    <p>This is a self-contained article displayed within a tab panel.</p>
  </article>
</div>

Full tab interface example

Here’s a complete, valid tab interface implementation:

<!DOCTYPE html>
<html lang="en">
<head>
  <title>Tab Interface Example</title>
</head>
<body>
  <div role="tablist" aria-label="Topics">
    <button role="tab" id="tab1" aria-controls="panel1" aria-selected="true">News</button>
    <button role="tab" id="tab2" aria-controls="panel2" aria-selected="false">Sports</button>
  </div>
  <div role="tabpanel" id="panel1" aria-labelledby="tab1">
    <p>Latest news content goes here.</p>
  </div>
  <div role="tabpanel" id="panel2" aria-labelledby="tab2" hidden>
    <p>Sports content goes here.</p>
  </div>
</body>
</html>

Note the use of aria-controls on each tab to reference its corresponding panel, aria-labelledby on each tabpanel to reference its controlling tab, and the hidden attribute on inactive panels. These associations ensure assistive technologies can properly navigate the tab interface.

Every HTML semantic element carries an implicit ARIA role that assistive technologies already recognize. The <article> element has a built-in role of article, which signals that the content represents a self-contained composition — such as a blog post, news story, forum comment, or any section that could be independently distributed or reused. When you explicitly add role="article" to an <article> element, you’re telling the browser and screen readers something they already know.

While this redundancy won’t break anything functionally, it creates unnecessary noise in your markup and goes against the W3C’s guidance on using ARIA. The first rule of ARIA use states: “If you can use a native HTML element or attribute with the semantics and behavior you require already built in, instead of repurposing an element and adding an ARIA role, state or property to make it accessible, then do so.” Redundant roles make code harder to maintain and can signal to other developers that something non-standard is happening when it isn’t.

The role="article" attribute is useful when applied to non-semantic elements like <div> or <span> that need to convey article semantics — for instance, in legacy codebases where changing the element isn’t feasible. But on the <article> element itself, it should simply be removed.

Examples

❌ Redundant role on <article>

This triggers the validator warning because role="article" duplicates the element’s implicit role:

<article role="article">
  <h2>Breaking News</h2>
  <p>A rare bird was spotted in the city park this morning.</p>
</article>

✅ Fixed: no explicit role needed

Simply remove the role attribute. The <article> element already communicates the article role to assistive technologies:

<article>
  <h2>Breaking News</h2>
  <p>A rare bird was spotted in the city park this morning.</p>
</article>

✅ Appropriate use of role="article" on a non-semantic element

If you cannot use the <article> element for some reason, applying the role to a generic element like <div> is valid and useful:

<div role="article">
  <h2>Breaking News</h2>
  <p>A rare bird was spotted in the city park this morning.</p>
</div>

✅ Multiple articles within a feed

A common pattern is nesting several <article> elements inside a feed. No explicit roles are needed on the articles themselves:

<section role="feed" aria-label="Latest posts">
  <article>
    <h2>First Post</h2>
    <p>Content of the first post.</p>
  </article>
  <article>
    <h2>Second Post</h2>
    <p>Content of the second post.</p>
  </article>
</section>

This same principle applies to other semantic elements with implicit roles — for example, <nav> already has role="navigation", <main> has role="main", and <header> has role="banner". Avoid adding redundant roles to any of these elements to keep your HTML clean and standards-compliant.

The <main> element serves a very specific purpose in HTML: it identifies the primary content of the document’s <body> — the content that is directly related to or expands upon the central topic of the page. Because of this document-level role, the HTML specification restricts where <main> can appear. It must not be a descendant of <article>, <aside>, <header>, <footer>, or <nav>. These are all sectioning or structural elements that represent subsets of the page, and nesting <main> inside them creates a semantic contradiction — you’d be saying “the main content of the whole page lives inside this one sub-section.”

The <article> element, by contrast, represents a self-contained composition — something like a blog post, a news story, a forum post, or a comment. Articles are meant to be independently distributable or reusable. They logically live within the main content area of a page, not around it.

This distinction matters for accessibility. Screen readers and assistive technologies use the <main> landmark to let users skip directly to the primary content of a page. When <main> is incorrectly nested inside an <article>, assistive technologies may misinterpret the document structure, making navigation confusing or unreliable. Search engines also rely on semantic HTML to understand page structure, so incorrect nesting can affect how your content is indexed.

To fix this issue, move the <main> element out of the <article> and make it a direct child of <body> (or of a non-sectioning element like <div>). Then place your <article> elements inside <main>. Also remember that only one visible <main> element should exist per page (additional <main> elements must have the hidden attribute).

Examples

Incorrect: <main> nested inside <article>

This triggers the validation error because <main> is a descendant of <article>:

<article>
  <main>
    <h1>My Blog Post</h1>
    <p>This is the post content.</p>
  </main>
</article>

Incorrect: <main> deeply nested inside <article>

The error also triggers when <main> is an indirect descendant — it doesn’t need to be a direct child:

<article>
  <div class="wrapper">
    <main>
      <h1>My Blog Post</h1>
      <p>This is the post content.</p>
    </main>
  </div>
</article>

Correct: <article> inside <main>

Invert the relationship so that <main> wraps the article content:

<main>
  <article>
    <h1>My Blog Post</h1>
    <p>This is the post content.</p>
  </article>
</main>

Correct: Multiple articles inside <main>

A typical page layout with <main> containing several articles alongside other content:

<main>
  <h1>Latest Posts</h1>
  <article>
    <h2>First Post</h2>
    <p>Content of the first post.</p>
  </article>
  <article>
    <h2>Second Post</h2>
    <p>Content of the second post.</p>
  </article>
</main>

Correct: Full document structure

A complete valid document showing the proper placement of <main> as a direct child of <body>:

<!DOCTYPE html>
<html lang="en">
<head>
  <title>Blog - Latest Posts</title>
</head>
<body>
  <header>
    <nav>
      <a href="/">Home</a>
      <a href="/about">About</a>
    </nav>
  </header>
  <main>
    <h1>Latest Posts</h1>
    <article>
      <h2>My Blog Post</h2>
      <p>This is the post content.</p>
    </article>
  </main>
  <footer>
    <p>© 2024 My Blog</p>
  </footer>
</body>
</html>

The key rule to remember: <main> represents the page’s primary content and sits at the top of your content hierarchy. Sectioning elements like <article>, <aside>, and <nav> are components within that hierarchy and belong inside or alongside <main> — never around it.