The <article> Element
Technical Summary
article represents a complete piece of content that can, in principle, be distributed or reused on its own. Examples include a blog post, a forum post, a comment, or a news story.
Its HTML categories are Flow content, Sectioning content, and Palpable content. Its content model is Flow content, and its DOM interface is HTMLElement. HTML-AAM maps it to the WAI-ARIA article role. This role is not a navigation landmark.
Definition, categories, and context
The HTML Standard defines article as a complete piece of content that can, in principle, be distributed or reused independently. “Independent” does not mean that it has no connection to its parent page or site. It describes content that can be treated as one composition.
| Item | Specification definition | Review point |
|---|---|---|
| Categories | Flow content / Sectioning content / Palpable content | article is one of the elements that creates a section in the document |
| Context | Where Sectioning content is expected | It can appear in the document body and within other sectioning content |
| Content model | Flow content | It can contain ordinary text, headings, and sections |
| Tag omission | Neither the start tag nor the end tag can be omitted | An omitted closing tag is non-conforming |
| DOM interface | Uses HTMLElement | No article-specific DOM interface is defined |
What “independent content” means
Independence is not decided by a URL, a visual card, or a database record alone. A useful test is whether the composition could be moved to a feed, search result, or another page and still be treated as one piece of content. Writing article does not itself publish, extract, or redistribute anything.
The Standard's examples include a news or magazine article, a blog entry, a user comment, and a widget that can be treated as independent content. These are examples; the element does not require a particular URL format or content-management system.
<main>
<h1>News</h1>
<article aria-labelledby="notice-title">
<h2 id="notice-title">Our opening hours are changing</h2>
<p>Our opening hours will change next month.</p>
<p>Published: <time datetime="2026-10-30">October 30, 2026</time></p>
</article>
</main>
Here, main identifies the page's primary content, and article identifies one news item within the list. The time element marks a date. Adding a date does not automatically add syndication behavior or structured data.
Nesting and content relationships
When an article contains another article, the inner article represents content related to the outer one. A blog post can contain its comments this way. Nesting elements does not create a reply thread or interactive discussion feature.
<article aria-labelledby="post-title">
<h2 id="post-title">A bird I saw in the park</h2>
<p>I saw a white bird near the pond.</p>
<article aria-labelledby="comment-title">
<h3 id="comment-title">Comment</h3>
<p>I saw one in the same place last week.</p>
</article>
</article>
The inner article does not automatically inherit the outer article's author, heading, or date. The HTML Standard says that author information associated with an article does not apply to its nested articles. The WAI-ARIA article role also states that author, heading, date, and other information do not carry over to nested articles.
article, section, main, and div
| Element | Represents | A useful question |
|---|---|---|
article | One piece of content that can stand on its own | Could this composition be treated as one item elsewhere? |
section | A thematic group within a page or application | Is there a topic that belongs in the document's structure and needs a heading? |
main | The page's primary content | Is this the central content unique to the page? |
div | A generic group with no added meaning | Is the group only for styling or scripts? |
These elements can be combined. A main can contain several articles. One article can contain sections for its topics. A section can contain several articles. Choose a combination that follows the content model and the meaning of the page.
Headings, names, and accessibility
Adding article does not create a heading or change the level of h1–h6. Choose heading levels for the document's overall hierarchy. Put a real heading in the markup when readers need it to understand the piece.
HTML-AAM 1.0 Working Draft maps the HTML article element to the WAI-ARIA article role. WAI-ARIA defines this as a document-structure role, not a navigation landmark. Its accessible name comes from the author, and the role definition says a name is required. To name an article, reference its visible heading with aria-labelledby. The native element already supplies the role, so an extra role="article" is normally unnecessary.
<article aria-labelledby="review-title">
<h2 id="review-title">Customer review</h2>
<p>This example uses the heading text as the article's accessible name.</p>
</article>
This naming pattern does not turn every small group into a landmark. Use a landmark such as main when people need to jump to a major page area; use article to expose the structure of an independent composition.
Fact / Evidence
The specification definition, HTML-AAM role mapping, and WAI-ARIA role characteristics have separate sources. Browser and WPT results are limited to the environments and selected coverage shown here.
| Type | Fact / claim | Conditions / scope | Status | Source |
|---|---|---|---|---|
| SPEC | article represents complete content that can, in principle, be distributed or reused independently. | Meaning of the article element in the HTML Standard. Does not assert an automatic publishing behavior. | Specification checked | HTML Standard: article |
| SPEC | A nested article represents content related to its parent; the parent's author information does not automatically apply to the nested article. | Nested article structure and author-information rule. | Specification checked | HTML Standard: nested article |
| AAM | HTML-AAM maps article to the article role. The role is not a landmark and its name comes from the author. | HTML-AAM mapping and WAI-ARIA 1.2 role definition; separate from platform API measurements. | Specification checked | HTML-AAM: article mapping; WAI-ARIA: article role |
Evidence
- HTML Living Standard: The article element — categories, context, content model, definition, examples, nesting, and author information
- HTML Living Standard: The section element — thematic groups and the article/section usage distinction
- HTML Accessibility API Mappings 1.0 Working Draft, 21 October 2026: article — the HTML article role mapping
- WAI-ARIA 1.2: article role — document structure role, author naming, and the distinction from landmarks
- Web Platform Tests: html-aam/roles.html at revision 68d964a5f292bc4b2c2eba2f21e2b916190b6ad2 — selected computed-role checks, including article
Implementation Evidence
On 2026-10-30, Chromium 151 was used to observe all four pages at widths from 320 to 1920px, along with language switching and system/light/dark themes. One pinned WPT file passed all 60 checks, including the article check. This local run used the Chromium DevTools Protocol to read computed roles, so it is distinct from an official wptrunner run. The Evidence rows record the conditions.
| Type | Reproduced scope | Recorded conditions | Status |
|---|---|---|---|
| IMPL | Four Japanese/English Yugien and Atlas pages; global navigation, search, locale switching, canonical / hreflang, 320–1920px responsive widths, system / light / dark themes, and article role / name | 2026-10-30 JST / Windows 11 build 26300 / Chromium 151.0.7922.34 / Playwright 1.62.1 / DPR 1 / local HTTP 127.0.0.1:4173. All four pages returned HTTP 200, exposed two Japanese/English alternate links and five shared navigation links, and had no document-level horizontal overflow at 320, 390, 768, 1280, and 1920px. System theme followed emulated dark and light OS preferences; explicit light and dark settings were also checked. A long WPT revision link found overflowing at 320px was made wrappable and remeasured. Details: build-config/yugien/research-results/article-v1/browser-report.json. Same-site link check: 13 Yugien / 25 Atlas anchors per page, 9 unique routes per page; all returned HTTP 200, with no missing fragments or failed local resources. Browser search found the article and its English alternate in Japanese Atlas, and the article and Japanese alternate in English Yugien. |
Partial observation (Chromium 151 / four pages / 320–1920px) |
| WPT | Selected HTML-AAM computed-role test for article in html-aam/roles.html |
2026-10-30 JST / Chromium 151.0.7922.34. WPT testharness in html-aam/roles.html (68d964a5f292bc4b2c2eba2f21e2b916190b6ad2): 60/60 passed, including el-article. The pinned test file and harness were used; only test_driver.get_computed_role was connected through a Playwright / Chromium DevTools Protocol adapter. The official wptrunner / WebDriver runner was not used. Other browsers and test files were not run. Details: build-config/yugien/research-results/article-v1/wpt-report.json.WPT version used: |
Partial run (Chromium 151 / 60 checks / CDP adapter) |
| AAM | Chromium Accessibility Tree role, accessible name, and nesting for native article elements |
2026-10-30 JST / Chromium 151.0.7922.34 / Playwright CDP. Each of the four pages exposed its article as role article, named from the h1 referenced by aria-labelledby. The five fixture article nodes also had role article; the unnamed example had an empty name, and heading-reference, aria-label, and nested names were observed. The fixture main had role main; all eight DOM checks passed. Chromium browser tree only. Windows UI Automation / IAccessible2 and Narrator, NVDA, or other spoken output were not measured. Details: build-config/yugien/research-results/article-v1/browser-report.json. |
Partial observation (Chromium Accessibility Tree only) |
Coverage / Open Issues
- Specification checkedMeaning, categories, context, content model, section/main distinctions, nesting, and HTML-AAM / WAI-ARIA role
- ObservedFour Japanese/English pages, five viewport widths, three theme settings, the Chromium Accessibility Tree, and one pinned WPT file
- OpenOther browsers and operating systems, platform APIs such as Windows UI Automation and IAccessible2, assistive-technology speech, and the full HTML-AAM/WPT scope
See the Evidence rows for the exact conditions and results. Other browsers and operating systems, Windows accessibility APIs, screen-reader output, and the full WPT suite remain untested. These results do not establish conformance across all environments.