HTML Validation

HTML Guides

Learn how to identify and fix common HTML validation errors flagged by the W3C Validator — so your pages are standards-compliant and render correctly across every browser. Also check our Accessibility Guides.

Scan Your Site Free

A “charset” attribute on a “meta” element found after the first 1024 bytes.

charset
meta

A character encoding declaration tells the browser how to interpret the raw bytes of your document into readable characters. For HTML documents, the standard way to declare this is with <meta charset="utf-8">. The HTML specification requires that this element be serialized completely within the first 1024 bytes of the document. This means that everything from the start of the file—including the doctype, the <html> tag, the <head> tag, and the <meta charset> element itself—must fit within that 1024-byte window.

If the <meta charset> element appears after the first 1024 bytes, the browser must use other heuristics or fallback encodings to guess how to decode the document. This can cause several problems:

Garbled or broken text: Characters outside the ASCII range (such as accented letters, CJK characters, or emoji) may render incorrectly.
Security vulnerabilities: Certain encoding-sniffing behaviors have historically been exploited for cross-site scripting (XSS) attacks, which is one reason the spec enforces this strict limit.
Inconsistent rendering: Different browsers may fall back to different default encodings, meaning your page could look different depending on the user’s browser or system locale.

This issue typically occurs when a large number of <meta> tags, inline <style> blocks, lengthy comments, or <script> elements are placed in the <head> before the <meta charset> declaration. Even excessive whitespace or server-injected content can push it past the 1024-byte boundary.

To fix this, ensure that <meta charset="utf-8"> is the first child element of <head>, appearing before any <title>, <link>, <script>, <style>, or other <meta> tags. Remove or relocate any unnecessary content that precedes it.

Examples

❌ Incorrect: <meta charset> pushed past 1024 bytes

In this example, a large inline style block and several meta tags appear before the charset declaration, easily exceeding the 1024-byte limit:

<!DOCTYPE html>
<html lang="en">
  <head>
    <meta name="description" content="A very long description...">
    <meta name="keywords" content="many, keywords, here, ...">
    <meta name="author" content="Some Author">
    <link rel="stylesheet" href="styles.css">
    <style>
      /* Hundreds of bytes of inline CSS rules...
         ...pushing the total well past 1024 bytes
         before the charset declaration appears */
      body { font-family: sans-serif; margin: 0; padding: 0; }
      .container { max-width: 1200px; margin: 0 auto; }
      /* ...many more rules... */
    </style>
    <meta charset="utf-8">
    <title>My Page</title>
  </head>
  <body>
    <p>Hello world</p>
  </body>
</html>

✅ Correct: <meta charset> as the first element in <head>

Move the charset declaration to the very first position inside <head>:

<!DOCTYPE html>
<html lang="en">
  <head>
    <meta charset="utf-8">
    <title>My Page</title>
    <meta name="description" content="A very long description...">
    <meta name="keywords" content="many, keywords, here, ...">
    <meta name="author" content="Some Author">
    <link rel="stylesheet" href="styles.css">
    <style>
      body { font-family: sans-serif; margin: 0; padding: 0; }
      .container { max-width: 1200px; margin: 0 auto; }
    </style>
  </head>
  <body>
    <p>Hello world</p>
  </body>
</html>

✅ Minimal correct example

For simpler documents, the pattern is straightforward—just keep <meta charset> first:

<!DOCTYPE html>
<html lang="en">
  <head>
    <meta charset="utf-8">
    <title>My Page</title>
  </head>
  <body>
    <p>Hello world</p>
  </body>
</html>

As a general rule of thumb, always make <meta charset="utf-8"> the very first thing after the opening <head> tag. This guarantees it falls well within the 1024-byte limit regardless of what follows, and it ensures the browser knows the correct encoding before it encounters any other content.

A document must not include both a “meta” element with an “http-equiv” attribute whose value is “content-type”, and a “meta” element with a “charset” attribute.

Both <meta charset="UTF-8"> and <meta http-equiv="content-type" content="text/html; charset=UTF-8"> instruct the browser which character encoding to use when interpreting the document’s bytes into text. Having both declarations in the same document creates a redundant and potentially conflicting situation. The HTML specification explicitly forbids including both, because if they ever specified different encodings, the browser would have to decide which one to trust, leading to unpredictable behavior.

Character encoding is critical for correctly displaying text. If the encoding is wrong or ambiguous, characters like accented letters, emoji, or symbols from non-Latin scripts can appear as garbled text (often called “mojibake”). By requiring a single, unambiguous declaration, the spec ensures browsers can reliably determine the encoding.

The <meta charset="UTF-8"> syntax was introduced with HTML5 as a shorter, cleaner alternative to the older <meta http-equiv="content-type"> approach. Both are valid on their own, but modern best practice strongly favors <meta charset="UTF-8"> for its simplicity. Whichever you choose, it should appear as early as possible within the <head> element — ideally as the first child — and must appear within the first 1024 bytes of the document so the browser can detect the encoding before parsing the rest of the content.

To fix this issue, search your document’s <head> for both forms of the declaration and remove one of them. In most cases, you should keep <meta charset="UTF-8"> and remove the <meta http-equiv="content-type"> element.

Examples

Incorrect: both declarations present

This triggers the validation error because both methods of declaring the character encoding are used simultaneously.

<!DOCTYPE html>
<html lang="en">
  <head>
    <meta charset="UTF-8">
    <meta http-equiv="content-type" content="text/html; charset=UTF-8">
    <title>My Page</title>
  </head>
  <body>
    <p>Hello, world!</p>
  </body>
</html>

Correct: using <meta charset> (recommended)

This is the modern, preferred approach for HTML5 documents.

<!DOCTYPE html>
<html lang="en">
  <head>
    <meta charset="UTF-8">
    <title>My Page</title>
  </head>
  <body>
    <p>Hello, world!</p>
  </body>
</html>

Correct: using <meta http-equiv="content-type">

This older syntax is also valid on its own. You might encounter it in legacy codebases or when serving documents as application/xhtml+xml.

<!DOCTYPE html>
<html lang="en">
  <head>
    <meta http-equiv="content-type" content="text/html; charset=UTF-8">
    <title>My Page</title>
  </head>
  <body>
    <p>Hello, world!</p>
  </body>
</html>

Common scenario: declarations split across includes

In templating systems or CMS platforms, the two declarations sometimes end up in different partial files — for example, one in a base layout and another injected by a plugin or theme. If you encounter this error unexpectedly, check all files that contribute to your <head> section, not just the main template.

<!-- base-layout.html -->

<head>
  <meta charset="UTF-8">
<!-- ...other tags... -->

</head>

<!-- plugin-head-snippet.html (remove this duplicate) -->

<meta http-equiv="content-type" content="text/html; charset=UTF-8">

Audit your includes and partials to ensure only one character encoding declaration ends up in the final rendered <head>.

A document must not include more than one “meta” element with a “charset” attribute.

meta
charset

The <meta charset> element tells the browser which character encoding to use when interpreting the bytes of the HTML document. The HTML specification explicitly states that there must be no more than one <meta> element with a charset attribute per document. This declaration should appear within the first 1024 bytes of the document, so placing it as the first child of <head> (right after the opening <head> tag) is the recommended practice.

Duplicate charset declarations typically happen when code is assembled from multiple templates, partials, or snippets — each contributing its own <meta charset>. It can also occur when a developer manually adds a charset declaration without realizing one is already present, or when migrating from an older <meta http-equiv="Content-Type"> approach and adding a new <meta charset> without removing the old equivalent.

Why this matters

Standards compliance: The WHATWG HTML living standard mandates at most one <meta charset> per document. Violating this produces a validation error.
Unpredictable behavior: When a browser encounters conflicting or duplicate charset declarations, the behavior is undefined. While most modern browsers will use the first one encountered, relying on this is fragile and could lead to garbled text or encoding issues in edge cases.
Maintainability: Multiple charset declarations signal disorganized or duplicated template logic, making the codebase harder to maintain.

How to fix it

Search your HTML document (including any templates, layouts, or partials that compose the final output) for all instances of <meta charset> or <meta charset="...">.
Keep exactly one <meta charset="utf-8"> declaration, placed as the first element inside <head>.
Remove all other <meta charset> elements.
If you also have a legacy <meta http-equiv="Content-Type" content="text/html; charset=utf-8">, remove it — the shorter <meta charset="utf-8"> form is the modern replacement, and having both counts as duplicate charset declarations.

Examples

❌ Incorrect: multiple charset declarations

<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="utf-8">
  <meta charset="utf-8">
  <title>My Page</title>
</head>
<body>
  <p>Hello, world!</p>
</body>
</html>

The second <meta charset="utf-8"> triggers the validation error, even though both specify the same encoding.

❌ Incorrect: mixing old and new charset syntax

<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="utf-8">
  <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  <title>My Page</title>
</head>
<body>
  <p>Hello, world!</p>
</body>
</html>

Both elements declare a character encoding, so the validator treats this as a duplicate.

✅ Correct: single charset declaration

<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="utf-8">
  <title>My Page</title>
</head>
<body>
  <p>Hello, world!</p>
</body>
</html>

A single <meta charset="utf-8"> appears first in <head>, before any other elements or content. This is the correct and recommended approach. UTF-8 is the strongly recommended encoding for all new HTML documents.

A document must not include more than one “meta” element with its “name” attribute set to the value “description”.

The <meta name="description"> element provides a brief summary of a page’s content. According to the WHATWG HTML living standard, there must be no more than one <meta> element per document where the name attribute has the value "description". This is a conformance requirement — not just a best practice — meaning that including duplicates produces invalid HTML.

