HTML Guides

Bad value “X” for attribute “rel” on element “Y”: The string “X” is not an absolute URL.

The rel attribute defines the relationship between the current document and a linked resource. The HTML specification maintains a set of recognized keyword values for this attribute, and the allowed keywords vary depending on which element the attribute appears on. For example, stylesheet is valid on <link> but not on <a>, while nofollow is valid on <a> and <form> but not on <link>.

When the validator encounters a rel value that isn't a recognized keyword, it checks whether the value is a valid absolute URL. This is because the HTML specification allows custom link types to be defined using absolute URLs as identifiers (similar to how XML namespaces work). If the value is neither a recognized keyword nor a valid absolute URL, the validator raises this error.

Common causes of this error include:

Typos in standard keywords — for example, rel="styelsheet" or rel="no-follow" instead of the correct rel="stylesheet" or rel="nofollow".
Using non-standard or invented values — such as rel="custom" or rel="external", which aren't part of the HTML specification's recognized set.
Using relative URLs as custom link types — for example, rel="my-custom-type" instead of a full URL like rel="https://example.com/my-custom-type".

This matters because browsers and other user agents rely on recognized rel values to determine how to handle linked resources. An unrecognized value will simply be ignored, which could mean your stylesheet doesn't load, your prefetch hint doesn't work, or search engines don't respect your intended link relationship. Using correct values ensures predictable behavior across all browsers and tools.

Examples

Incorrect: Misspelled keyword

The validator reports that styleshet is not a recognized keyword and is not an absolute URL.

Correct: Fixed spelling

Incorrect: Non-standard keyword on an anchor

<a href="https://example.com" rel="external">Visit Example</a>

The value external is not a standard rel keyword in the HTML specification, so the validator flags it.

Correct: Using a recognized keyword

<a href="https://example.com" rel="noopener">Visit Example</a>

Incorrect: Relative URL as a custom link type

Correct: Absolute URL as a custom link type

If you genuinely need a custom relationship type, provide a full absolute URL:

Correct: Common valid `rel` values

Here are some frequently used standard rel keywords with their appropriate elements:

<a href="https://example.com" rel="nofollow">Sponsored link</a>

<a href="https://example.com" target="_blank" rel="noopener noreferrer">External site</a>

Multiple `rel` values

You can specify multiple space-separated rel values. Each one must individually be either a recognized keyword or a valid absolute URL:

<a href="https://example.com" target="_blank" rel="noopener noreferrer">External</a>

<a href="https://example.com" target="_blank" rel="noopener popup">External</a>

To resolve this error, consult the MDN rel attribute reference for the full list of recognized keywords and which elements support them. If your value isn't on the list, either replace it with the correct standard keyword or use a complete absolute URL to define your custom link type.

The “aria-label” attribute must not be specified on any “menu-item” element unless the element has a “role” value other than “caption”, “code”, “deletion”, “emphasis”, “generic”, “insertion”, “paragraph”, “presentation”, “strong”, “subscript”, or “superscript”.

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

The WAI-ARIA specification defines a strict ownership model for tab-related roles. An element with role="tab" controls the visibility of an associated role="tabpanel" element, and tabs are expected to be grouped within a tablist. This relationship is how assistive technologies like screen readers understand and communicate the tab interface pattern to users — for example, announcing "tab 2 of 4" when focus moves between tabs.

When a tab is not contained in or owned by a tablist, screen readers cannot determine how many tabs exist in the group, which tab is currently selected, or how to navigate between them. This fundamentally breaks the accessibility of the tab interface, making it confusing or unusable for people who rely on assistive technologies.

There are two ways to establish the required relationship:

Direct containment: Place the role="tab" elements as direct children of the role="tablist" element. This is the most common and straightforward approach.
Using aria-owns: If the DOM structure prevents direct nesting, add aria-owns to the tablist element with a space-separated list of id values referencing each tab. This tells assistive technologies that the tablist owns those tabs even though they aren't direct children in the DOM.