Why this matters

Standards compliance: The HTML specification explicitly states that certain metadata names, including "description", must be unique within a document. Violating this makes your HTML non-conforming.

Search engine behavior: Search engines like Google use the meta description to generate snippet text in search results. When multiple description meta tags are present, search engines must decide which one to use — or may ignore them entirely and pull text from the page body instead. This can result in a less relevant or less compelling snippet, potentially reducing click-through rates.

Maintainability: Duplicate meta descriptions often arise from template conflicts — for example, a CMS injecting one description while a theme or plugin adds another. Having duplicates makes it unclear which description is actually intended, creating confusion for developers maintaining the code.

Common causes

A CMS or static site generator automatically inserts a <meta name="description"> tag, while the template or theme also hardcodes one.
Multiple HTML partials or includes each contribute their own description meta tag to the <head>.
Copy-paste errors when building or editing the <head> section.

How to fix it

Search your HTML source for all instances of <meta name="description".
Decide which description best represents the page’s content.
Remove all duplicate instances, keeping only one.
If your content comes from templates or includes, trace where each tag is generated and ensure only one source outputs the description.

Examples

❌ Invalid: duplicate description meta tags

<!DOCTYPE html>
<html lang="en">
<head>
  <title>About Us</title>
  <meta name="description" content="Learn about our company and mission.">
  <meta name="description" content="We are a team of passionate developers.">
</head>
<body>
  <h1>About Us</h1>
  <p>Welcome to our about page.</p>
</body>
</html>

The validator will report an error because two <meta> elements share name="description".

✅ Valid: single description meta tag

<!DOCTYPE html>
<html lang="en">
<head>
  <title>About Us</title>
  <meta name="description" content="Learn about our company, mission, and the team of passionate developers behind it.">
</head>
<body>
  <h1>About Us</h1>
  <p>Welcome to our about page.</p>
</body>
</html>

Here, the two descriptions have been merged into a single, more comprehensive meta description. Alternatively, you could simply keep whichever original description was more accurate and discard the other.

❌ Invalid: duplicates from mixed sources (common template issue)

<head>
  <title>Blog Post</title>
<!-- Injected by CMS -->

  <meta name="description" content="Auto-generated summary of the blog post.">
<!-- Hardcoded in theme template -->

  <meta name="description" content="A blog about web development tips and tricks.">
  <meta name="author" content="Jane Smith">
</head>

✅ Valid: single source of truth

<head>
  <title>Blog Post</title>
<!-- Injected by CMS (theme duplicate removed) -->

  <meta name="description" content="Auto-generated summary of the blog post.">
  <meta name="author" content="Jane Smith">
</head>

When fixing template-driven duplicates, decide which system should own the description — typically the CMS, since it can generate page-specific descriptions — and remove the hardcoded one from the theme.

Make sure your final <meta name="description"> content is meaningful, concise (typically 150–160 characters), and accurately reflects what visitors will find on the page.

A document must not include more than one visible “main” element.

The <main> element represents the dominant, unique content of a document — the primary content that is directly related to or expands upon the central topic of the page. Having more than one visible <main> element creates ambiguity: browsers, screen readers, and other assistive technologies use <main> to identify the primary content area, and multiple visible instances make it unclear which content block is truly the main one.

This is particularly important for accessibility. Screen reader users often rely on landmark navigation to jump directly to the main content of a page. When multiple visible <main> elements exist, this shortcut becomes unreliable or confusing, as the user has no way to know which <main> holds the content they’re looking for.

There are legitimate scenarios where multiple <main> elements make sense — for example, in single-page applications (SPAs) where different views are swapped in and out dynamically using JavaScript. The HTML specification accommodates this by allowing multiple <main> elements as long as only one is visible at a time. The others must be hidden using the hidden attribute.

How to fix it

If you only need one main content area, remove the extra <main> elements and keep just one.
If you need multiple views (e.g., for tabbed content or SPA-style navigation), add the hidden attribute to all <main> elements except the one currently active. Use JavaScript to toggle visibility by adding or removing the hidden attribute as needed.

Examples

❌ Invalid: Two visible <main> elements

<header>
  <h1>My Website</h1>
</header>

<main>
  <h2>Welcome</h2>
  <p>This is the home page content.</p>
</main>

<main>
  <h2>About</h2>
  <p>This is the about page content.</p>
</main>

Both <main> elements are visible, which violates the specification and confuses assistive technologies.

✅ Fixed: Single <main> element

If you don’t need multiple views, simply use one <main>:

<header>
  <h1>My Website</h1>
</header>

<main>
  <h2>Welcome</h2>
  <p>This is the home page content.</p>
</main>

✅ Fixed: Multiple <main> elements with only one visible

If you need multiple views for JavaScript-driven navigation, hide all but the active one using the hidden attribute:

<header>
  <nav>
    <button onclick="switchView('home')">Home</button>
    <button onclick="switchView('about')">About</button>
  </nav>
</header>

<main id="home">
  <h2>Welcome</h2>
  <p>This is the home page content.</p>
</main>

<main id="about" hidden>
  <h2>About</h2>
  <p>This is the about page content.</p>
</main>

In this pattern, JavaScript would toggle the hidden attribute when the user navigates between views, ensuring only one <main> is ever visible at a time.

❌ Invalid: Using CSS instead of hidden

Note that hiding a <main> element with CSS (e.g., display: none or visibility: hidden) does not satisfy the HTML specification. The validator checks for the hidden attribute, not CSS styles:

<!-- This still triggers the validation error -->

<main>
  <h2>Welcome</h2>
</main>

<main style="display: none;">
  <h2>About</h2>
</main>

Always use the hidden attribute to indicate that a <main> element is not currently relevant to the page.

A “figure” element with a “figcaption” descendant must not have a “role” attribute.

The HTML <figure> element represents self-contained content — such as an image, diagram, code snippet, or quotation — optionally accompanied by a caption provided by a <figcaption> element. When a <figcaption> is present, the browser and assistive technologies already understand the relationship between the figure and its caption. This built-in semantic relationship is part of the ARIA in HTML specification, which governs how native HTML elements map to accessibility roles.

The role attribute is typically used to assign or override the ARIA role of an element for assistive technologies like screen readers. However, the ARIA in HTML specification explicitly restricts certain role assignments when an element’s native semantics are already well-defined by its content. A <figure> with a <figcaption> is one such case — the presence of the caption establishes a clear semantic structure that the role attribute would interfere with.

This restriction exists for several important reasons:

Accessibility conflicts: Adding role="figure" is redundant since the element already has that implicit role. Adding a different role (like role="img" or role="group") could confuse assistive technologies by contradicting the semantic meaning established by the <figcaption>. Screen readers may ignore the caption or announce the element incorrectly.
Standards compliance: The ARIA in HTML specification states that when a <figure> has a <figcaption> descendant, no role attribute is allowed. The W3C validator enforces this rule.
Maintainability: Relying on native HTML semantics rather than ARIA overrides keeps your markup simpler and less error-prone. The first rule of ARIA is: “If you can use a native HTML element with the semantics and behavior you require already built in, do so.”

To fix this issue, remove the role attribute from the <figure> element. The <figcaption> provides all the semantic context needed.

Examples

Incorrect: role attribute on <figure> with <figcaption>

Adding role="figure" is redundant and triggers the validation error:

<figure role="figure">
  <img src="chart.png" alt="Sales data for Q3 2024">
  <figcaption>Figure 1: Quarterly sales by region.</figcaption>
</figure>

Using a different role like role="img" also triggers the error and can cause accessibility problems:

<figure role="img">
  <img src="chart.png" alt="Sales data for Q3 2024">
  <figcaption>Figure 1: Quarterly sales by region.</figcaption>
</figure>

Correct: <figure> with <figcaption> and no role

Simply remove the role attribute. The <figure> and <figcaption> elements handle semantics on their own:

<figure>
  <img src="chart.png" alt="Sales data for Q3 2024">
  <figcaption>Figure 1: Quarterly sales by region.</figcaption>
</figure>

Correct: <figure> without <figcaption> can use a role

If you have a <figure> without a <figcaption>, the restriction does not apply. In this case, you may use a role attribute if needed:

<figure role="img" aria-label="Sales data for Q3 2024">
  <img src="chart.png" alt="">
</figure>

Correct: <figure> with <figcaption> containing other media

The fix applies regardless of the type of content inside the <figure>:

<figure>
  <pre><code>const greeting = "Hello, world!";</code></pre>
  <figcaption>A simple variable assignment in JavaScript.</figcaption>
</figure>

<figure>
  <blockquote>
    <p>The best way to predict the future is to invent it.</p>
  </blockquote>
  <figcaption>Alan Kay</figcaption>
</figure>

In every case, the <figcaption> provides the accessible name and descriptive context for the <figure>, making any role attribute unnecessary and non-conformant.

A “link” element must have an “href” or “imagesrcset” attribute, or both.

The <link> element defines a relationship between the current document and an external resource — most commonly stylesheets, icons, preloaded assets, or canonical URLs. According to the HTML specification, the element must include at least one of the href or imagesrcset attributes so the browser knows what resource is being linked. A <link> element without either attribute is essentially an empty declaration: it tells the browser about a relationship type (via rel) but provides no actual resource to fetch or reference.

This validation error commonly occurs in a few scenarios:

Templating or CMS issues: A dynamic template generates a <link> tag but the URL variable is empty or undefined, resulting in a bare element with no href.
Incomplete code: A developer adds a <link> with a rel attribute intending to fill in the href later but forgets to do so.
Copy-paste mistakes: Attributes are accidentally removed during editing or refactoring.

Fixing this is important for several reasons. Browsers may ignore the element entirely or behave unpredictably when encountering a <link> with no resource URL. Unnecessary elements without purpose add bloat to the document and can confuse other developers reading the code. Additionally, tools that parse HTML — such as search engine crawlers and assistive technologies — rely on well-formed markup to correctly understand document relationships.

To resolve the issue, add an href attribute pointing to the target resource, use an imagesrcset attribute when providing responsive image sources, or include both when appropriate.

Examples

Invalid: missing both href and imagesrcset

This <link> declares a stylesheet relationship but doesn’t specify where the stylesheet is located:

<link rel="stylesheet">

This preload link has an as attribute but no resource to fetch:

<link rel="preload" as="image" type="image/png">

Fixed: using href

The most common fix is adding an href attribute with a valid URL:

<link rel="stylesheet" href="styles.css">

<link rel="icon" href="favicon.ico">

<link rel="canonical" href="https://example.com/page">

Fixed: using imagesrcset

For responsive image preloading, the imagesrcset attribute specifies multiple image sources at different resolutions. This is valid without href:

<link rel="preload" as="image" type="image/png" imagesrcset="icon-1x.png 1x, icon-2x.png 2x">

Fixed: using both href and imagesrcset

You can combine both attributes. The href serves as a fallback resource while imagesrcset provides responsive alternatives:

<link rel="preload" as="image" href="icon-1x.png" imagesrcset="icon-1x.png 1x, icon-2x.png 2x">

Handling dynamic templates

If your <link> elements are generated dynamically, make sure the element is only rendered when a valid URL is available. For example, in a template, wrap the output in a conditional check rather than outputting an empty <link>:

<!-- Bad: outputs a link even when the URL is empty -->

<link rel="stylesheet" href="">

<!-- Good: only include the element when there's a real URL -->

<link rel="stylesheet" href="styles.css">

Note that href="" resolves to the current page URL and is technically valid syntax (it won’t trigger this specific error), but it’s almost certainly not what you intend. Always ensure the href value points to the correct resource.

A “link” element must not appear as a descendant of a “body” element unless the “link” element has an “itemprop” attribute or has a “rel” attribute whose value contains “dns-prefetch”, “modulepreload”, “pingback”, “preconnect”, “prefetch”, “preload”, “prerender”, or “stylesheet”.

link

The HTML specification restricts where <link> elements can appear based on their purpose. Links that load resources needed for rendering (like stylesheets and preloaded assets) or carry microdata (itemprop) are allowed in <body> because they have a direct relationship to the content around them. Other types of <link> elements—canonical URLs, icons, alternate versions—are document-level metadata and belong exclusively in <head>.

This matters for several reasons. Browsers may ignore or inconsistently handle <link> elements placed in unexpected locations, leading to issues like missing canonical signals for search engines or broken favicon references. Standards compliance also ensures your HTML is forward-compatible and behaves predictably across all browsers.

Common causes

Direct placement in <body>

The most straightforward cause is placing a metadata <link> directly inside <body>, often due to a CMS, template system, or plugin injecting it in the wrong location.

Implicit <body> creation by the parser

A subtler cause occurs when an element that’s only valid in <body> appears inside <head>. When the HTML parser encounters such an element (like <img>, <div>, or <p>), it implicitly closes the <head> and opens the <body>. Any <link> elements that follow are then treated as descendants of <body>, even though they appear to be inside <head> in your source code.

For example, an <img> tag in the <head> causes the parser to switch to body context, so the subsequent <link rel="canonical"> is interpreted as being inside <body> and triggers this error.

How to fix it

Move disallowed <link> elements to <head>: If a <link> with rel="canonical", rel="icon", rel="alternate", or similar values is in <body>, move it into <head>.
Check for body-only elements in <head>: Look for elements like <img>, <div>, <p>, <script> (without src), or text content that may have been accidentally placed in <head>. These cause the parser to implicitly close <head>, making everything after them part of <body>.
Use allowed rel values if a body placement is intentional: If you genuinely need a <link> in <body>, ensure it uses one of the permitted rel values (stylesheet, preload, prefetch, preconnect, dns-prefetch, modulepreload, pingback, prerender) or has an itemprop attribute.

Examples

❌ <link rel="canonical"> placed in <body>

<body>
  <link rel="canonical" href="https://example.com/page">
  <h1>Welcome</h1>
</body>

✅ Move it to <head>

<head>
  <title>My Page</title>
  <link rel="canonical" href="https://example.com/page">
</head>
<body>
  <h1>Welcome</h1>
</body>

❌ An <img> in <head> forces implicit body context

Even though the <link> appears to be in <head>, the <img> causes the parser to switch to body context:

<!DOCTYPE html>
<html lang="en">
  <head>
    <title>Test</title>
    <img src="photo.jpg" alt="A smiling cat">
    <link rel="canonical" href="https://example.com/">
  </head>
  <body>
    <p>Some content</p>
  </body>
</html>

✅ Move the <img> to <body> where it belongs

<!DOCTYPE html>
<html lang="en">
  <head>
    <title>Test</title>
    <link rel="canonical" href="https://example.com/">
  </head>
  <body>
    <img src="photo.jpg" alt="A smiling cat">
    <p>Some content</p>
  </body>
</html>

✅ Allowed <link> elements inside <body>

These are valid because they use permitted rel values:

<body>
  <article>
    <link rel="stylesheet" href="article-theme.css">
    <h2>Article Title</h2>
    <p>Content here.</p>
  </article>
  <link rel="prefetch" href="/next-page.html">
  <link rel="preload" href="/font.woff2" as="font" type="font/woff2" crossorigin>
</body>

✅ Using itemprop for microdata

A <link> with an itemprop attribute is also valid inside <body>:

<body>
  <div itemscope itemtype="https://schema.org/Product">
    <span itemprop="name">Widget</span>
    <link itemprop="availability" href="https://schema.org/InStock">
  </div>
</body>

A “link” element with a “rel” attribute that contains the value “preload” must have an “as” attribute.

The preload value of the <link> element’s rel attribute lets you declare fetch requests in the HTML <head>, telling the browser to start loading critical resources early in the page lifecycle—before the main rendering machinery kicks in. This can significantly improve performance by ensuring key assets are available sooner and are less likely to block rendering.

However, a preload hint is incomplete without the as attribute. The as attribute tells the browser what kind of resource is being fetched. This matters for several important reasons:

Request prioritization: Browsers assign different priorities to different resource types. A stylesheet is typically higher priority than an image. Without as, the browser cannot apply the correct priority, and the preloaded resource may be fetched with a low default priority, undermining the purpose of preloading.
Content Security Policy (CSP): CSP rules are applied based on resource type (e.g., script-src, style-src). Without knowing the type, the browser cannot enforce the appropriate policy.
Correct Accept header: The as value determines which Accept header the browser sends with the request. For example, an image request sends a different Accept header than a script request. An incorrect or missing header could lead to unexpected responses from the server.
Cache matching: When the resource is later requested by a <script>, <link rel="stylesheet">, or other element, the browser needs to match it against the preloaded resource in its cache. Without as, the browser may not recognize the preloaded resource and could fetch it again, resulting in a duplicate request—the opposite of what you intended.

The HTML specification explicitly requires the as attribute when rel="preload" is used, making this a conformance error.

Common as Values

The as attribute accepts a specific set of values. Here are the most commonly used ones:

Value	Resource Type
script	JavaScript files
style	CSS stylesheets
font	Web fonts
image	Images
fetch	Resources fetched via fetch() or XMLHttpRequest
document	HTML documents (for <iframe>)
audio	Audio files
video	Video files
track	WebVTT subtitle tracks
worker	Web workers or shared workers

Examples

Incorrect: Missing as attribute

This will trigger the validation error because the browser doesn’t know what type of resource is being preloaded:

<link rel="preload" href="/fonts/roboto.woff2">

<link rel="preload" href="/js/app.js">

Correct: as attribute included

Adding the appropriate as value tells the browser exactly what kind of resource to expect:

<link rel="preload" href="/fonts/roboto.woff2" as="font" type="font/woff2" crossorigin>

<link rel="preload" href="/js/app.js" as="script">

<link rel="preload" href="/css/main.css" as="style">

<link rel="preload" href="/images/hero.webp" as="image">

Note on fonts and crossorigin

When preloading fonts, you must also include the crossorigin attribute, even if the font is hosted on the same origin. This is because font fetches are CORS requests by default. Without crossorigin, the preloaded font won’t match the later font request and will be fetched twice:

<!-- Correct: includes both as and crossorigin for fonts -->

<link rel="preload" href="/fonts/roboto.woff2" as="font" type="font/woff2" crossorigin>

Full document example

<!DOCTYPE html>
<html lang="en">
  <head>
    <meta charset="utf-8">
    <title>Preload Example</title>
    <link rel="preload" href="/css/main.css" as="style">
    <link rel="preload" href="/js/app.js" as="script">
    <link rel="preload" href="/fonts/roboto.woff2" as="font" type="font/woff2" crossorigin>
    <link rel="stylesheet" href="/css/main.css">
  </head>
  <body>
    <h1>Hello, world!</h1>
    <script src="/js/app.js"></script>
  </body>
</html>

Choosing the correct as value is straightforward—just match it to how the resource will ultimately be used on the page. If you’re preloading a stylesheet, use as="style"; if it’s a script, use as="script", and so on.