Examples

Incorrect: tab outside of a tablist

In this example, the role="tab" buttons are siblings of the tablist rather than children of it, which triggers the validation error.

First Tab

</button>

Second Tab

</button>

</div>

Correct: tabs as direct children of tablist

The simplest fix is to place the role="tab" elements directly inside the role="tablist" element.

First Tab

</button>

Second Tab

</button>

</div>

<p>Content for the first panel</p>

</div>

<p>Content for the second panel</p>

</div>

Correct: using aria-owns when DOM nesting isn't possible

If your layout or framework makes it difficult to nest the tabs directly inside the tablist, you can use aria-owns to establish the relationship programmatically.

First Tab

</button>

Second Tab

</button>

</div>

<p>Content for the first panel</p>

</div>

<p>Content for the second panel</p>

</div>

Additional notes

Each role="tab" element should use aria-selected to indicate which tab is active ("true") and which are not ("false").
Use aria-controls on each tab to reference the id of its associated tabpanel.
Use aria-labelledby on each tabpanel to point back to its controlling tab.
Set tabindex="0" on the active tab and tabindex="-1" on inactive tabs to support keyboard navigation with arrow keys within the tablist.
Always include an aria-label or aria-labelledby on the tablist to give it an accessible name.

The “gcse:search” element is a completely-unknown element that is not allowed anywhere in any HTML content.

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:

Correct: `as` attribute included

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

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:

Full document example

<!DOCTYPE html>

<head>

<title>Preload Example</title>

</head>

<body>

<h1>Hello, world!</h1>

</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.

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="columnheader">Department</div>

<div role="cell">Alice</div>

<div role="cell">Engineering</div>

</div>

Correct: `columnheader` inside a `row`

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

<div role="columnheader">Department</div>

</div>

<div role="cell">Alice</div>

<div role="cell">Engineering</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="columnheader">Department</div>

</div>

<div role="cell">Alice</div>

<div role="cell">Engineering</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>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.

Bad value X for attribute “src” on element “img”: Percentage ("%") is not followed by two hexadecimal digits.

url encoding

In URLs, special characters that aren't part of the standard allowed set must be represented using percent-encoding (also called URL encoding). This works by replacing the character with a % followed by two hexadecimal digits representing its byte value — for example, a space becomes %20, and an ampersand becomes %26. Because % itself serves as the escape character in this scheme, any bare % that isn't followed by two hexadecimal digits creates an ambiguous, invalid URL.

When the W3C validator encounters a src attribute containing a % not followed by two valid hex digits, it cannot determine the intended character and reports the error. This issue typically arises in two scenarios:

A literal percent sign in the URL — for instance, a query parameter like ?width=48% where the % is meant as an actual percent symbol. The % must be encoded as %25.
Incomplete or corrupted percent-encoding — such as %2 instead of %20, or %GZ where the characters after % aren't valid hexadecimal digits (only 0–9 and A–F/a–f are valid).

Why this matters

Browser inconsistency: While many browsers try to handle malformed URLs gracefully, behavior varies. Some browsers may misinterpret the intended resource path, leading to broken images or unexpected requests.
Standards compliance: The URL Living Standard and RFC 3986 define strict rules for percent-encoding. Invalid URLs violate these standards.
Reliability: Proxies, CDNs, and server-side software may reject or misroute requests with malformed URLs, causing images to fail to load in certain environments even if they work in your local browser.

How to fix it

Find every bare % in the URL that isn't followed by two hexadecimal digits.
If the % is meant as a literal percent sign, replace it with %25.
If the % is part of a broken encoding sequence (e.g., %2 or %GH), correct it to the intended two-digit hex code (e.g., %20 for a space).
Use proper URL encoding functions in your language or framework (e.g., encodeURIComponent() in JavaScript, urlencode() in PHP) when building URLs dynamically, rather than constructing them by hand.