A “link” element with an “as” attribute must have a “rel” attribute that contains the value “preload” or the value “modulepreload”.

The as attribute specifies the type of content a <link> element is fetching — such as "style", "script", "font", or "image". The browser uses this information to set the correct request headers, apply the right Content Security Policy, and assign the appropriate priority to the request. However, the HTML specification restricts the as attribute to <link> elements whose rel attribute is either "preload" or "modulepreload". Using as with any other rel value (like "stylesheet", "icon", or a missing rel altogether) is invalid HTML.

This validation error commonly occurs in two scenarios:

You intended to preload a resource but forgot to set rel="preload" — for example, writing <link href="styles.css" as="style"> without specifying rel.
You added as to a regular <link> by mistake — for example, writing <link rel="stylesheet" href="styles.css" as="style">, where as is unnecessary because rel="stylesheet" already tells the browser what type of resource it is.

Getting this right matters for several reasons. Browsers rely on valid rel values to determine how to handle linked resources. An incorrect combination may cause the browser to ignore the as attribute entirely, leading to double-fetching of resources or incorrect prioritization. Additionally, invalid HTML can cause unpredictable behavior across different browsers.

How to fix it

If you want to preload a resource (font, stylesheet, image, script, etc.), set rel="preload" and keep the as attribute.
If you want to preload a JavaScript module, set rel="modulepreload". The as attribute defaults to "script" for module preloads and is optional in that case.
If you’re using a different rel value like "stylesheet" or "icon", remove the as attribute — it’s not needed and not allowed.

Examples

Incorrect: as attribute without rel="preload"

This <link> has as="style" but no rel attribute:

<link href="styles.css" as="style">

Incorrect: as attribute with rel="stylesheet"

The as attribute is not valid on a stylesheet link:

<link rel="stylesheet" href="styles.css" as="style">

Correct: preloading a stylesheet

Use rel="preload" with the as attribute to hint the resource type:

<link rel="preload" href="styles.css" as="style">

Note that preloading a stylesheet doesn’t apply it — you still need a separate <link rel="stylesheet"> to actually use the CSS.

Correct: preloading a font

<link rel="preload" href="font.woff2" as="font" type="font/woff2" crossorigin>

The crossorigin attribute is required when preloading fonts, even if they’re served from the same origin.

Correct: preloading a JavaScript module

<link rel="modulepreload" href="app.js">

With rel="modulepreload", the as attribute defaults to "script", so you can omit it. You may still include it explicitly if you prefer:

<link rel="modulepreload" href="app.js" as="script">

Correct: regular stylesheet (no as needed)

If you simply want to load a stylesheet, no as attribute is required:

<link rel="stylesheet" href="styles.css">

Full document example

<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="UTF-8">
  <meta name="viewport" content="width=device-width, initial-scale=1.0">
  <title>Preload Example</title>
<!-- Preload critical resources -->

  <link rel="preload" href="styles.css" as="style">
  <link rel="preload" href="hero.jpg" as="image">
  <link rel="preload" href="font.woff2" as="font" type="font/woff2" crossorigin>
<!-- Apply the stylesheet -->

  <link rel="stylesheet" href="styles.css">
</head>
<body>
  <h1>Hello, World!</h1>
  <img src="hero.jpg" alt="Hero banner">
</body>
</html>

A “meta” element with an “http-equiv” attribute whose value is “X-UA-Compatible” must have a “content” attribute with the value “IE=edge”.

The X-UA-Compatible meta tag was originally introduced to control which rendering engine Internet Explorer would use to display a page. Developers could force IE to emulate older versions (e.g., IE=7, IE=9) or use the latest available engine with IE=edge. The value IE=edge,chrome=1 was also commonly used to activate the Google Chrome Frame plugin, which allowed Internet Explorer to use Chrome’s rendering engine instead.

The HTML specification now only permits the value IE=edge for this meta tag. Other values are considered invalid for several reasons:

Google Chrome Frame is discontinued. The chrome=1 directive targeted a plugin that was retired in February 2014 and is no longer supported by any browser.
Legacy IE rendering modes are obsolete. Internet Explorer itself has been retired, making emulation modes like IE=EmulateIE7 or IE=9 pointless.
Standards compliance. The WHATWG HTML living standard explicitly requires the content attribute value to be IE=edge when http-equiv="X-UA-Compatible" is used.

In practice, since all modern browsers use their latest rendering engine by default, this meta tag has little functional impact today. If your site no longer needs to support Internet Explorer at all, you can safely remove the tag entirely. If you choose to keep it — for example, in environments where legacy IE browsers might still access your site — ensure the value is exactly IE=edge.

Examples

Invalid: Using chrome=1 with IE=edge

This was a common pattern when Google Chrome Frame was active, but it now triggers a validation error:

<meta http-equiv="X-UA-Compatible" content="IE=edge,chrome=1">

Invalid: Using a legacy IE rendering mode

Forcing a specific IE version is no longer valid:

<meta http-equiv="X-UA-Compatible" content="IE=EmulateIE7">

Invalid: Specifying a particular IE version

<meta http-equiv="X-UA-Compatible" content="IE=9">

Valid: Using IE=edge

The only accepted value is IE=edge:

<meta http-equiv="X-UA-Compatible" content="IE=edge">

Valid: Removing the tag entirely

If you don’t need Internet Explorer compatibility, the simplest fix is to remove the meta tag altogether. A minimal valid document without it:

<!DOCTYPE html>
<html lang="en">
  <head>
    <meta charset="utf-8">
    <title>My Page</title>
  </head>
  <body>
    <p>Hello, world!</p>
  </body>
</html>

A numeric character reference expanded to carriage return.

The HTML specification explicitly forbids numeric character references from expanding to certain control characters, and the carriage return (U+000D) is one of them. Even though you can type  or in your markup, the spec defines this as a parse error. Browsers may handle it inconsistently — some will silently discard it, others may convert it to a different character — so relying on it leads to unpredictable behavior across environments.

The reason carriage return is singled out is rooted in how HTML normalizes line endings. During parsing, all carriage return characters (and carriage return + line feed pairs) are normalized to a single line feed (U+000A). Because the character is never preserved as-is, referencing it serves no practical purpose and is treated as an error. The WHATWG HTML Living Standard lists U+000D among the characters that must not appear as numeric character references.

Control characters in general are problematic in HTML text content. Most of them (U+0001 through U+001F, excluding tab, line feed, and form feed) are disallowed. The carriage return falls into this category because, after normalization, it effectively doesn’t exist in the parsed document.

How to fix it

Remove it — In most cases, the  reference is unnecessary. Simply delete it.
Replace with 
 — If you need a line break character reference (for example, in a title attribute or a pre element), use 
 (LINE FEED), which is a permitted space character in HTML.
Use <br> — If you need a visible line break in rendered content, use the <br> element instead of a character reference.

Examples

Incorrect: using a carriage return character reference

<p>First line&#13;Second line</p>

This triggers the validation error because  expands to the carriage return control character.

The same error occurs with hexadecimal notation:

<p>First line&#x0D;Second line</p>

Correct: using a line feed character reference

<p>First line&#10;Second line</p>

The 
 reference expands to LINE FEED (U+000A), which is allowed in HTML. Note that in normal flow, this renders as collapsible whitespace — it won’t produce a visible line break unless you’re inside a pre element or using CSS white-space: pre.

Correct: using <br> for a visible line break

<p>First line<br>Second line</p>

If the goal is a visible line break in the rendered output, the <br> element is the standard and most reliable approach.

Correct: line break in an attribute value

Sometimes  appears in attribute values where a newline is intended, such as in title tooltips:

<!-- Incorrect -->

<span title="Line one&#13;Line two">Hover me</span>

<!-- Correct -->

<span title="Line one&#10;Line two">Hover me</span>

The 
 reference is valid and some browsers will render it as a line break within tooltip text, though this behavior is not guaranteed across all browsers.

A numeric character reference expanded to the C1 controls range.

The C1 controls range spans Unicode code points U+0080 through U+009F (decimal 128–159). These are control characters inherited from older encoding standards, and the HTML specification explicitly forbids numeric character references that resolve to them. When the W3C validator encounters a reference like  (decimal 151, which is U+0097), it flags it because these code points are not valid content characters.

Why This Happens

This issue almost always stems from a confusion between the Windows-1252 (or CP-1252) character encoding and Unicode. Windows-1252 is a legacy encoding that repurposes the byte range 0x80–0x9F to store useful characters like curly quotes, em dashes, and the euro sign. In Unicode, however, those same code point positions are reserved as C1 control characters and carry no printable meaning.

When text originally encoded in Windows-1252 gets converted to HTML numeric references byte-by-byte — without proper re-mapping to Unicode — you end up with references like  instead of the correct ” for a right double quotation mark. The byte value was meaningful in Windows-1252, but the corresponding Unicode code point is a control character.

Why It Matters

Standards compliance: The HTML specification forbids these references. Browsers may handle them inconsistently, with some silently remapping them and others ignoring them entirely.
Portability: While some browsers apply the Windows-1252 remapping as a compatibility quirk, this behavior is not guaranteed across all user agents, platforms, or contexts (such as XML or XHTML, where these references cause parse errors).
Accessibility: Screen readers and other assistive technologies may not interpret C1 control characters at all, resulting in missing or garbled content for users who rely on them.
Data integrity: If your HTML is processed by tools, APIs, or parsers that follow the spec strictly, these invalid references can cause failures or data loss.

How to Fix It

Use named character references where available — they’re the most readable option (e.g., —, ’, €).
Use correct Unicode code points in numeric references if a named reference isn’t available (e.g., — or — for an em dash).
Use the literal UTF-8 character directly in your source file. If your document is saved as UTF-8 (which it should be), you can simply type —, ', or € directly.
Audit legacy content that may have been migrated from older systems or databases using Windows-1252 encoding. A search for numeric references in the 128–159 decimal range will find all instances.

Examples

Invalid: C1 control range references

These references resolve to C1 control code points, not the intended characters:

<p>Price: &#128;50</p>
<p>She said, &#147;Hello.&#148;</p>
<p>2020&#150;2024</p>
<p>Wait &#151; what?</p>
<p>It&#146;s a beautiful day.</p>

Fixed: Correct Unicode references

Replace each invalid reference with the proper Unicode code point or named reference:

<p>Price: &euro;50</p>
<p>She said, &ldquo;Hello.&rdquo;</p>
<p>2020&ndash;2024</p>
<p>Wait &mdash; what?</p>
<p>It&rsquo;s a beautiful day.</p>

Fixed: Using numeric Unicode code points

If you prefer numeric references, use the correct Unicode values:

<p>Price: &#x20AC;50</p>
<p>She said, &#8220;Hello.&#8221;</p>
<p>2020&#8211;2024</p>
<p>Wait &#8212; what?</p>
<p>It&#8217;s a beautiful day.</p>

Fixed: Using literal UTF-8 characters

The simplest approach — just use the characters directly in a UTF-8 encoded document:

<p>Price: €50</p>
<p>She said, "Hello."</p>
<p>2020–2024</p>
<p>Wait — what?</p>
<p>It's a beautiful day.</p>

A “script” element with a “defer” attribute must not have a “type” attribute with the value “module”.

The HTML living standard defines that scripts with type="module" are always fetched in parallel and evaluated after the document has been parsed, which is the same behavior that the defer attribute provides for classic scripts. Because this deferred execution is an inherent characteristic of module scripts, the spec explicitly forbids combining the two. Including both doesn’t change how the browser handles the script, but it signals a misunderstanding of how modules work and produces invalid HTML.

This validation error commonly arises when developers migrate classic scripts to ES modules. A classic script like <script defer src="app.js"></script> relies on the defer attribute to avoid blocking the parser. When converting to a module by adding type="module", it’s natural to leave defer in place — but it’s no longer needed or allowed.

It’s worth noting that the async attribute is valid on module scripts and does change their behavior. While defer is redundant because modules are already deferred, async overrides that default and causes the module to execute as soon as it and its dependencies have finished loading, rather than waiting for HTML parsing to complete.

How to Fix

Remove the defer attribute from any <script> element that has type="module". No other changes are needed — the loading and execution behavior will remain identical.

If you intentionally want the script to run as soon as possible (before parsing completes), use async instead of defer. But if you want the standard deferred behavior, simply omit both attributes and let the module default take effect.

Examples

❌ Incorrect: defer combined with type="module"

<script type="module" defer src="app.js"></script>

The defer attribute is redundant here and causes a validation error.

✅ Correct: module script without defer

<script type="module" src="app.js"></script>

Module scripts are deferred automatically, so this behaves exactly the same as the incorrect example above but is valid HTML.

✅ Correct: using async with a module (when needed)

<script type="module" async src="analytics.js"></script>

Unlike defer, the async attribute is permitted on module scripts. It causes the module to execute as soon as it’s ready, without waiting for HTML parsing to finish.

✅ Correct: classic script with defer

<script defer src="app.js"></script>

For classic (non-module) scripts, the defer attribute is valid and necessary if you want deferred execution.

A “script” element with a “src” attribute must not have a “type” attribute whose value is anything other than the empty string, a JavaScript MIME type, or “module”.

The <script> element serves two distinct purposes in HTML: loading executable scripts and embedding non-executable data blocks. When the src attribute is present, the element is always being used to load an external script, so the type attribute must reflect a valid script type. Setting type to something like "text/html", "text/plain", or an invented value like "wrong" tells the browser this is not JavaScript, which means the external file referenced by src will be fetched but never executed — almost certainly not what the author intended.

The HTML specification restricts the allowed type values for <script src="..."> to three categories:

An empty string (type=""): Treated the same as the default, which is JavaScript.
A JavaScript MIME type: This includes text/javascript, application/javascript, and other legacy JavaScript MIME types. Since text/javascript is the default, specifying it is redundant.
module: Indicates the script should be treated as a JavaScript module, enabling import/export syntax and deferred execution by default.

Any value outside these categories — such as text/html, application/json, or a made-up string — is invalid when src is present.

Why this matters

Broken functionality: A non-JavaScript type on a <script> with src prevents the browser from executing the loaded file. The script is effectively dead code that still costs a network request.

Standards compliance: The HTML living standard explicitly forbids this combination. Validators flag it because it almost always indicates a mistake — either the wrong type was applied, or the src attribute was added by accident.

Maintainability: Future developers reading the code may be confused about whether the script is supposed to execute or serve as an inert data block. Keeping markup valid makes intent clear.

How to fix it

Remove the type attribute entirely. This is the best approach for classic JavaScript. The default behavior is text/javascript, so no type is needed.
Use type="module" if the script uses ES module syntax (import/export).
If you intended a data block (e.g., embedding JSON or a template), remove the src attribute and place the content inline inside the <script> element instead. Data blocks with non-JavaScript types cannot use src.

Examples

Invalid: non-JavaScript types with src

These all trigger the validation error because the type value is not a JavaScript MIME type, an empty string, or "module":

<script type="text/html" src="template.html"></script>

<script type="application/json" src="data.json"></script>

<script type="text/plain" src="app.js"></script>

<script type="wrong" src="app.js"></script>

Valid: omitting the type attribute

The simplest and recommended fix for classic scripts — just drop type:

<script src="app.js"></script>

Valid: using a JavaScript MIME type

This is valid but redundant, since text/javascript is already the default. The validator may suggest omitting it:

<script type="text/javascript" src="app.js"></script>

Valid: using type="module"

Use this when the external script uses ES module syntax:

<script type="module" src="app.js"></script>

Valid: using an empty type attribute

An empty string is treated as the default. It’s valid but unnecessary, and the validator may suggest removing it:

<script type="" src="app.js"></script>

Valid: data blocks without src

If you need a non-JavaScript type for an inline data block, remove the src attribute and place the content directly inside the element:

<script type="application/json" id="config">
  {
    "apiUrl": "https://example.com/api",
    "debug": false
  }
</script>

A “select” element with a “required” attribute, and without a “multiple” attribute, and without a “size” attribute whose value is greater than “1”, must have a child “option” element.

The HTML specification enforces this rule because a required <select> element needs options for the user to choose from. Without any <option> children, the element is semantically meaningless — it’s a dropdown with nothing to select, yet the form demands a selection before submission. This creates an impossible situation for the user and an ambiguous state for the browser.

This rule specifically applies when all three of these conditions are true:

The required attribute is present.
The multiple attribute is not present.
The size attribute is either absent or set to 1 (the default for a single-selection <select>).

When multiple is set or size is greater than 1, the <select> behaves differently (as a list box rather than a dropdown), and the specification relaxes this constraint. But for the standard single-selection dropdown, at least one <option> is mandatory.

Why this matters

Usability: A required dropdown with no options gives users no way to satisfy the form requirement, effectively blocking form submission entirely.
Accessibility: Screen readers announce <select> elements along with their available options. An empty required dropdown creates a confusing experience for assistive technology users.
Form validation: Browsers use the first <option> with an empty value as the placeholder. The built-in constraint validation for required selects relies on checking whether the selected option’s value is a non-empty string. Without any options, this validation behavior is undefined.

How the placeholder pattern works

The HTML specification defines a specific behavior for required single-selection dropdowns: the first <option> element, if it has an empty value attribute, acts as a placeholder. When the form is submitted with this placeholder still selected, browser validation will reject the submission because the value is empty. This is the standard pattern for prompting users to make a deliberate choice.

Examples

❌ Invalid: required <select> with no options

<label for="color">Pick a color:</label>
<select id="color" name="color" required>
</select>

This triggers the validation error because there are no <option> elements inside the required <select>.

❌ Invalid: required <select> with only a group but no options

<label for="color">Pick a color:</label>
<select id="color" name="color" required>
  <optgroup label="Colors">
  </optgroup>
</select>

An empty <optgroup> doesn’t satisfy the requirement. The <select> still needs at least one <option>.

✅ Valid: required <select> with a placeholder and options

<label for="color">Pick a color:</label>
<select id="color" name="color" required>
  <option value="">--Select a color--</option>
  <option value="red">Red</option>
  <option value="green">Green</option>
  <option value="blue">Blue</option>
</select>

The first <option> has an empty value, so it serves as a placeholder. The browser will require the user to choose one of the other options before submitting the form.

✅ Valid: required <select> with multiple (rule does not apply)

<label for="colors">Pick one or more colors:</label>
<select id="colors" name="colors" required multiple>
</select>

This does not trigger the error because the multiple attribute is present, which exempts the element from this particular rule. However, an empty multi-select is still poor UX and should generally be avoided.

✅ Valid: required <select> with size greater than 1 (rule does not apply)

<label for="colors">Pick a color:</label>
<select id="colors" name="colors" required size="4">
</select>

When size is greater than 1, the element renders as a list box and the rule no longer applies. Again, while technically valid, an empty list box isn’t useful in practice.

✅ Valid: required <select> with grouped options