Examples

Literal percent sign not encoded

Incomplete percent-encoding sequence

Non-hexadecimal characters after percent sign

Multiple encoding issues in one URL

Building URLs safely with JavaScript

When generating src values in code, use encodeURIComponent() to handle special characters automatically:

const label = "100%";

const name = "my file.png";

const src = `https://example.com/img?label=${encodeURIComponent(label)}&name=${encodeURIComponent(name)}`;

// Result: "https://example.com/img?label=100%25&name=my%20file.png"

This ensures every special character — including % — is correctly percent-encoded without manual effort.

Bad value X for attribute “href” on element “a”: Illegal character in fragment: space is not allowed.

The fragment portion of a URL (everything after the # symbol) follows the same encoding rules as the rest of the URL — literal space characters are not permitted. When a browser encounters a space in a URL fragment, it may try to correct it automatically, but this behavior is not guaranteed across all browsers and contexts. Relying on browser error-correction leads to fragile links that may break unpredictably.

This issue matters for several reasons. First, it produces invalid HTML that fails W3C validation. Second, fragment navigation (jumping to a specific section of a page) may not work correctly if the browser doesn't auto-correct the space. Third, assistive technologies like screen readers rely on well-formed URLs to announce link destinations accurately. Finally, tools that parse or process HTML programmatically — such as crawlers, link checkers, and content management systems — may misinterpret or reject malformed URLs.

The most common scenario for this error is linking to an id attribute on the same page or another page where the id contains spaces. However, it's worth noting that id values themselves cannot contain spaces in valid HTML (a space in an id would make it multiple invalid tokens). So if you're writing both the link and the target, the best fix is often to correct the id itself by using hyphens or underscores instead of spaces.

How to Fix It

There are two main approaches:

Percent-encode the spaces — Replace each space with %20 in the href value.
Use space-free identifiers — Change the target id to use hyphens or camelCase, then update the fragment to match.

The second approach is strongly preferred because it fixes the root problem and produces cleaner, more readable markup.

Examples

❌ Invalid: Space in the fragment

<a href="https://example.com/page#some term">Go to section</a>

<a href="#my section">Jump to My Section</a>

✅ Fixed: Percent-encode the space

If you cannot control the target id (e.g., linking to an external page), percent-encode the space:

<a href="https://example.com/page#some%20term">Go to section</a>

✅ Better fix: Use a hyphenated `id` and matching fragment

When you control both the link and the target, use a space-free id:

<h2 id="my-section">My Section</h2>

<p>Some content here.</p>

<a href="#my-section">Jump to My Section</a>

❌ Invalid: Space in fragment linking to another page

<a href="/docs/getting-started#quick start guide">Quick Start Guide</a>

✅ Fixed: Matching hyphenated `id`

<h2 id="quick-start-guide">Quick Start Guide</h2>

<a href="/docs/getting-started#quick-start-guide">Quick Start Guide</a>

A note on `id` naming conventions

Since fragment identifiers reference id attributes, adopting a consistent id naming convention avoids this issue entirely. Common patterns include:

All three are valid and will never trigger a space-related validation error in your fragment links.

Bad value “mailto:X>” for attribute “href” on element “a”: Illegal character in scheme data: “<” is not allowed.

Bad value X for attribute “href” on element “a”: Illegal character in query. Y is not allowed.

Bad value for attribute “href” on element “link”: Illegal character in scheme data: X is not allowed.

The “icon” element is a completely-unknown element that is not allowed anywhere in any HTML content.

icon

Bad value X for attribute “href” on element “a”: Illegal character after “tel:”. Space is not allowed.

Bad value X for attribute “href” on element “a”: Illegal character in path segment. “[” is not allowed.

Bad value “X” for attribute “href” on element “a”: Illegal character in scheme data: “<” is not allowed.

Bad value X for attribute “href” on element “a”: Illegal character in scheme data: “[” is not allowed.

Bad value X for attribute “src” on element “iframe”: Illegal character in query. Space is not allowed.

Bad value X for attribute “poster” on element “video”: Illegal character in path segment. “[” is not allowed.

Bad value “X” for attribute “href” on element “a”: Illegal character in query: space is not allowed.

URLs follow strict syntax rules defined by RFC 3986, which does not permit literal space characters anywhere in a URI. When the W3C validator encounters a space in the href attribute of an <a> element — particularly within the query string (the part after the ?) — it flags it as an illegal character.

While most modern browsers will silently fix malformed URLs by encoding spaces for you, relying on this behavior is problematic for several reasons:

Standards compliance: The HTML specification requires that href values contain valid URLs. A space makes the URL syntactically invalid.
Interoperability: Not all user agents, crawlers, or HTTP clients handle malformed URLs the same way. Some may truncate the URL at the first space or reject it entirely.
Accessibility: Screen readers and assistive technologies may struggle to interpret or announce links with invalid URLs.
Link sharing and copy-pasting: If a user copies the link from the source or if the URL is used in an API or redirect, the unencoded space can cause breakage.

To fix this issue, replace every literal space character in the URL with %20. Within query string values, you can also use + as a space encoding (this is the application/x-www-form-urlencoded format commonly used in form submissions). If you're generating URLs dynamically, use your programming language's URL encoding function (e.g., encodeURIComponent() in JavaScript, urlencode() in PHP, or urllib.parse.quote() in Python).

Examples

Incorrect — spaces in the query string

<a href="https://example.com/search?query=hello world&lang=en">Search</a>

The space between hello and world is an illegal character in the URL.

Correct — space encoded as `%20`

<a href="https://example.com/search?query=hello%20world&lang=en">Search</a>

Correct — space encoded as `+` in query string

<a href="https://example.com/search?query=hello+world&lang=en">Search</a>

Using + to represent a space is valid within query strings and is commonly seen in URLs generated by HTML forms.

Incorrect — spaces in the path and query

<a href="https://example.com/my folder/page?name=John Doe">Profile</a>

Correct — all spaces properly encoded

<a href="https://example.com/my%20folder/page?name=John%20Doe">Profile</a>

Generating safe URLs in JavaScript

If you're building URLs dynamically, use encodeURIComponent() for individual parameter values:

const query = "hello world";

const url = "https://example.com/search?query=" + encodeURIComponent(query);

// Result: "https://example.com/search?query=hello%20world"

</script>

Note that encodeURIComponent() encodes spaces as %20, which is safe for use in any part of a URL. Avoid using encodeURI() for query values, as it does not encode certain characters like & and = that may conflict with query string syntax.

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="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>

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="columnheader">Email</div>

</div>

<div role="cell">Alice</div>

<div role="cell">alice@example.com</div>

</div>

<div role="cell">bob@example.com</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="columnheader">Quarter</div>

<div role="columnheader">Revenue</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>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.

Bad value X for attribute “href” on element “a”: Percentage ("%") is not followed by two hexadecimal digits.

url encoding

Percent-encoding (also called URL encoding) is the mechanism defined by RFC 3986 for representing special or reserved characters in URLs. It works by replacing a character with a % sign followed by two hexadecimal digits that correspond to the character's byte value. For example, a space becomes %20, an ampersand becomes %26, and a literal percent sign becomes %25. When a browser or parser encounters % in a URL, it expects the next two characters to be valid hexadecimal digits so it can decode them back to the original character.

If the parser finds a % that is not followed by two hexadecimal digits, it cannot decode the sequence, and the URL is considered invalid. The W3C validator flags this as a bad value for the href attribute.

Common causes

A literal % that wasn't encoded. This is the most frequent cause. For instance, a URL containing a percentage value like 50% in a query string — the % must be written as %25.
Truncated percent-encoded sequences. A sequence like %2 is incomplete because it only has one hex digit instead of two.
Invalid hex characters after %. A sequence like %GZ is invalid because G and Z are not hexadecimal digits (valid hex digits are 0–9 and A–F).
Copy-pasting URLs from non-web sources. URLs pasted from documents, emails, or spreadsheets may contain unencoded special characters.

Why this matters

Broken links. Browsers may interpret the malformed URL differently than intended, leading users to the wrong page or a 404 error.
Standards compliance. The WHATWG URL Standard and the HTML specification require that href values contain valid URLs. Malformed URLs violate these standards.
Accessibility. Screen readers and assistive technologies rely on well-formed URLs to provide accurate navigation information to users.
Interoperability. While some browsers attempt error recovery on malformed URLs, behavior is not guaranteed to be consistent across all browsers and tools.

How to fix it

Encode literal % as %25. If the % is meant to appear as part of the URL's content (e.g., in a query parameter value), replace it with %25.
Complete any truncated sequences. If you intended a percent-encoded character like %20, make sure both hex digits are present.
Use proper URL encoding functions. In JavaScript, use encodeURIComponent() for query parameter values. In server-side languages, use the equivalent encoding function (e.g., urllib.parse.quote() in Python, urlencode() in PHP).

Examples

Literal `%` not encoded

<a href="https://example.com?width=48%">48% width</a>

<a href="https://example.com?width=48%25">48% width</a>

Truncated percent-encoded sequence

<a href="https://example.com/path%2file">Download</a>

<a href="https://example.com/path%2Ffile">Download</a>

Invalid hexadecimal characters

<a href="https://example.com/search?q=%XYdata">Search</a>

<a href="https://example.com/search?q=%25XYdata">Search</a>

Multiple unencoded `%` in a URL

<a href="https://example.com?min=10%&max=90%">Range</a>

<a href="https://example.com?min=10%25&max=90%25">Range</a>

Bad value X for attribute “srcset” on element “img”: Must contain one or more image candidate strings.

srcset
img

The srcset attribute allows you to specify multiple image sources so the browser can choose the most appropriate one based on the user's device characteristics, such as screen resolution or viewport width. When you include a srcset attribute on an <img> element, the HTML specification requires it to contain one or more comma-separated image candidate strings. Each string consists of a URL followed by an optional descriptor — either a width descriptor (e.g., 200w) or a pixel density descriptor (e.g., 2x).

This validation error typically appears when:

The srcset attribute is empty (srcset="")
The srcset attribute contains only whitespace (srcset=" ")
The value contains syntax errors such as missing URLs, invalid descriptors, or incorrect formatting
A templating engine or CMS outputs the attribute with no value

This matters because browsers rely on the srcset value to select the best image to load. An empty or malformed srcset means the browser must fall back entirely to the src attribute, making the srcset attribute pointless. Additionally, invalid markup can cause unexpected behavior across different browsers and undermines standards compliance.

How to fix it

Provide valid image candidate strings. Each entry needs a URL and optionally a width or pixel density descriptor, with entries separated by commas.
Remove the attribute entirely if you don't have multiple image sources to offer. A plain src attribute is perfectly fine on its own.
Check dynamic output. If a CMS or templating system generates the srcset, ensure it conditionally omits the attribute when no responsive image candidates are available, rather than outputting an empty attribute.

Examples

❌ Empty `srcset` attribute

This triggers the error because srcset is present but contains no image candidate strings.

❌ Malformed `srcset` value

This is invalid because each candidate string must include a URL. Descriptors alone are not valid entries.

✅ Using pixel density descriptors

<img

src="/img/photo-400.jpg"

alt="A sunset over the ocean"

srcset="

/img/photo-400.jpg 1x,

/img/photo-800.jpg 2x

">

Each candidate string contains a URL followed by a pixel density descriptor (1x, 2x). The browser picks the best match for the user's display.

✅ Using width descriptors with `sizes`

<img

src="/img/photo-400.jpg"

alt="A sunset over the ocean"

srcset="

/img/photo-400.jpg 400w,

/img/photo-800.jpg 800w,

/img/photo-1200.jpg 1200w

"

sizes="(max-width: 600px) 400px, (max-width: 1000px) 800px, 1200px">

Width descriptors (e.g., 400w) tell the browser the intrinsic width of each image. The sizes attribute then tells the browser how large the image will be displayed at various viewport sizes, allowing it to calculate the best source to download.

✅ Removing `srcset` when not needed

If you only have a single image source, simply omit srcset altogether. The src attribute alone is valid and sufficient.

✅ Single candidate in `srcset`

<img

src="/img/photo.jpg"

alt="A sunset over the ocean"

srcset="/img/photo-highres.jpg 2x">

Even a single image candidate string is valid. Here, the browser will use the high-resolution image on 2x displays and fall back to src otherwise.

The “tabs” element is a completely-unknown element that is not allowed anywhere in any HTML content.

tabs

This document appears to be written in Arabic. Consider adding “dir="rtl"” to the “html” start tag.

The dir attribute specifies the base text direction for the content of an element. When a document is written in a right-to-left language like Arabic, Hebrew, Persian (Farsi), or Urdu, the browser needs to know that text should flow from right to left. Without this attribute, browsers default to left-to-right (ltr) rendering, which can cause a range of problems: text alignment may be incorrect, punctuation can appear in the wrong place, and the overall page layout may look broken or confusing to native readers.

This matters for several important reasons:

Accessibility: Screen readers and other assistive technologies rely on the dir attribute to correctly announce and navigate content. Without it, the reading experience for users relying on these tools may be disorienting or incorrect.
Visual correctness: Elements like lists, tables, form labels, and navigation menus will mirror their layout in RTL mode. Without dir="rtl", these elements default to LTR positioning, which feels unnatural for RTL language speakers.
Bidirectional text handling: Documents often contain mixed-direction content (e.g., Arabic text with embedded English words, numbers, or brand names). The Unicode Bidirectional Algorithm (BiDi) uses the base direction set by dir to correctly resolve the ordering of these mixed runs of text.
Standards compliance: The WHATWG HTML Living Standard recommends that authors set the dir attribute to match the language of the document, and the W3C Internationalization guidelines strongly encourage it for RTL languages.

How to fix it

Add dir="rtl" to your <html> start tag. If you haven't already, also include the appropriate lang attribute for the specific language you're using.

For Arabic:

For Hebrew:

For Persian:

Examples

❌ Missing `dir` attribute on an Arabic document

<!DOCTYPE html>

<head>

<title>مرحبا بالعالم</title>

</head>

<body>

<h1>مرحبا بالعالم</h1>

<p>هذه صفحة تجريبية باللغة العربية.</p>

</body>

</html>

The browser will render this page with a left-to-right base direction. The heading and paragraph text may appear left-aligned, and any mixed-direction content (like embedded numbers or English words) may be ordered incorrectly.

✅ Correct: `dir="rtl"` added to the `<html>` tag

<!DOCTYPE html>

<head>

<title>مرحبا بالعالم</title>

</head>

<body>

<h1>مرحبا بالعالم</h1>

<p>هذه صفحة تجريبية باللغة العربية.</p>

</body>

</html>

Now the browser knows to render the page right-to-left. Text will be right-aligned by default, scroll bars will appear on the left, and the overall layout will feel natural for Arabic readers.

Handling mixed-direction content within a page

If your RTL document contains sections in a left-to-right language, use the dir attribute on individual elements to override the base direction locally:

<p>قام المستخدم بزيارة <span dir="ltr">www.example.com</span> اليوم.</p>

This ensures the URL renders in the correct left-to-right order while the surrounding Arabic text flows right-to-left. Setting dir="rtl" on the <html> element establishes the correct default, and you only need per-element overrides for embedded LTR content.

The “o:p” element is a completely-unknown element that is not allowed anywhere in any HTML content.

Examples

Incorrect: Misspelled keyword

Correct: Fixed spelling

Incorrect: Non-standard keyword on an anchor

Correct: Using a recognized keyword

Incorrect: Relative URL as a custom link type

Correct: Absolute URL as a custom link type

Correct: Common valid rel values

Multiple rel values

HTML Examples

❌ Invalid: aria-label on an element with implicit generic role

✅ Valid: adding an explicit role that supports aria-label

Examples

Incorrect: tab outside of a tablist

Correct: tabs as direct children of tablist

Correct: using aria-owns when DOM nesting isn't possible

Additional notes

HTML examples

Invalid: namespaced <gcse:search> element

Valid: div with the gcse-search class

Common as Values

Examples

Incorrect: Missing as attribute

Correct: as attribute included

Note on fonts and crossorigin

Full document example

Examples

Incorrect: columnheader not inside a row

Correct: columnheader inside a row

Correct: Using rowgroup for additional structure

Best practice: Use native table elements

Why this matters

How to fix it

Examples

Literal percent sign not encoded

Incomplete percent-encoding sequence

Non-hexadecimal characters after percent sign

Multiple encoding issues in one URL

Building URLs safely with JavaScript

How to Fix It

Examples

❌ Invalid: Space in the fragment

✅ Fixed: Percent-encode the space

✅ Better fix: Use a hyphenated id and matching fragment

❌ Invalid: Space in fragment linking to another page

✅ Fixed: Matching hyphenated id

A note on id naming conventions

HTML examples

Incorrect

Correct

HTML examples

Invalid: raw illegal characters in the query string

Valid: percent-encoded characters

Examples

Invalid: unencoded characters in href

Valid: percent-encoded URL

Invalid: unresolved template syntax

Valid: resolved or corrected URL

HTML examples

Invalid: using the <icon> element

Valid: using a <link> element for a favicon

Valid: displaying an icon inline with <img>

Valid: displaying an icon inline with <span> and CSS

Invalid example

Valid examples

HTML examples

Invalid: square brackets in the URL

Valid: percent-encoded square brackets

Example with the issue

How to fix it

How to fix it

Examples

Invalid: square brackets in a mailto URL

Fixed: remove the brackets

Invalid: square brackets in a query string

Fixed: percent-encode the brackets

Invalid: unprocessed template syntax in rendered HTML

Fixed: ensure the template renders a valid URL

HTML examples

Correct: Common valid `rel` values

Multiple `rel` values

❌ Invalid: `aria-label` on an element with implicit `generic` role

✅ Valid: adding an explicit `role` that supports `aria-label`

Invalid: namespaced `<gcse:search>` element

Valid: div with the `gcse-search` class

Common `as` Values

Incorrect: Missing `as` attribute

Correct: `as` attribute included

Note on fonts and `crossorigin`

Incorrect: `columnheader` not inside a `row`

Correct: `columnheader` inside a `row`

Correct: Using `rowgroup` for additional structure

✅ Better fix: Use a hyphenated `id` and matching fragment

✅ Fixed: Matching hyphenated `id`

A note on `id` naming conventions

Invalid: using the `<icon>` element

Valid: using a `<link>` element for a favicon

Valid: displaying an icon inline with `<img>`

Valid: displaying an icon inline with `<span>` and CSS

Valid: space encoded as `%20`

Correct — space encoded as `%20`

Correct — space encoded as `+` in query string

Literal `%` not encoded

Multiple unencoded `%` in a URL

❌ Empty `srcset` attribute

❌ Malformed `srcset` value

✅ Using width descriptors with `sizes`

✅ Removing `srcset` when not needed

✅ Single candidate in `srcset`

Invalid: unknown `<tabs>` element

❌ Missing `dir` attribute on an Arabic document

✅ Correct: `dir="rtl"` added to the `<html>` tag

Validate at scale.
Ship accessible websites, faster.