<label for="vehicle">Choose a vehicle:</label>
<select id="vehicle" name="vehicle" required>
  <option value="">--Select a vehicle--</option>
  <optgroup label="Cars">
    <option value="sedan">Sedan</option>
    <option value="suv">SUV</option>
  </optgroup>
  <optgroup label="Trucks">
    <option value="pickup">Pickup</option>
    <option value="semi">Semi</option>
  </optgroup>
</select>

Options inside <optgroup> elements count as child options of the <select>, so this is fully valid.

A slash was not immediately followed by “>”.

slash

The HTML parser expects a slash inside a tag to signal the end of a self-closing (void) element, such as <br /> or <img />. When the parser encounters a / that isn’t immediately followed by >, it can’t interpret the tag correctly and raises this error. This can happen in several scenarios:

A typo in an attribute name or value, such as accidentally typing a / instead of another character.
An unquoted attribute value that contains a slash, like a URL path.
A misplaced slash somewhere in the middle of a tag.

While browsers are generally forgiving and may still render the page, relying on error recovery leads to unpredictable behavior across different browsers. Fixing these issues ensures your markup is unambiguous, standards-compliant, and easier to maintain.

Examples

Stray slash in a tag (typo)

A common typo where a slash appears between attributes:

<!-- ❌ Slash not immediately followed by ">" -->

<input type="text" / name="username">

Remove the stray slash:

<!-- ✅ Correct -->

<input type="text" name="username">

Unquoted attribute value containing a slash

If an attribute value contains a / and isn’t wrapped in quotes, the parser sees the slash as part of the tag syntax rather than the value:

<!-- ❌ Unquoted value with slash confuses the parser -->

<img src=images/photo.jpg alt="Photo">

Always quote attribute values, especially those containing slashes:

<!-- ✅ Correct: quoted attribute value -->

<img src="images/photo.jpg" alt="Photo">

Slash in the wrong position for self-closing tags

Placing the slash before the final attribute instead of at the end of the tag:

<!-- ❌ Slash is not immediately before ">" -->

<img src="logo.png" / alt="Logo">

Move the self-closing slash to the very end, or simply remove it (self-closing syntax is optional in HTML5 for void elements):

<!-- ✅ Correct: slash at the end -->

<img src="logo.png" alt="Logo" />

<!-- ✅ Also correct: no self-closing slash needed in HTML -->

<img src="logo.png" alt="Logo">

Accidental double slash

Sometimes a self-closing tag ends up with an extra slash:

<!-- ❌ Double slash before ">" -->

<br //>

Use a single slash or omit it entirely:

<!-- ✅ Correct -->

<br />

<!-- ✅ Also correct -->

<br>

A “source” element that has a following sibling “source” element or “img” element with a “srcset” attribute must have a “media” attribute and/or “type” attribute.

The <picture> element exists to give browsers a choice between multiple image sources. The browser evaluates each <source> in order, looking for the first one whose conditions match the current environment. These conditions are expressed through the media attribute (e.g., viewport width or resolution) and the type attribute (e.g., image/webp or image/avif). If a <source> lacks both attributes, it acts as an unconditional match — the browser will always select it, making any subsequent <source> elements or an <img> with srcset unreachable. This defeats the purpose of the <picture> element entirely.

The HTML specification requires these attributes specifically to prevent this situation. When a <source> has a following sibling <source> or a following <img> with srcset, at least one selection criterion (media or type) must be present so the browser can meaningfully choose between the options. A <source> without these attributes is only valid if it’s the last <source> before a plain <img> (one without srcset), since in that case it serves as the final fallback within the <picture>.

This matters for several reasons:

Standards compliance: The HTML living standard explicitly defines this requirement. Violating it produces a validation error.
Predictable rendering: Without distinguishing attributes, browsers may silently ignore sources or always pick the first one, leading to inconsistent behavior across browsers.
Performance: The <picture> element is often used to serve smaller images on small viewports or modern formats like WebP and AVIF to browsers that support them. Without proper media or type attributes, these optimizations won’t work as intended.

How to fix it

Add a media attribute, a type attribute, or both to each <source> element that is followed by another <source> or an <img> with srcset:

Use type when you’re offering the same image in different formats (e.g., AVIF, WebP, JPEG). The browser picks the first format it supports.
Use media when you’re serving different images based on viewport conditions (art direction). The browser picks the source whose media query matches.
Use both when you want to combine format negotiation with art direction.

Examples

Incorrect — <source> without media or type

Each <source> below has no selection criterion, so the browser has no way to choose between them:

<picture>
  <source srcset="hero.webp">
  <source srcset="hero.jpg">
  <img src="hero.jpg" srcset="hero-2x.jpg 2x" alt="A mountain landscape">
</picture>

Correct — using type for format negotiation

Adding type lets the browser pick the first format it supports:

<picture>
  <source srcset="hero.avif" type="image/avif">
  <source srcset="hero.webp" type="image/webp">
  <img src="hero.jpg" srcset="hero-2x.jpg 2x" alt="A mountain landscape">
</picture>

Correct — using media for art direction

Adding media lets the browser pick the source that matches the viewport:

<picture>
  <source srcset="hero-wide.jpg" media="(min-width: 1024px)">
  <source srcset="hero-narrow.jpg" media="(max-width: 1023px)">
  <img src="hero-narrow.jpg" srcset="hero-narrow-2x.jpg 2x" alt="A mountain landscape">
</picture>

Correct — combining media and type

You can use both attributes together to serve the right format at the right viewport size:

<picture>
  <source srcset="hero-wide.avif" media="(min-width: 1024px)" type="image/avif">
  <source srcset="hero-wide.webp" media="(min-width: 1024px)" type="image/webp">
  <source srcset="hero-narrow.avif" media="(max-width: 1023px)" type="image/avif">
  <source srcset="hero-narrow.webp" media="(max-width: 1023px)" type="image/webp">
  <img src="hero-narrow.jpg" alt="A mountain landscape">
</picture>

Correct — single <source> before a plain <img>

When there’s only one <source> and the <img> has no srcset, no media or type is required — but adding type is still recommended for clarity:

<picture>
  <source srcset="hero.webp" type="image/webp">
  <img src="hero.jpg" alt="A mountain landscape">
</picture>

A table row was X columns wide and exceeded the column count established by the first row (Y).

In HTML, the structure of a <table> is implicitly defined by its rows and columns. The first <tr> in a table (or table section like <thead>, <tbody>, or <tfoot>) establishes the expected column count for the entire table. When a subsequent row contains more cells than the first row, the validator raises this error because the table’s column grid becomes inconsistent.

Browsers will still attempt to render mismatched tables, but the results can be unpredictable and problematic. Screen readers and other assistive technologies rely on a well-formed table grid to correctly associate data cells with their headers. An inconsistent column count can cause these tools to misread or skip content, making the table inaccessible to users who depend on them. Additionally, inconsistent tables are harder to style with CSS and can lead to unexpected layout shifts.

There are several common causes for this issue:

Missing cells in the first row — The first row has fewer <td> or <th> elements than subsequent rows.
Forgotten colspan — A cell in the first row should span multiple columns but is missing a colspan attribute.
Extra cells in later rows — A row further down the table has more cells than intended.
Mismatched colspan arithmetic — The sum of cells and their colspan values doesn’t add up consistently across rows.

To fix this, review every row in the table and ensure the total column count (accounting for colspan and rowspan attributes) is the same for each row.

Examples

Incorrect: second row has more columns than the first

The first row defines 1 column, but the second row has 2 columns.

<table>
  <tr>
    <td>Liza</td>
  </tr>
  <tr>
    <td>Jimmy</td>
    <td>14</td>
  </tr>
</table>

Fixed: add missing cells to the first row

Make both rows have 2 columns by adding a header or data cell to the first row.

<table>
  <tr>
    <th>Name</th>
    <th>Age</th>
  </tr>
  <tr>
    <td>Jimmy</td>
    <td>14</td>
  </tr>
</table>

Fixed: use colspan if the first row intentionally spans the full width

If the first row is meant to be a single spanning header, use colspan to match the total column count.

<table>
  <tr>
    <th colspan="2">Student Info</th>
  </tr>
  <tr>
    <td>Jimmy</td>
    <td>14</td>
  </tr>
</table>

Incorrect: later row exceeds column count with extra cells

<table>
  <tr>
    <th>Name</th>
    <th>Age</th>
  </tr>
  <tr>
    <td>Liza</td>
    <td>12</td>
    <td>Extra cell</td>
  </tr>
</table>

Fixed: remove the extra cell or expand the header row

<table>
  <tr>
    <th>Name</th>
    <th>Age</th>
    <th>Notes</th>
  </tr>
  <tr>
    <td>Liza</td>
    <td>12</td>
    <td>Extra cell</td>
  </tr>
</table>

Incorrect: colspan mismatch causes inconsistent totals

The first row spans 3 columns total (1 + colspan="2"), but the second row has 4 cells.

<table>
  <tr>
    <th>Name</th>
    <th colspan="2">Contact</th>
  </tr>
  <tr>
    <td>Liza</td>
    <td>liza@example.com</td>
    <td>555-0100</td>
    <td>Room 4</td>
  </tr>
</table>

Fixed: adjust colspan or cell count so all rows match

<table>
  <tr>
    <th>Name</th>
    <th colspan="3">Contact &amp; Location</th>
  </tr>
  <tr>
    <td>Liza</td>
    <td>liza@example.com</td>
    <td>555-0100</td>
    <td>Room 4</td>
  </tr>
</table>

When debugging this issue, count the effective columns for each row by adding up the number of cells plus any additional columns contributed by colspan values (a colspan="3" cell counts as 3 columns). Every row in the table must produce the same total.

A table row was X columns wide, which is less than the column count established by the first row (Y).

HTML tables establish their column count based on the first row. When subsequent rows have fewer <td> or <th> cells than that initial row defines, the table structure becomes invalid. Browsers will typically render these tables by leaving blank space where the missing cells should be, but the underlying markup is malformed.

This matters for several important reasons. Screen readers and other assistive technologies rely on a consistent table structure to navigate cells and associate data with the correct headers. When cells are missing, users who depend on these tools may receive confusing or incorrect information. Additionally, inconsistent row widths can lead to unpredictable layout behavior across different browsers and make your table markup harder to maintain.

When counting columns, remember that the colspan attribute contributes to the total. A single <td colspan="3"> counts as three columns, not one. So if your first row has two <td> elements and one of them has colspan="2", the table is three columns wide, and every other row must also account for three columns.

How to Fix

There are several approaches depending on your intent:

Add the missing cells — If data was accidentally omitted, add the appropriate <td> or <th> elements to complete the row.
Use colspan — If a cell should intentionally span multiple columns, use the colspan attribute so the total column count matches.
Add empty cells — If a cell simply has no content, include an empty <td></td> to maintain the structure.

Examples

❌ Row with fewer columns than the first row

The first row establishes a 3-column table, but the second row only has 2 cells:

<table>
  <tr>
    <td>Name</td>
    <td>Role</td>
    <td>Department</td>
  </tr>
  <tr>
    <td>Alice</td>
    <td>Engineer</td>
  </tr>
</table>

✅ Fix by adding the missing cell

<table>
  <tr>
    <td>Name</td>
    <td>Role</td>
    <td>Department</td>
  </tr>
  <tr>
    <td>Alice</td>
    <td>Engineer</td>
    <td>Product</td>
  </tr>
</table>

✅ Fix by using colspan to span remaining columns

If the second row intentionally has fewer logical cells, use colspan so the total still matches:

<table>
  <tr>
    <td>Name</td>
    <td>Role</td>
    <td>Department</td>
  </tr>
  <tr>
    <td>Alice</td>
    <td colspan="2">Engineer — General</td>
  </tr>
</table>

✅ Fix by adding an empty cell

If there’s simply no data for that column, include an empty cell:

<table>
  <tr>
    <td>Name</td>
    <td>Role</td>
    <td>Department</td>
  </tr>
  <tr>
    <td>Alice</td>
    <td>Engineer</td>
    <td></td>
  </tr>
</table>

❌ Mismatch caused by colspan in the first row

Be careful when the first row uses colspan, as it increases the effective column count:

<table>
  <tr>
    <td colspan="2">Full Name</td>
    <td>Role</td>
  </tr>
  <tr>
    <td>Alice</td>
    <td>Engineer</td>
  </tr>
</table>

Here the first row spans 3 columns (2 + 1), but the second row only has 2 cells.

✅ Fix by matching the full column count

<table>
  <tr>
    <td colspan="2">Full Name</td>
    <td>Role</td>
  </tr>
  <tr>
    <td>Alice</td>
    <td>Smith</td>
    <td>Engineer</td>
  </tr>
</table>

Almost standards mode doctype. Expected “<!DOCTYPE html>”.

When a browser encounters a document, the doctype declaration is the first thing it reads to determine which rendering mode to use. There are three modes: quirks mode, almost standards mode, and full standards mode. Almost standards mode was introduced as a transitional step — it renders pages mostly according to standards but retains a few legacy behaviors, particularly around how images inside table cells are laid out. Doctypes that trigger this mode include:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Frameset//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-frameset.dtd">

These doctypes were common during the XHTML and HTML 4 era but are now considered obsolete. The W3C HTML Validator (Nu HTML Checker) is designed for HTML5 documents and expects the simple <!DOCTYPE html> declaration.

Why this matters

Standards compliance: The HTML Living Standard (maintained by WHATWG) specifies <!DOCTYPE html> as the only valid doctype. Using anything else means your document does not conform to the current standard.
Rendering consistency: While almost standards mode is close to full standards mode, the subtle differences — especially around vertical sizing of table cell images — can lead to unexpected layout behavior across browsers.
Future-proofing: Legacy doctypes tie your pages to outdated specifications. Modern tooling, linters, and validators all expect HTML5, and maintaining an old doctype can mask other issues.
Simplicity: The HTML5 doctype is short, easy to remember, and case-insensitive. There’s no reason to use a longer, more complex declaration.

How to fix it

Replace the legacy doctype on the very first line of your HTML document with <!DOCTYPE html>. No public identifier, no system identifier, and no DTD URL is needed. After making the change, review your page for any layout shifts — in most cases there will be none, but pages that relied on the subtle almost-standards-mode behavior around images in table cells may need a small CSS adjustment (such as setting img { display: block; } or img { vertical-align: bottom; } on affected images).

Examples

❌ Legacy doctype triggering almost standards mode

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
  "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
  <head>
    <title>My Page</title>
  </head>
  <body>
    <h1>Hello, world!</h1>
  </body>
</html>

❌ HTML 4.01 Transitional doctype

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
  "http://www.w3.org/TR/html4/loose.dtd">
<html>
  <head>
    <title>My Page</title>
  </head>
  <body>
    <h1>Hello, world!</h1>
  </body>
</html>

✅ Correct HTML5 doctype

<!DOCTYPE html>
<html lang="en">
  <head>
    <meta charset="utf-8">
    <title>My Page</title>
  </head>
  <body>
    <h1>Hello, world!</h1>
  </body>
</html>

The HTML5 doctype is the shortest possible doctype that triggers full standards mode in all modern browsers. It works regardless of case (<!DOCTYPE html>, <!doctype html>, or <!Doctype Html> are all equivalent), though lowercase or the conventional mixed-case form shown above is recommended for consistency.

An “aria-disabled” attribute whose value is “true” should not be specified on an “a” element that has an “href” attribute.

The core problem is that aria-disabled="true" is purely an accessibility hint — it communicates a disabled state to assistive technologies like screen readers, but it has no effect on the actual behavior of the element. When an a element has an href attribute, the browser treats it as a valid hyperlink regardless of any ARIA attributes. Users can still click it, follow it via keyboard navigation, and navigate to its destination. This mismatch between the announced state (“disabled”) and actual behavior (“fully functional link”) creates a confusing and misleading experience, particularly for users of assistive technologies.

The W3C validator flags this combination because it violates the principle that ARIA states should accurately reflect an element’s true interactive state. A link that claims to be disabled but still works undermines user trust and can cause real usability problems.

Why this matters

Accessibility: Screen readers will announce the link as disabled, but users who activate it will be unexpectedly navigated away. This is disorienting and violates WCAG guidance on predictable behavior.
Standards compliance: The HTML specification and ARIA in HTML requirements discourage or disallow this combination because it produces an unreliable user experience.
Browser behavior: No browser will disable a link just because aria-disabled="true" is present. The href attribute always makes the a element an active hyperlink.

How to fix it

You have two main approaches depending on your intent:

The link should be active: Remove aria-disabled="true" and keep the href. If the link works, don’t mark it as disabled.
The link should be disabled: Remove the href attribute. Without href, the a element becomes a placeholder link that is not interactive. You can then use aria-disabled="true" to communicate the disabled state, tabindex="-1" to remove it from the keyboard tab order, and CSS to style it as visually disabled. You should also add JavaScript to prevent activation if needed.

Examples

Incorrect

This triggers the validation error because aria-disabled="true" conflicts with the presence of href:

<a href="/dashboard" aria-disabled="true">Go to Dashboard</a>

Correct — Keep the link active

If the link should function normally, simply remove the aria-disabled attribute:

<a href="/dashboard">Go to Dashboard</a>

Correct — Disable the link

If the link should be non-actionable (e.g., a navigation item the user doesn’t currently have access to), remove the href attribute and use ARIA and CSS to communicate the disabled state:

<a aria-disabled="true" tabindex="-1" role="link" class="link-disabled">Go to Dashboard</a>

.link-disabled {
  color: #6c757d;
  cursor: not-allowed;
  pointer-events: none;
  text-decoration: none;
}

In this approach:

Removing href ensures the link is not actionable by the browser.
aria-disabled="true" tells assistive technologies the element is disabled.
tabindex="-1" removes the element from the keyboard tab order so users can’t Tab to it.
role="link" preserves the link semantics so screen readers still identify it as a link (an a without href loses its implicit link role).
The CSS provides a visual indication that the element is disabled, with pointer-events: none preventing mouse clicks and cursor: not-allowed giving a visual cue on hover.

Correct — Use a button instead

If the “link” triggers an action rather than navigating somewhere, consider using a button element instead. Buttons natively support the disabled attribute:

<button type="button" disabled>Perform Action</button>

This is the simplest and most robust solution when the element doesn’t need to be a link. The disabled attribute is natively understood by browsers and assistive technologies without any ARIA workarounds.

An element with “role=cell” must be contained in, or owned by, an element with “role=row”.

role
cell

The ARIA specification defines a strict ownership hierarchy for table-related roles. A role="cell" element must be “owned by” an element with role="row", meaning it must either be a direct child of that element or be associated with it via the aria-owns attribute. This mirrors how native HTML tables work: a <td> element must live inside a <tr> element. When you use ARIA roles to build custom table structures from non-table elements like <div> or <span>, you are responsible for maintaining this same hierarchy manually.

The expected nesting order for an ARIA table is:

role="table" — the outermost container
role="rowgroup" (optional) — groups rows together, like <thead>, <tbody>, or <tfoot>
role="row" — a single row of cells
role="cell" or role="columnheader" / role="rowheader" — individual cells

When a role="cell" element is placed directly inside a role="table" or any other container that isn’t role="row", screen readers lose the ability to announce row and column positions. Users who rely on table navigation shortcuts (such as moving between cells with arrow keys) will find the table unusable. This is not just a validation concern — it directly impacts whether people can access your content.

This issue commonly arises when developers add intermediate wrapper elements for styling purposes and accidentally break the required parent-child relationship, or when they forget to assign role="row" to a container element.

How to Fix

Ensure every element with role="cell" is a direct child of an element with role="row". If you have wrapper elements between the row and cell for layout or styling, either remove them, move the role assignments, or use aria-owns on the row element to explicitly claim ownership of the cells.

Examples

Incorrect — Cell Without a Row Parent

This triggers the validation error because role="cell" elements are direct children of the role="table" container, with no role="row" in between.

<div role="table">
  <div role="cell">Name</div>
  <div role="cell">Email</div>
</div>

Incorrect — Intermediate Wrapper Breaking Ownership

Here, a styling wrapper sits between the row and its cells. Since the <div> without a role is not a role="row", the cells are not properly owned.

<div role="table">
  <div role="row">
    <div class="cell-wrapper">
      <div role="cell">Row 1, Cell 1</div>
      <div role="cell">Row 1, Cell 2</div>
    </div>
  </div>
</div>

Correct — Cells Directly Inside Rows

Each role="cell" is a direct child of a role="row" element, forming a valid ARIA table structure.

<div role="table" aria-label="Team members">
  <div role="row">
    <div role="columnheader">Name</div>
    <div role="columnheader">Email</div>
  </div>
  <div role="row">
    <div role="cell">Alice</div>
    <div role="cell">alice@example.com</div>
  </div>
  <div role="row">
    <div role="cell">Bob</div>
    <div role="cell">bob@example.com</div>
  </div>
</div>

Correct — Using Rowgroups

You can optionally group rows with role="rowgroup", similar to <thead> and <tbody>. The cells still must be direct children of their rows.

<div role="table" aria-label="Quarterly results">
  <div role="rowgroup">
    <div role="row">
      <div role="columnheader">Quarter</div>
      <div role="columnheader">Revenue</div>
    </div>
  </div>
  <div role="rowgroup">
    <div role="row">
      <div role="cell">Q1</div>
      <div role="cell">$10,000</div>
    </div>
    <div role="row">
      <div role="cell">Q2</div>
      <div role="cell">$12,500</div>
    </div>
  </div>
</div>

Correct — Using Native HTML Instead

If your content is genuinely tabular data, consider using native HTML table elements instead of ARIA roles. Native tables have built-in semantics and require no additional role attributes.

<table>
  <tr>
    <th>Name</th>
    <th>Email</th>
  </tr>
  <tr>
    <td>Alice</td>
    <td>alice@example.com</td>
  </tr>
</table>

Native HTML tables are always preferable when they suit your use case. The first rule of ARIA is: if you can use a native HTML element that already has the semantics you need, use it instead of adding ARIA roles to a generic element.

An element with “role=columnheader” must be contained in, or owned by, an element with “role=row”.

The ARIA specification defines a strict ownership hierarchy for table-related roles. A columnheader represents a header cell for a column, analogous to a <th> element in native HTML. For assistive technologies like screen readers to correctly announce column headers and associate them with the data cells beneath them, the columnheader must exist within a row context. The required structure is:

An element with role="table", role="grid", or role="treegrid" serves as the container.
Inside it, elements with role="rowgroup" (optional) or role="row" organize the rows.
Each role="row" element contains one or more elements with role="columnheader", role="rowheader", or role="cell".

When a role="columnheader" element is placed directly inside a role="table" or role="grid" container — or any other element that is not role="row" — the validator raises this error. Without the row wrapper, screen readers cannot navigate the table structure properly. Users who rely on assistive technology may hear disjointed content or miss the column headers entirely, making the data table unusable.

The best practice, whenever feasible, is to use native HTML table elements (<table>, <thead>, <tr>, <th>, <td>). These carry implicit ARIA roles and establish the correct ownership relationships automatically, eliminating this entire category of errors. Only use ARIA table roles when you genuinely cannot use native table markup — for example, when building a custom grid widget with non-table elements for layout reasons.

Examples

Incorrect: columnheader not inside a row

In this example, the columnheader elements are direct children of the table container, with no role="row" wrapper:

<div role="table" aria-label="Employees">
  <div role="columnheader">Name</div>
  <div role="columnheader">Department</div>
  <div role="row">
    <div role="cell">Alice</div>
    <div role="cell">Engineering</div>
  </div>
</div>

Correct: columnheader inside a row

Wrapping the column headers in an element with role="row" fixes the issue:

<div role="table" aria-label="Employees">
  <div role="row">
    <div role="columnheader">Name</div>
    <div role="columnheader">Department</div>
  </div>
  <div role="row">
    <div role="cell">Alice</div>
    <div role="cell">Engineering</div>
  </div>
</div>

Correct: Using rowgroup for additional structure

You can optionally use role="rowgroup" to separate headers from body rows, similar to <thead> and <tbody>. The columnheader elements must still be inside a row:

<div role="table" aria-label="Employees">
  <div role="rowgroup">
    <div role="row">
      <div role="columnheader">Name</div>
      <div role="columnheader">Department</div>
    </div>
  </div>
  <div role="rowgroup">
    <div role="row">
      <div role="cell">Alice</div>
      <div role="cell">Engineering</div>
    </div>
  </div>
</div>

Best practice: Use native table elements

Native HTML tables have built-in semantics that make ARIA roles unnecessary. A <th> inside a <tr> already behaves as a columnheader inside a row:

<table>
  <thead>
    <tr>
      <th>Name</th>
      <th>Department</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>Alice</td>
      <td>Engineering</td>
    </tr>
  </tbody>
</table>

This approach is simpler, more robust across browsers and assistive technologies, and avoids the risk of ARIA misuse. Reserve ARIA table roles for situations where native table markup is not an option.

An element with “role=listitem” must be contained in, or owned by, an element with “role=list” or “role=group”.

The WAI-ARIA specification defines strict ownership requirements for certain roles. The listitem role is one such role — it must be “owned by” an element with role="list" or role="group". “Owned by” means the listitem must be either a direct DOM child of the owning element, or explicitly associated with it via the aria-owns attribute.

This matters because screen readers and other assistive technologies rely on the accessibility tree to convey structure to users. When a screen reader encounters a properly structured list, it announces something like “list, 3 items” and lets the user navigate between items. Without the parent role="list", the individual items lose their list context — users won’t know how many items exist, where the list begins and ends, or that the items are related at all.

In most cases, the simplest and most robust fix is to use native HTML list elements (<ul> or <ol> with <li> children) instead of ARIA roles. Native elements have built-in semantics that don’t require additional attributes. Only use ARIA roles when native elements aren’t feasible — for example, when building a custom component where the visual layout prevents using standard list markup.

Examples

Incorrect: listitem without a parent list

These listitem elements are not contained within a role="list" or role="group" parent, so the validator reports an error.

<div role="listitem">Apples</div>
<div role="listitem">Bananas</div>
<div role="listitem">Cherries</div>

Correct: wrapping items in role="list"

Adding a parent container with role="list" establishes the required ownership relationship.

<div role="list">
  <div role="listitem">Apples</div>
  <div role="listitem">Bananas</div>
  <div role="listitem">Cherries</div>
</div>

Correct: using native HTML list elements

Native <ul> and <li> elements implicitly carry the list and listitem roles without any ARIA attributes. This is the preferred approach.

<ul>
  <li>Apples</li>
  <li>Bananas</li>
  <li>Cherries</li>
</ul>

Correct: using role="group" for nested sublists

The role="group" container is appropriate for grouping a subset of list items within a larger list, such as a nested sublist.

<div role="list">
  <div role="listitem">Fruits
    <div role="group">
      <div role="listitem">Apples</div>
      <div role="listitem">Bananas</div>
    </div>
  </div>
  <div role="listitem">Vegetables
    <div role="group">
      <div role="listitem">Carrots</div>
      <div role="listitem">Peas</div>
    </div>
  </div>
</div>

Note that role="group" should itself be nested inside a role="list" — it doesn’t replace the top-level list container, but rather serves as an intermediate grouping mechanism within one.

Correct: using aria-owns for non-descendant ownership

If the DOM structure prevents you from nesting the items directly inside the list container, you can use aria-owns to establish the relationship programmatically.

<div role="list" aria-owns="item-1 item-2 item-3"></div>

<!-- These items live elsewhere in the DOM -->

<div role="listitem" id="item-1">Apples</div>
<div role="listitem" id="item-2">Bananas</div>
<div role="listitem" id="item-3">Cherries</div>

This approach should be used sparingly, as it can create confusion if the visual order doesn’t match the accessibility tree order. Whenever possible, restructure your HTML so the items are actual descendants of the list container.

🇪🇺 EU-Hosted

Made in Europe.
Built for the open web.

Built by Lighthouses SCP, a Spanish company, with servers in Paris, Amsterdam and Frankfurt. Your data stays in the EU.

Based in Spain

EU Data Residency

Open Source Standards

€7 / 7 days

Pro Trial

Full Pro access. Cancel anytime.

Start Pro Trial →

Join teams across 40+ countries