HTML Guides

Understanding the Issue

MIME types follow a specific format: a type and a subtype separated by a forward slash, such as text/javascript or application/json. When the W3C validator encounters type="rocketlazyloadscript" on a <script> element, it flags it because this value has no slash and no subtype — it doesn’t conform to the MIME type syntax defined in the HTML specification.

The value rocketlazyloadscript is intentionally set by the WP Rocket WordPress caching and performance plugin. WP Rocket changes the type attribute of <script> elements from text/javascript (or removes the default) and replaces it with this custom value. This prevents the browser from executing the script immediately on page load. WP Rocket’s JavaScript then swaps the type back to a valid value when the script should actually be loaded, achieving a lazy-loading effect that can improve page performance.

Why This Is Flagged

The HTML specification states that if the type attribute is present on a <script> element, its value must be one of the following:

• A valid JavaScript MIME type (e.g., text/javascript) — indicating the script should be executed.
• The string module — indicating the script is a JavaScript module.
• Any other valid MIME type that is not a JavaScript MIME type — indicating a data block that the browser should not execute.

Since rocketlazyloadscript is not a valid MIME type at all (it lacks the type/subtype structure), it fails validation. While browsers will simply ignore scripts with unrecognized type values (which is exactly what WP Rocket relies on), the markup itself is technically non-conforming.

How to Fix It

Because this value is generated by a plugin rather than authored manually, your options are:

1. Configure WP Rocket to exclude specific scripts — In WP Rocket’s settings under “File Optimization,” you can exclude individual scripts from the “Delay JavaScript execution” feature. This prevents WP Rocket from modifying their type attribute.

2. Disable delayed JavaScript execution entirely — If W3C compliance is critical, you can turn off the “Delay JavaScript execution” option in WP Rocket. This eliminates the validation errors but sacrifices the performance benefit.

3. Accept the validation errors — WP Rocket acknowledges these errors in their documentation and considers them an expected side effect of their optimization technique. Since browsers handle the non-standard type gracefully (by not executing the script), there is no functional or accessibility issue. The errors are purely a standards compliance concern.

Examples

Invalid: Non-standard type value (generated by WP Rocket)

<script type="rocketlazyloadscript" src="/js/analytics.js"></script>

The validator reports: Bad value “rocketlazyloadscript” for attribute “type” on element “script”: Subtype missing.

Valid: Standard type attribute

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

Valid: Omitting the type attribute entirely

Since text/javascript is the default for <script> elements in HTML5, the type attribute can be omitted entirely:

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

Valid: Using a module script

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

Valid: Using a data block with a proper MIME type

If you need a non-executed data block, use a valid MIME type that isn’t a JavaScript type:

<script type="application/json" id="config">
  {"lazy": true, "threshold": 200}
</script>

The rowgroup role represents a group of rows within a tabular structure — similar to what <thead>, <tbody>, or <tfoot> provide in a native HTML <table>. According to the ARIA specification, the rowgroup role should be used on elements that serve as structural containers for rows within a grid, table, or treegrid. A <header> element is not appropriate for this role because it carries its own strong semantic meaning (typically banner or a sectioning header), and overriding it with role="rowgroup" creates a conflict that the W3C validator flags.

This matters for several reasons. First, assistive technologies rely on correct role assignments to convey the structure of a page. When a <header> element is given role="rowgroup", screen readers receive contradictory signals about what the element represents, which can confuse users. Second, the HTML specification restricts which ARIA roles can be applied to certain elements — the <header> element does not allow rowgroup as a valid role override.

To fix this issue, you have two main options:

1. Replace the <header> element with a <div> — since <div> has no implicit ARIA role, it freely accepts role="rowgroup".
2. Use native HTML table elements — replace the custom ARIA table structure with <table>, <thead>, <tbody>, <tr>, <th>, and <td>, which provide the correct semantics without requiring any ARIA roles.

Examples

❌ Incorrect: role="rowgroup" on a <header> element

<div role="table" aria-label="Quarterly Sales">
  <header role="rowgroup">
    <div role="row">
      <span role="columnheader">Quarter</span>
      <span role="columnheader">Revenue</span>
    </div>
  </header>
  <div role="rowgroup">
    <div role="row">
      <span role="cell">Q1</span>
      <span role="cell">$1.2M</span>
    </div>
  </div>
</div>

The validator reports Bad value “rowgroup” for attribute “role” on element “header” because <header> cannot accept the rowgroup role.

✅ Fix option 1: Use a <div> instead of <header>

<div role="table" aria-label="Quarterly Sales">
  <div role="rowgroup">
    <div role="row">
      <span role="columnheader">Quarter</span>
      <span role="columnheader">Revenue</span>
    </div>
  </div>
  <div role="rowgroup">
    <div role="row">
      <span role="cell">Q1</span>
      <span role="cell">$1.2M</span>
    </div>
  </div>
</div>

A <div> is semantically neutral, so role="rowgroup" is perfectly valid on it.

✅ Fix option 2: Use native HTML table elements

<table>
  <caption>Quarterly Sales</caption>
  <thead>
    <tr>
      <th>Quarter</th>
      <th>Revenue</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>Q1</td>
      <td>$1.2M</td>
    </tr>
  </tbody>
</table>

Native table elements like <thead> and <tbody> implicitly carry the rowgroup role, so no ARIA attributes are needed at all. This approach is generally preferred because it provides the best accessibility support out of the box and results in cleaner, more maintainable markup. Only use ARIA table roles when you cannot use native HTML tables (for example, when building a custom grid layout that requires non-table CSS).

Media types describe the general category of a device for which a stylesheet is intended. The most commonly used values are screen (for computer screens, tablets, and phones), print (for print preview and printed pages), and all (the default, for all devices).

Understanding Deprecated Media Types

CSS 2.1 and Media Queries 3 defined several additional media types: tty, tv, projection, handheld, braille, embossed, and aural. All of these were deprecated in the Media Queries 4 specification. The projection type was originally intended for projected presentations (such as slideshows), but modern browsers never meaningfully distinguished between screen and projection rendering contexts.

Why This Is a Problem

• Standards compliance: Using deprecated media types produces validator warnings and means your code doesn’t conform to current web standards.
• No practical effect: Modern browsers treat unrecognized or deprecated media types as not matching, which means a stylesheet targeted only at projection would never be applied. When combined with screen in a comma-separated list (e.g., screen,projection), the projection portion is simply ignored — it adds clutter without benefit.
• Maintainability: Keeping deprecated values in your markup can confuse other developers and suggest that the code targets a platform that no longer exists in the spec.

How to Fix It

1. Remove the deprecated media type from the media attribute, keeping only valid types like screen, print, speech, or all.
2. Remove the media attribute entirely if the remaining value is all or if you only need screen (since screen is the most common rendering context and stylesheets without a media attribute default to all).
3. Use modern media features instead of deprecated media types if you need to target specific device capabilities (e.g., (hover: none), (pointer: coarse), (display-mode: fullscreen)).

Examples

❌ Incorrect: Using the deprecated projection media type

<link rel="stylesheet" href="styles.css" media="screen,projection">

This triggers the validation warning because projection has been deprecated.

✅ Correct: Using only the screen media type

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

✅ Correct: Removing the media attribute entirely

If you want the stylesheet to apply to all media types (the default behavior), simply omit the attribute:

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

✅ Correct: Combining valid media types

If you need your stylesheet to apply to both screen and print contexts:

<link rel="stylesheet" href="styles.css" media="screen,print">

❌ Other deprecated media types to avoid

All of the following are deprecated and will produce similar warnings:

<link rel="stylesheet" href="a.css" media="handheld">
<link rel="stylesheet" href="b.css" media="tv">
<link rel="stylesheet" href="c.css" media="braille">
<link rel="stylesheet" href="d.css" media="embossed">
<link rel="stylesheet" href="e.css" media="tty">
<link rel="stylesheet" href="f.css" media="aural">

Replace these with screen, print, speech, all, or use specific media features to target the device characteristics you need.

The search ARIA role is a landmark role, which means it identifies a large, navigable section of a page — specifically, the region that contains the search functionality. Landmark roles help assistive technologies (like screen readers) quickly identify and jump to major sections of a document. Because landmarks describe sections of a page, they belong on container elements that encompass all the parts of the search interface (the label, the input field, the submit button, etc.), not on a single <input> element.

When you place role="search" on an <input>, the validator rejects it because the search role doesn’t match the semantics of an input control. An <input> represents a single interactive widget, not a page region. The valid way to indicate that an input field is for search queries is to use <input type="search">, which gives browsers and assistive technologies the correct semantic meaning for that specific control.

Meanwhile, if you want to mark an entire search form as a search landmark, apply role="search" to the <form> element that wraps the search controls. In modern HTML, you can also use the <search> element, which has the implicit search landmark role without needing any ARIA attribute.

How to fix it

1. Remove role="search" from the <input> element.
2. Change the input’s type to "search" — this tells browsers and assistive technologies that the field is for search queries.
3. Apply role="search" to the wrapping <form>, or use the HTML <search> element as the container.

Examples

❌ Incorrect: role="search" on an <input>

<form>
  <label for="query">Search</label>
  <input role="search" id="query" name="q">
  <button type="submit">Go</button>
</form>

This triggers the validation error because search is not a valid role for <input>.

✅ Correct: type="search" on the input, role="search" on the form

<form role="search">
  <label for="query">Search this site</label>
  <input type="search" id="query" name="q">
  <button type="submit">Go</button>
</form>

Here, role="search" is correctly placed on the <form> element, creating a search landmark. The <input type="search"> conveys the correct semantics for the input field itself.

✅ Correct: Using the <search> element (modern HTML)

<search>
  <form>
    <label for="query">Search this site</label>
    <input type="search" id="query" name="q">
    <button type="submit">Go</button>
  </form>
</search>

The <search> element has the implicit ARIA role of search, so no explicit role attribute is needed on either the container or the form. This is the most semantic approach in browsers that support it.

✅ Correct: Standalone search input without a landmark

If you simply need a search-styled input without marking up a full landmark region, just use type="search":

<label for="filter">Filter results</label>
<input type="search" id="filter" name="filter">

This gives the input the correct semantics and allows browsers to provide search-specific UI features (such as a clear button) without requiring a landmark role.

The value section does not exist in the WAI-ARIA specification. ARIA defines a specific set of role values, and section is not among them. This is likely a confusion between the HTML element name <section> and the ARIA role region, which is the role that the <section> element implicitly maps to. Because section is not a recognized role, the validator rejects it as an invalid value.

This matters for several reasons. First, assistive technologies like screen readers rely on ARIA roles to communicate the purpose of elements to users. An unrecognized role value may be ignored entirely or cause unexpected behavior, degrading the experience for users who depend on these tools. Second, the <section> element already carries native semantics equivalent to role="region" (when it has an accessible name), so adding a redundant or incorrect role provides no benefit and introduces potential problems.

According to the ARIA in HTML specification, you should generally avoid setting a role on elements that already have appropriate native semantics. The <section> element’s implicit role is region, so explicitly adding role="region" is redundant in most cases. The simplest and best fix is to remove the role attribute altogether and let the native HTML semantics do their job.

If you do need to override an element’s role for a specific design pattern (for example, turning a <section> into a navigation landmark), use a valid ARIA role from the WAI-ARIA specification.

Examples

Incorrect: using the invalid section role

<section role="section">
  <h2>About Us</h2>
  <p>Learn more about our team.</p>
</section>

This triggers the validation error because section is not a valid ARIA role value.

Correct: remove the role attribute

<section>
  <h2>About Us</h2>
  <p>Learn more about our team.</p>
</section>

The <section> element already provides the correct semantics. No role attribute is needed.

Correct: use a valid ARIA role if needed

If you have a specific reason to assign a role, use a valid one. For example, if a <section> is being used as a navigation landmark:

<section role="navigation" aria-label="Main navigation">
  <ul>
    <li><a href="/">Home</a></li>
    <li><a href="/about">About</a></li>
  </ul>
</section>

In practice, you would typically use a <nav> element instead, which has the navigation role natively. This example simply illustrates that if you do apply a role, it must be a valid ARIA role value.

Correct: explicit region role with an accessible name

If you want to explicitly mark a section as a named region landmark, you can use role="region" along with an accessible name. However, this is redundant when using <section> with an aria-label or aria-labelledby, since the browser already maps it to region:

<!-- Preferred: native semantics handle the role -->

<section aria-labelledby="features-heading">
  <h2 id="features-heading">Features</h2>
  <p>Explore our product features.</p>
</section>

<!-- Also valid but redundant -->

<section role="region" aria-labelledby="features-heading">
  <h2 id="features-heading">Features</h2>
  <p>Explore our product features.</p>
</section>

Both are valid HTML, but the first approach is cleaner and follows the principle of relying on native semantics whenever possible.

The role attribute exposes an element’s purpose to assistive technologies. ARIA defines a fixed set of role values; sidebar is not among them, so validators report a bad value. Sidebars typically contain related or ancillary content, which maps to the complementary landmark role. In HTML, the <aside> element already represents this concept and implicitly maps to the complementary role.

Leaving an invalid role harms accessibility because screen readers may ignore the landmark or misreport it, and automated tools can’t build a reliable landmarks map. Standards compliance also matters for consistent behavior across browsers and assistive tech.

To fix it:

• Replace role="sidebar" with role="complementary" on a generic container; add an accessible name with aria-labelledby or aria-label when multiple complementary regions exist.
• Prefer <aside> for semantic HTML. It implicitly has the complementary role; add a label when there is more than one <aside>.
• Do not add role="complementary" to <aside> unless you need to override something; duplicate roles are unnecessary.
• If the area is site-wide navigation, use <nav> or role="navigation" instead; choose the role that best matches the intent.

Examples

Invalid: non-existent ARIA role

<div role="sidebar">
<!-- Related links and promos -->

</div>

Fixed: use the complementary role on a generic container

<div role="complementary" aria-labelledby="sidebar-title">
  <h2 id="sidebar-title">Related</h2>
  <ul>
    <li><a href="/guide-a">Guide A</a></li>
    <li><a href="/guide-b">Guide B</a></li>
  </ul>
</div>

Fixed: use semantic HTML with aside (implicit complementary)

<aside aria-labelledby="sidebar-title">
  <h2 id="sidebar-title">Related</h2>
  <ul>
    <li><a href="/guide-a">Guide A</a></li>
    <li><a href="/guide-b">Guide B</a></li>
  </ul>
</aside>

Multiple sidebars: ensure unique, descriptive labels

<aside aria-labelledby="filters-title">
  <h2 id="filters-title">Filter results</h2>
<!-- filter controls -->

</aside>

<aside aria-labelledby="related-title">
  <h2 id="related-title">Related articles</h2>
<!-- related links -->

</aside>

When it’s actually navigation: use the navigation landmark

<nav aria-label="Section navigation">
  <ul>
    <li><a href="#intro">Intro</a></li>
    <li><a href="#examples">Examples</a></li>
    <li><a href="#contact">Contact</a></li>
  </ul>
</nav>

Tips:

• Use <aside> for tangential content; it’s the simplest, standards-based approach.
• Provide an accessible name when more than one complementary region is present.
• Avoid inventing ARIA roles; stick to defined values like banner, main, navigation, complementary, contentinfo, and others.

ARIA defines a fixed set of role values that user agents and assistive technologies understand. sidebar is not in that set, so role="sidebar" fails conformance checking and gives unreliable signals to screen readers. Using a valid role or the correct HTML element improves accessibility, ensures consistent behavior across browsers and AT, and keeps your markup standards‑compliant.

Sidebars typically contain tangential or ancillary content (e.g., related links, promos, author info). The ARIA role that matches that meaning is complementary. In HTML, the semantic element for the same concept is aside, which by default maps to the complementary landmark in accessibility APIs. Prefer native semantics first: use <aside> when possible. Only add role="complementary" when you can’t change the element type or when you need an explicit landmark for non-semantic containers.

How to fix:

• If the element is a sidebar: change <div role="sidebar"> to <aside> (preferred), or to <div role="complementary">.
• Ensure each page has at most one primary main region and that complementary regions are not essential to understanding the main content.
• Provide an accessible name for the complementary region when multiple exist, using aria-label or aria-labelledby, to help users navigate landmarks.

Examples

Triggers the validator error

<div role="sidebar">
<!-- Sidebar content -->

</div>

Fixed: use the semantic element (preferred)

<aside aria-label="Related articles">
<!-- Sidebar content -->

</aside>

Fixed: keep the container, apply a valid role

<div role="complementary" aria-label="Related articles">
<!-- Sidebar content -->

</div>

Full document example with two sidebars (each labeled)

<!doctype html>
<html lang="en">
  <head>
    <meta charset="utf-8">
    <title>Sidebar Landmarks Example</title>
  </head>
  <body>
    <header>
      <h1>News Today</h1>
    </header>

    <main id="main">
      <article>
        <h2>Main Story</h2>
        <p>...</p>
      </article>
    </main>

    <aside aria-label="Trending topics">
      <ul>
        <li>Science</li>
        <li>Politics</li>
        <li>Sports</li>
      </ul>
    </aside>

    <div role="complementary" aria-labelledby="sponsor-title">
      <h2 id="sponsor-title">Sponsored</h2>
      <p>Ad content</p>
    </div>

    <footer>
      <p>&copy; 2026</p>
    </footer>
  </body>
</html>

Notes:

• Do not invent ARIA roles (e.g., sidebar, hero, footer-nav). Use defined roles like complementary, navigation, banner, contentinfo, and main.
• Prefer native HTML elements (aside, nav, header, footer, main) over generic containers with roles.
• Label multiple complementary landmarks to make them distinguishable in screen reader landmark lists.

The HTML specification defines specific rules about which autocomplete values can be used on which form elements. The street-address token is categorized as a “multiline” autofill field because street addresses often span multiple lines (e.g., “123 Main St\nApt 4B”). Since <input> elements only accept single-line text, the spec prohibits using street-address with them. The <textarea> element, on the other hand, naturally supports multiline content, making it the appropriate host for this token.

This matters for several reasons. First, browsers use autocomplete values to offer autofill suggestions. When the element type doesn’t match the expected data format, browsers may not autofill correctly or may ignore the hint entirely. Second, standards compliance ensures consistent behavior across different browsers and assistive technologies. Third, using the correct pairing improves the user experience — users expect their full street address to appear in a field that can actually display it properly.

You have two approaches to fix this:

1. Use a <textarea> — If you want the full street address in a single field, switch from <input> to <textarea>. This is the most semantically correct choice when you expect multiline address data.

2. Use line-specific tokens on <input> elements — If your form design uses separate single-line fields for each part of the address, use address-line1, address-line2, and address-line3 instead. These tokens are explicitly allowed on <input> elements.

Examples

❌ Invalid: street-address on an <input>

<label for="address">Street Address</label>
<input type="text" id="address" name="address" autocomplete="street-address">

This triggers the validation error because street-address requires a multiline control.

✅ Fix: Use a <textarea> with street-address

<label for="address">Street Address</label>
<textarea id="address" name="address" autocomplete="street-address"></textarea>

The <textarea> supports multiline text, so street-address is valid here.

✅ Fix: Use line-specific tokens on <input> elements

<label for="address1">Address Line 1</label>
<input type="text" id="address1" name="address1" autocomplete="address-line1">

<label for="address2">Address Line 2</label>
<input type="text" id="address2" name="address2" autocomplete="address-line2">

The address-line1, address-line2, and address-line3 tokens are single-line autofill fields and are perfectly valid on <input> elements. This approach is common in forms that break the address into separate fields for apartment numbers, building names, or other details.

Summary of allowed pairings

Choose the approach that best fits your form layout. If you prefer a single address field, use <textarea> with street-address. If you prefer structured, separate fields, use <input> elements with the appropriate address-line tokens.

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

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

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

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

Examples

Incorrect: tabpanel role on an article element

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

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

Correct: tabpanel role on a div

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

Correct: Nesting an article inside the tab panel

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

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

Full tab interface example

Here’s a complete, valid tab interface implementation:

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

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

The W3C validator raises this error because ARIA roles must be compatible with the element they are applied to. A <ul> element has an implicit ARIA role of list, and overriding it with tabpanel creates a conflict. The tabpanel role signals to assistive technologies that the element is a panel of content activated by a corresponding tab. When this role is placed on a <ul>, screen readers lose the semantic meaning of the list (item count, list navigation, etc.) while also misrepresenting the element’s function in the tab interface.

This matters for several reasons:

• Accessibility: Screen reader users rely on correct roles to navigate and understand page structure. A <ul> marked as tabpanel confuses both its list semantics and its role in the tab interface.
• Standards compliance: The ARIA in HTML specification defines which roles are allowed on which elements. The tabpanel role is not permitted on <ul>.
• Browser behavior: Browsers may handle conflicting roles inconsistently, leading to unpredictable behavior across assistive technologies.

The fix is straightforward: wrap the <ul> inside a proper container element (like a <div> or <section>) and apply the tabpanel role to that container instead.

Examples

Incorrect: tabpanel role on a <ul>

This triggers the validation error because tabpanel is not a valid role for <ul>:

<div role="tablist" aria-label="Recipe categories">
  <button role="tab" aria-controls="panel-1" aria-selected="true" id="tab-1">Appetizers</button>
  <button role="tab" aria-controls="panel-2" aria-selected="false" id="tab-2">Desserts</button>
</div>

<ul role="tabpanel" id="panel-1" aria-labelledby="tab-1">
  <li>Bruschetta</li>
  <li>Spring rolls</li>
</ul>

<ul role="tabpanel" id="panel-2" aria-labelledby="tab-2" hidden>
  <li>Tiramisu</li>
  <li>Cheesecake</li>
</ul>

Correct: tabpanel role on a container wrapping the <ul>

Move the tabpanel role to a <div> and nest the <ul> inside it. This preserves both the tab panel semantics and the list semantics:

<div role="tablist" aria-label="Recipe categories">
  <button role="tab" aria-controls="panel-1" aria-selected="true" id="tab-1">Appetizers</button>
  <button role="tab" aria-controls="panel-2" aria-selected="false" id="tab-2">Desserts</button>
</div>

<div role="tabpanel" id="panel-1" aria-labelledby="tab-1">
  <ul>
    <li>Bruschetta</li>
    <li>Spring rolls</li>
  </ul>
</div>

<div role="tabpanel" id="panel-2" aria-labelledby="tab-2" hidden>
  <ul>
    <li>Tiramisu</li>
    <li>Cheesecake</li>
  </ul>
</div>

Correct: Using <section> as the tab panel

A <section> element also works well as a tab panel container, especially when the panel content is more complex:

<div role="tablist" aria-label="Project info">
  <button role="tab" aria-controls="tasks-panel" aria-selected="true" id="tasks-tab">Tasks</button>
  <button role="tab" aria-controls="notes-panel" aria-selected="false" id="notes-tab">Notes</button>
</div>

<section role="tabpanel" id="tasks-panel" aria-labelledby="tasks-tab">
  <h2>Current tasks</h2>
  <ul>
    <li>Review pull requests</li>
    <li>Update documentation</li>
  </ul>
</section>

<section role="tabpanel" id="notes-panel" aria-labelledby="notes-tab" hidden>
  <h2>Meeting notes</h2>
  <p>Discussed project timeline and milestones.</p>
</section>

In a properly structured tabbed interface:

• The tablist role goes on the container that holds the tab buttons.
• Each tab trigger gets role="tab" with aria-controls pointing to its panel’s id.
• Each content panel gets role="tabpanel" on a generic container like <div> or <section>, with aria-labelledby referencing the corresponding tab’s id.
• List elements like <ul> and <ol> should remain inside the panel as regular content, retaining their native list semantics.

The HTML specification defines specific rules about which autocomplete autofill field names can be paired with which input types. The tel-national token (which represents a phone number without the country code) is classified as requiring a text-based input control. Meanwhile, <input type="tel"> is a specialized control that the spec treats differently from a plain text field. When the validator encounters tel-national on a type="tel" input, it flags the mismatch because the autofill field name is not allowed in that context.

This might seem counterintuitive — a national telephone number value on a telephone input feels like a natural fit. However, the distinction exists because type="tel" already implies a complete telephone number, and the spec maps the broader tel autocomplete token to it. The more granular telephone tokens like tel-national, tel-country-code, tel-area-code, tel-local, tel-local-prefix, and tel-local-suffix are designed for type="text" inputs where a phone number is being broken into individual parts across multiple fields.

Getting this right matters for browser autofill behavior. When the autocomplete value and input type are properly paired according to the spec, browsers can more reliably populate the field with the correct portion of the user’s stored phone number. An invalid pairing may cause autofill to silently fail or behave unpredictably across different browsers.

How to fix it

You have two options:

1. Change the input type to text — Use type="text" if you specifically want the national portion of a phone number (without the country code). This is the right choice when you’re splitting a phone number across multiple fields.
2. Change the autocomplete value to tel — Use autocomplete="tel" if you want a single field for the full phone number. This pairs correctly with type="tel".

Examples

❌ Invalid: tel-national on type="tel"

<label for="phone">Phone number</label>
<input id="phone" name="phone" type="tel" autocomplete="tel-national">

This triggers the validation error because tel-national is not allowed on a type="tel" input.

✅ Fix option 1: Change input type to text

<label for="phone">Phone number (without country code)</label>
<input id="phone" name="phone" type="text" autocomplete="tel-national">

Using type="text" satisfies the spec’s requirement for the tel-national autofill token. This is ideal when collecting just the national portion of a number.

✅ Fix option 2: Change autocomplete to tel

<label for="phone">Phone number</label>
<input id="phone" name="phone" type="tel" autocomplete="tel">

Using autocomplete="tel" is the correct pairing for type="tel" and tells the browser to autofill the complete phone number.

✅ Splitting a phone number across multiple fields

When you need separate fields for different parts of a phone number, use type="text" with the granular autocomplete tokens:

<fieldset>
  <legend>Phone number</legend>
  <label for="country-code">Country code</label>
  <input id="country-code" name="country-code" type="text" autocomplete="tel-country-code">
  <label for="national">National number</label>
  <input id="national" name="national" type="text" autocomplete="tel-national">
</fieldset>

A URI (Uniform Resource Identifier) follows a strict syntax defined by RFC 3986. The general structure is scheme:scheme-data, where no spaces or other illegal characters are allowed between the colon and the scheme-specific data. When the W3C validator reports “Illegal character in scheme data,” it means the parser found a character that isn’t permitted in that position of the URI.

The most common cause of this error is adding a space after the colon in tel: links (e.g., tel: +123456789). While browsers may be forgiving and still handle the link, the markup is technically invalid. This matters for several reasons:

• Accessibility: Screen readers and assistive technologies rely on well-formed URIs to correctly identify link types. A malformed tel: link might not be announced as a phone number.
• Standards compliance: Invalid URIs violate the HTML specification, which requires the href attribute to contain a valid URL.
• Cross-device behavior: Mobile devices use the URI scheme to determine which app should handle a link. A malformed tel: URI may fail to trigger the phone dialer on some devices or operating systems.
• Interoperability: While some browsers silently trim spaces, others may encode them as %20, potentially breaking the phone number or other scheme data.

To fix this issue, ensure there are no spaces or other illegal characters between the scheme’s colon and the data that follows it. For telephone links specifically, the number should follow the colon directly, using only digits, hyphens, dots, parentheses, and the + prefix as defined by RFC 3966.

Examples

Incorrect: space after the colon in a tel: link

<a href="tel: +1-234-567-8900">Call us</a>

The space between tel: and +1 is an illegal character in the URI scheme data.

Correct: no space after the colon

<a href="tel:+1-234-567-8900">Call us</a>

Incorrect: space after the colon in a mailto: link

<a href="mailto: support@example.com">Email support</a>

Correct: mailto: with no space

<a href="mailto:support@example.com">Email support</a>

Incorrect: other illegal characters in scheme data

<a href="tel:+1 234 567 8900">Call us</a>

Spaces within the phone number itself are also illegal characters in the URI. Use hyphens, dots, or no separators instead.

Correct: valid separators in a phone number

<a href="tel:+1-234-567-8900">Call us</a>
<a href="tel:+1.234.567.8900">Call us</a>
<a href="tel:+12345678900">Call us</a>

Visual formatting vs. the href value

If you want the displayed phone number to include spaces for readability, format the visible text separately from the href value:

<a href="tel:+12345678900">+1 234 567 8900</a>

The href contains a valid URI with no spaces, while the link text is formatted for easy reading. This gives you the best of both worlds — valid markup and a user-friendly display.

The HTML5 specification mandates UTF-8 as the only permitted character encoding for web documents declared via <meta> tags. Legacy encodings such as windows-1251 (a Cyrillic character encoding), iso-8859-1, shift_jis, and others are no longer valid values in HTML5 <meta> declarations. This restriction exists because UTF-8 is a universal encoding that can represent virtually every character from every writing system, eliminating the interoperability problems that plagued the web when dozens of competing encodings were in use.

When the validator encounters content="text/html; charset=windows-1251" on a <meta> element, it flags it because the charset= portion must be followed by utf-8 — no other value is accepted. This applies whether you use the longer <meta http-equiv="Content-Type"> syntax or the shorter <meta charset> syntax.

Why this matters

• Standards compliance: The WHATWG HTML Living Standard explicitly requires utf-8 as the character encoding when declared in a <meta> tag. Non-conforming encodings will trigger validation errors.
• Internationalization: UTF-8 supports all Unicode characters, making your pages work correctly for users across all languages, including Cyrillic text that windows-1251 was originally designed for.
• Security: Legacy encodings can introduce security vulnerabilities, including certain cross-site scripting (XSS) attack vectors that exploit encoding ambiguity.
• Browser consistency: While browsers may still recognize legacy encodings, relying on them can cause mojibake (garbled text) when there’s a mismatch between the declared and actual encoding.

How to fix it

1. Update the <meta> tag to declare utf-8 as the charset.
2. Re-save your file in UTF-8 encoding using your text editor or IDE. Most modern editors support this — look for an encoding option in “Save As” or in the status bar.
3. Verify your server configuration. If your server sends a Content-Type HTTP header with a different encoding, the server header takes precedence over the <meta> tag. Make sure both agree on UTF-8.
4. Convert your content. If your text was originally written in windows-1251, you may need to convert it to UTF-8. Tools like iconv on the command line can help: iconv -f WINDOWS-1251 -t UTF-8 input.html > output.html.

Examples

❌ Incorrect: Using windows-1251 charset

<meta http-equiv="Content-Type" content="text/html; charset=windows-1251">

✅ Correct: Using utf-8 with http-equiv syntax

<meta http-equiv="Content-Type" content="text/html; charset=utf-8">

✅ Correct: Using the shorter <meta charset> syntax (preferred in HTML5)

<meta charset="utf-8">

Full document example

<!DOCTYPE html>
<html lang="ru">
  <head>
    <meta charset="utf-8">
    <title>Пример страницы</title>
  </head>
  <body>
    <p>Текст на русском языке в кодировке UTF-8.</p>
  </body>
</html>

The shorter <meta charset="utf-8"> syntax is generally preferred in HTML5 documents because it’s more concise and achieves the same result. Whichever syntax you choose, place the charset declaration within the first 1024 bytes of your document — ideally as the very first element inside <head> — so browsers can detect the encoding as early as possible.

The HTML specification mandates that documents must be encoded in UTF-8. This requirement exists because UTF-8 is the universal character encoding that supports virtually every character from every writing system in the world. Older encodings like windows-1252, iso-8859-1, or shift_jis only support a limited subset of characters and can cause text to display incorrectly — showing garbled characters or question marks — especially for users in different locales or when content includes special symbols, accented letters, or emoji.

When the validator encounters charset=windows-1252 in your <meta> tag, it flags this as an error because the HTML living standard (WHATWG) explicitly states that the character encoding declaration must specify utf-8 as the encoding. This isn’t just a stylistic preference — browsers and other tools rely on this declaration to correctly interpret the bytes in your document. Using a non-UTF-8 encoding can lead to security vulnerabilities (such as encoding-based XSS attacks) and accessibility issues when assistive technologies misinterpret characters.

To fix this issue, take two steps:

1. Update the <meta> tag to declare utf-8 as the charset.
2. Re-save your file with UTF-8 encoding. Most modern code editors (VS Code, Sublime Text, etc.) let you choose the encoding when saving — look for an option like “Save with Encoding” or check the status bar for the current encoding. If your file was originally in windows-1252, simply changing the <meta> tag without re-encoding the file could cause existing special characters to display incorrectly.

The HTML spec also recommends using the shorter <meta charset="utf-8"> form rather than the longer <meta http-equiv="Content-Type" ...> pragma directive, as it’s simpler and achieves the same result. Either form is valid, but the charset declaration must appear within the first 1024 bytes of the document.

Examples

Incorrect: Using windows-1252 charset

<meta http-equiv="Content-Type" content="text/html; charset=windows-1252">

This triggers the validator error because the charset is not utf-8.

Correct: Using the short charset declaration (recommended)

<meta charset="utf-8">

Correct: Using the http-equiv pragma directive with utf-8

<meta http-equiv="Content-Type" content="text/html; charset=utf-8">

Full document example

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

Note that the <meta charset="utf-8"> tag should be the first element inside <head>, before any other elements (including <title>), so the browser knows the encoding before it starts parsing the rest of the document.

The textbox ARIA role identifies an element that allows free-form text input. While it can technically be applied to elements using contenteditable, it should not be placed on elements that already carry strong semantic meaning, such as <li>. A list item is expected to be a child of <ul>, <ol>, or <menu>, and its implicit listitem role communicates its purpose within a list structure to assistive technologies. Assigning role="textbox" to an <li> overrides this semantic, confusing screen readers and other assistive tools about whether the element is a list item or a text input field.

This is problematic for several reasons:

• Accessibility: Screen readers rely on roles to convey the purpose of elements to users. An <li> with role="textbox" sends mixed signals — it exists within a list structure but announces itself as a text input.
• Standards compliance: The ARIA in HTML specification restricts which roles can be applied to specific elements. The li element does not allow the textbox role, which is why the W3C validator flags this as an error.
• Browser behavior: Browsers may handle the conflicting semantics unpredictably, leading to inconsistent experiences across different user agents.

The best approach is to use native HTML form elements whenever possible. The <input type="text"> element handles single-line text input, and the <textarea> element handles multi-line input. These native elements come with built-in keyboard support, focus management, and form submission behavior — none of which you get for free with a role="textbox" on a non-form element.

If you genuinely need an editable area inside a list and cannot use native form elements, nest a <div> or <span> with role="textbox" inside the <li> rather than placing the role on the <li> itself.

Examples

❌ Incorrect: role="textbox" on an li element

<ul>
  <li role="textbox" contenteditable="true">Edit this item</li>
  <li role="textbox" contenteditable="true">Edit this item too</li>
</ul>

This triggers the validator error because textbox is not a valid role for <li>.

✅ Fix: Use native form elements

The simplest and most robust fix is to use standard form controls:

<ul>
  <li>
    <label for="item1">Item 1:</label>
    <input type="text" id="item1" value="Edit this item">
  </li>
  <li>
    <label for="item2">Item 2:</label>
    <input type="text" id="item2" value="Edit this item too">
  </li>
</ul>

For multi-line input, use <textarea>:

<ul>
  <li>
    <label for="note1">Note:</label>
    <textarea id="note1">Edit this content</textarea>
  </li>
</ul>

✅ Fix: Nest a div with role="textbox" inside the li

If you need a contenteditable area and cannot use native form elements, place the textbox role on a nested element:

<ul>
  <li>
    <div id="label1">Item 1:</div>
    <div
      role="textbox"
      contenteditable="true"
      aria-labelledby="label1"
      aria-placeholder="Enter text">
      Edit this item
    </div>
  </li>
</ul>

This preserves the <li> element’s implicit listitem role while correctly assigning the textbox role to a semantically neutral <div>.

✅ Fix: Remove the list structure entirely

If the items aren’t truly a list, consider dropping the <ul>/<li> structure altogether:

<div id="zipLabel">Enter your five-digit zipcode</div>
<div
  role="textbox"
  contenteditable="true"
  aria-placeholder="5-digit zipcode"
  aria-labelledby="zipLabel">
</div>

In every case, prefer native <input> and <textarea> elements over role="textbox" with contenteditable. Native elements provide accessible behavior by default, including keyboard interaction, form validation, and proper focus management, without requiring additional ARIA attributes or JavaScript.

In HTML, boolean attributes like allowfullscreen, disabled, readonly, and hidden work differently from what many developers expect. Their presence alone on an element means “true,” and their absence means “false.” The only valid values for a boolean attribute are the empty string ("") or the attribute’s own name (e.g., allowfullscreen="allowfullscreen"). Setting a boolean attribute to "true" is not valid HTML according to the WHATWG HTML living standard, even though browsers will typically still interpret it as enabled.

This matters for several reasons. First, it violates the HTML specification and will produce a W3C validation error. Second, it can create confusion for other developers who may assume that setting the attribute to "false" would disable it — but that’s not how boolean attributes work. Setting allowfullscreen="false" would still enable fullscreen because the attribute is present. Keeping your markup valid and semantically correct avoids these misunderstandings and ensures forward compatibility with browsers and tooling.

It’s also worth noting that allowfullscreen is now considered a legacy attribute. The modern approach is to use the allow attribute with the "fullscreen" permission token, which is part of the broader Permissions Policy mechanism. The allow attribute gives you fine-grained control over multiple features in a single attribute.

Examples

Incorrect: boolean attribute set to “true”

This triggers the validation error because "true" is not a valid value for a boolean attribute.

<iframe src="https://example.com" allowfullscreen="true"></iframe>

Correct: boolean attribute with no value

Simply include the attribute name without any value assignment.

<iframe src="https://example.com" allowfullscreen></iframe>

Also correct: boolean attribute with an empty string

The empty string is a valid value for any boolean attribute.

<iframe src="https://example.com" allowfullscreen=""></iframe>

Also correct: boolean attribute set to its own name

Per the spec, a boolean attribute can be set to a case-insensitive match of its own name.

<iframe src="https://example.com" allowfullscreen="allowfullscreen"></iframe>

Recommended: using the modern allow attribute

The allow attribute is the preferred approach going forward. It replaces allowfullscreen and can also control other permissions like camera, microphone, and more.

<iframe src="https://example.com" allow="fullscreen"></iframe>

You can combine multiple permissions in a single allow attribute:

<iframe src="https://example.com" allow="fullscreen; camera; microphone"></iframe>

Common mistake: trying to disable with “false”

Be aware that the following does not disable fullscreen — the attribute is still present, so fullscreen is still allowed. This would also produce a validation error.

<!-- This does NOT disable fullscreen — and is invalid HTML -->

<iframe src="https://example.com" allowfullscreen="false"></iframe>

To disable fullscreen, simply omit the attribute entirely:

<iframe src="https://example.com"></iframe>

The aria-hidden attribute controls whether an element and its descendants are exposed to assistive technologies such as screen readers. When set to true, the element is hidden from the accessibility tree; when set to false, it remains visible. According to the WAI-ARIA specification, the only valid values for this attribute are the literal strings true and false. Any other value — including "true" with embedded quotation marks — is invalid.

When the validator reports a bad value like "true" (with the quotation marks as part of the value), it means the actual attribute value contains the characters "true" rather than just true. HTML attributes already use outer quotes as delimiters, so any quotes inside the value become part of the value itself. The browser or assistive technology may not recognize "true" as a valid ARIA state, which can lead to the element being incorrectly exposed to or hidden from screen readers, breaking the intended accessibility behavior.

This issue commonly arises in a few scenarios:

• Copy-pasting from formatted text where “smart quotes” or extra quoting gets included.
• Templating engines or frameworks that double-escape or double-quote attribute values (e.g., aria-hidden="{{value}}" where {{value}} already outputs "true").
• JavaScript that sets the attribute with extra quotes, such as element.setAttribute("aria-hidden", '"true"').

To fix the issue, ensure the attribute value contains only the bare string true or false with no extra quotation marks, HTML entities, or escaped characters inside it.

Examples

Incorrect — extra quotes embedded in the value

<div aria-hidden='"true"'>
  This content should be hidden from assistive tech
</div>

The rendered attribute value is literally "true" (five characters including the quotes), which is not a recognized ARIA value.

Incorrect — HTML entities producing extra quotes

<div aria-hidden="&quot;true&quot;">
  This content should be hidden from assistive tech
</div>

The &quot; entities resolve to quotation mark characters, producing the same invalid value of "true".

Correct — simple true value

<div aria-hidden="true">
  This content is hidden from assistive tech
</div>

Correct — simple false value

<div aria-hidden="false">
  This content is visible to assistive tech
</div>

Fixing the issue in JavaScript

If you’re setting the attribute dynamically, make sure you aren’t wrapping the value in extra quotes:

<div id="modal">Modal content</div>
<script>
  // Incorrect:
  // document.getElementById("modal").setAttribute("aria-hidden", '"true"');

  // Correct:
  document.getElementById("modal").setAttribute("aria-hidden", "true");
</script>

Fixing the issue in templating engines

If a template variable already outputs a quoted string, don’t add additional quotes around it. For example, in a templating system:

<!-- Incorrect: if myVar outputs "true" (with quotes) -->

<!-- <div aria-hidden="{{myVar}}"> -->


<!-- Correct: ensure myVar outputs just true (no quotes) -->

<div aria-hidden="true">
  Content
</div>

The key takeaway is straightforward: the outer quotes in aria-hidden="true" are HTML syntax — they delimit the attribute value. The value itself must be exactly true or false with nothing extra. If you’re generating HTML dynamically, inspect the rendered output in your browser’s developer tools to confirm the attribute value doesn’t contain stray quotation marks.

In HTML, boolean attributes work differently than you might expect from programming languages. They don’t accept "true" or "false" as values. Instead, the presence of the attribute means it’s active, and its absence means it’s inactive. This is defined in the WHATWG HTML Living Standard, which states that a boolean attribute’s value must either be the empty string or a case-insensitive match for the attribute’s name.

This means there are exactly three valid ways to write the disabled attribute:

• disabled (no value)
• disabled="" (empty string)
• disabled="disabled" (attribute name as value)

Any other value — including "true", "false", "yes", "no", or "1" — is invalid and will trigger a W3C validation error.

A common and dangerous misunderstanding is that disabled="false" will make an element not disabled. It won’t. Because boolean attributes are activated by their presence alone, disabled="false" still disables the element. The browser sees the disabled attribute is present and treats the element as disabled, completely ignoring the "false" value. This can lead to confusing bugs where elements appear permanently disabled.

This issue affects all elements that support the disabled attribute, including <input>, <button>, <select>, <textarea>, <fieldset>, <optgroup>, and <option>. The same rules apply to other boolean attributes like checked, readonly, required, autofocus, and hidden.

Why this matters

• Standards compliance: Using invalid attribute values violates the HTML specification and produces W3C validation errors.
• Maintainability: Developers reading disabled="true" or disabled="false" may misunderstand the intent, especially if they assume "false" removes the disabled state.
• Framework pitfalls: Some JavaScript frameworks dynamically set disabled="true" or disabled="false" as string values. When the rendered HTML reaches the browser, both values result in a disabled element, which is rarely the intended behavior.

How to fix it

1. To disable an element, add the disabled attribute with no value, or use disabled="" or disabled="disabled".
2. To enable an element, remove the disabled attribute entirely. Don’t set it to "false".
3. In JavaScript, use the DOM property element.disabled = true or element.disabled = false, or use element.removeAttribute('disabled') to enable it. Avoid element.setAttribute('disabled', 'false').

Examples

❌ Invalid: using "true" and "false" as values

<form>
  <input type="text" disabled="true">
  <select disabled="false">
    <option>Option A</option>
  </select>
  <button type="submit" disabled="true">Submit</button>
</form>

Both the "true" and "false" values are invalid. Additionally, disabled="false" still disables the <select> element, which is almost certainly not what was intended.

✅ Valid: correct boolean attribute usage

<form>
  <input type="text" disabled>
  <select>
    <option>Option A</option>
  </select>
  <button type="submit" disabled="disabled">Submit</button>
</form>

Here, the <input> and <button> are disabled using valid syntax. The <select> is enabled because the disabled attribute has been removed entirely.

✅ Valid: toggling disabled state with JavaScript

<form>
  <input type="text" id="username" disabled>
  <button type="button" id="toggle">Enable field</button>
  <script>
    document.getElementById('toggle').addEventListener('click', function () {
      var field = document.getElementById('username');
      field.disabled = !field.disabled;
    });
  </script>
</form>

Using the disabled DOM property (a real boolean) is the correct way to toggle the disabled state dynamically. This avoids the pitfall of setting string values like "true" or "false" on the attribute.

In HTML, boolean attributes work differently than you might expect from programming languages. A boolean attribute’s presence on an element represents the true value, and its absence represents false. You don’t set them to "true" or "false" like you would in JavaScript or other languages. According to the WHATWG HTML specification, a boolean attribute has exactly three valid forms:

1. The attribute name alone (e.g., multiple)
2. The attribute with an empty value (e.g., multiple="")
3. The attribute with a value matching its own name, case-insensitively (e.g., multiple="multiple")

Setting multiple="true" is invalid because "true" is not one of the permitted values. While browsers are forgiving and will typically still treat the attribute as present (effectively enabling it), this produces a W3C validation error and does not conform to the HTML standard. Relying on browser leniency leads to inconsistent behavior, makes your code harder to maintain, and can cause problems with HTML processing tools or strict parsers.

This same rule applies to all boolean attributes in HTML, including disabled, readonly, checked, required, hidden, autoplay, and many others.

It’s also important to note that multiple="false" does not disable the attribute. Because the attribute is still present on the element, the browser treats it as enabled. To disable a boolean attribute, you must remove it from the element entirely.

Examples

❌ Invalid: using "true" as the value

<label for="colors">Select your favorite colors:</label>
<select id="colors" name="colors" multiple="true">
  <option value="red">Red</option>
  <option value="green">Green</option>
  <option value="blue">Blue</option>
</select>

This triggers the validation error: Bad value “true” for attribute “multiple” on element “select”.

✅ Fixed: attribute name only (preferred)

<label for="colors">Select your favorite colors:</label>
<select id="colors" name="colors" multiple>
  <option value="red">Red</option>
  <option value="green">Green</option>
  <option value="blue">Blue</option>
</select>

✅ Fixed: empty string value

<label for="colors">Select your favorite colors:</label>
<select id="colors" name="colors" multiple="">
  <option value="red">Red</option>
  <option value="green">Green</option>
  <option value="blue">Blue</option>
</select>

✅ Fixed: value matching the attribute name

<label for="colors">Select your favorite colors:</label>
<select id="colors" name="colors" multiple="multiple">
  <option value="red">Red</option>
  <option value="green">Green</option>
  <option value="blue">Blue</option>
</select>

❌ Common mistake: using "false" to disable

<!-- This does NOT disable multiple selection — the attribute is still present -->

<select name="colors" multiple="false">
  <option value="red">Red</option>
  <option value="green">Green</option>
</select>

✅ Correct way to disable: remove the attribute entirely

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

In HTML, boolean attributes like selected work differently than you might expect if you’re coming from a programming language. A boolean attribute’s presence alone means “true,” and its absence means “false.” Setting selected="true" is invalid because the only permitted values for a boolean attribute are the empty string ("") or the attribute’s own name (e.g., selected="selected"). The value "true" is not recognized by the HTML specification, which is why the W3C validator flags it.

This matters for several reasons. First, it violates the WHATWG HTML specification, which explicitly defines how boolean attributes must be written. Second, while most browsers are forgiving and will still treat selected="true" as if the option is selected, relying on this lenient behavior is risky — it can lead to inconsistencies across browsers or tools that parse HTML strictly. Third, invalid markup can cause problems for assistive technologies, automated testing tools, and server-side HTML processors that follow the spec closely.

The same rule applies to other boolean attributes like disabled, checked, readonly, multiple, required, and hidden. None of them should be set to "true" or "false".

It’s also worth noting that setting a boolean attribute to "false" (e.g., selected="false") does not turn it off — the attribute’s mere presence activates it. To deactivate a boolean attribute, you must remove it entirely from the element.

Examples

❌ Invalid: using selected="true"

<select name="color">
  <option selected="true">Red</option>
  <option>Green</option>
  <option>Blue</option>
</select>

This triggers the validation error because "true" is not a valid value for the boolean selected attribute.

✅ Valid: bare attribute (preferred)

<select name="color">
  <option selected>Red</option>
  <option>Green</option>
  <option>Blue</option>
</select>

The simplest and most common way to write a boolean attribute — just include the attribute name with no value.

✅ Valid: empty string value

<select name="color">
  <option selected="">Red</option>
  <option>Green</option>
  <option>Blue</option>
</select>

An empty string is a valid value for any boolean attribute per the HTML spec.

✅ Valid: attribute name as value

<select name="color">
  <option selected="selected">Red</option>
  <option>Green</option>
  <option>Blue</option>
</select>

Using the attribute’s own name as its value is also valid. This form is sometimes seen in XHTML-style markup and in templating systems.

❌ Invalid: using selected="false" to deselect

<select name="color">
  <option selected="false">Red</option>
  <option>Green</option>
  <option>Blue</option>
</select>

This is both invalid and misleading. The option will still be selected because the selected attribute is present. To not select an option, simply omit the attribute:

<select name="color">
  <option>Red</option>
  <option>Green</option>
  <option>Blue</option>
</select>

The wrap attribute on a <textarea> controls how text is wrapped when the form is submitted. The value "virtual" was used by some older browsers (notably early versions of Netscape and Internet Explorer) as a proprietary alternative to what the HTML Standard now calls "soft". Since "virtual" was never part of any formal HTML specification, the W3C validator correctly rejects it as an invalid value.

The HTML Standard defines only two valid values for wrap:

• soft (the default): The text is visually wrapped in the browser for display purposes, but no actual line break characters are inserted into the submitted form data. The server receives the text as continuous lines.
• hard: The browser inserts carriage return + line feed (CRLF) characters at the visual wrap points when the form is submitted, so the server receives the text with hard line breaks. When using wrap="hard", you must also specify the cols attribute so the browser knows where the wrap points are.

Since "virtual" was functionally identical to "soft", replacing it is straightforward. If you omit the wrap attribute altogether, the browser defaults to soft wrapping, which gives you the same behavior.

Why this matters

Using non-standard attribute values can lead to unpredictable behavior across browsers. While most modern browsers will likely fall back to soft wrapping when they encounter an unrecognized wrap value, this is not guaranteed by any specification. Sticking to valid values ensures consistent, cross-browser behavior and keeps your markup standards-compliant.

How to fix it

1. Replace wrap="virtual" with wrap="soft" for an explicit equivalent.
2. Remove the wrap attribute entirely if you want the default soft wrapping behavior.
3. Use wrap="hard" with a cols attribute if you actually need hard line breaks inserted on submission.

Examples

❌ Invalid: using the non-standard "virtual" value

<form>
  <label for="msg">Message</label>
  <textarea id="msg" name="msg" wrap="virtual"></textarea>
</form>

This triggers the error: Bad value “virtual” for attribute “wrap” on element “textarea”.

✅ Fixed: using wrap="soft" (equivalent to "virtual")

<form>
  <label for="msg">Message</label>
  <textarea id="msg" name="msg" wrap="soft"></textarea>
</form>

✅ Fixed: omitting wrap entirely (defaults to "soft")

<form>
  <label for="msg">Message</label>
  <textarea id="msg" name="msg"></textarea>
</form>

Since "soft" is the default, removing the attribute produces identical behavior and cleaner markup.

✅ Fixed: using wrap="hard" with cols

If you need the submitted text to include line breaks at wrap points, use wrap="hard" and specify cols:

<form>
  <label for="msg">Message</label>
  <textarea id="msg" name="msg" wrap="hard" cols="60" rows="6"></textarea>
</form>

Note that cols is required when using wrap="hard". Omitting it will trigger a separate validation error.

Other legacy values to watch for

The value "virtual" isn’t the only non-standard wrap value from the early web. You may also encounter wrap="physical" (the legacy equivalent of "hard") or wrap="off" (which disabled wrapping). Neither is valid in modern HTML. Replace "physical" with "hard" (and add cols), and replace "off" by removing the attribute and using CSS (white-space: nowrap; or overflow-wrap: normal;) to control visual wrapping if needed.

When you write an attribute like maxlength="200 and accidentally omit the closing quote, everything that follows — including subsequent attribute names and their values — gets absorbed into that one attribute’s value. In this case, the validator sees the value of maxlength as 200 aria-required= (or similar), which is not a valid integer. The parser doesn’t encounter a closing " until it finds the next quotation mark further along in the tag, causing a cascade of errors.

This is a problem for several reasons:

• Broken functionality: The maxlength attribute won’t work because 200 aria-required= is not a valid number. The browser cannot determine the intended character limit.
• Lost attributes: The aria-required attribute is swallowed into the malformed maxlength value, so it never gets applied as a separate attribute. Assistive technologies like screen readers won’t know the field is required.
• Accessibility impact: Since aria-required="true" is lost, users who rely on screen readers won’t receive the information that the field is mandatory, potentially leading to form submission errors and a frustrating experience.

The root cause is almost always a missing closing quotation mark. Carefully check that every attribute value has both an opening and a closing ". This kind of typo is easy to make and easy to miss, especially in long tags with many attributes.

Examples

Incorrect — missing closing quote on maxlength

The closing " after 200 is missing, so the value of maxlength extends all the way to the next quotation mark it finds:

<input type="text" name="nome" id="nome" maxlength="200 aria-required="true">

The validator interprets maxlength as having the value 200 aria-required=, and only true ends up as the value of an unintended or malformed attribute. Nothing works as expected.

Correct — properly quoted attributes

Each attribute has its own properly matched pair of quotation marks:

<input type="text" name="nome" id="nome" maxlength="200" aria-required="true">

Here, maxlength="200" correctly limits the input to 200 characters, and aria-required="true" is a separate attribute that tells assistive technologies the field is required.

Incorrect — missing closing quote with more attributes

This issue can happen with any combination of attributes. Here, a missing quote after maxlength absorbs class and placeholder:

<input type="text" maxlength="50 class="username" placeholder="Enter name">

Correct — all quotes properly closed

<input type="text" maxlength="50" class="username" placeholder="Enter name">

Tips for avoiding this issue

• Use a code editor with syntax highlighting. Most editors color attribute values differently from attribute names. If you see an attribute name rendered in the same color as a value string, a quote is likely missing.
• Format attributes one per line on complex elements. This makes it much easier to spot mismatched quotes:

<input
  type="text"
  name="nome"
  id="nome"
  maxlength="200"
  aria-required="true">

• Validate early and often. Running your HTML through the W3C validator regularly helps catch these small typos before they cause confusing bugs in production.

The device-width and device-height media features (along with their min- and max- prefixed variants) originally referred to the physical dimensions of the device’s entire screen, regardless of how much space was actually available to the document. In practice, this distinction caused confusion and inconsistent behavior across browsers. On most modern devices and browsers, device-width and width return the same value anyway, making the device-* variants redundant.

The device-* media features were frequently used as a proxy to detect mobile devices, but this was never a reliable approach. A narrow browser window on a desktop monitor would not trigger a max-device-width query even though the available layout space was small. Conversely, modern phones and tablets with high-resolution screens can report large device widths that don’t reflect the actual CSS viewport size. The viewport-based alternatives (width, height, aspect-ratio) more accurately represent the space available for rendering your content.

Using deprecated media features causes W3C validation warnings and may eventually lose browser support entirely. Replacing them ensures your stylesheets are future-proof, standards-compliant, and behave consistently across all devices and window sizes.

How to fix it

Replace any device-width, device-height, or device-aspect-ratio media feature (including min- and max- prefixed versions) with the corresponding viewport-based equivalent:

The width media feature describes the width of the viewport (the targeted display area of the output device), including the size of a rendered scroll bar if any. This is the value you almost always want when writing responsive styles.

Examples

Incorrect: using deprecated max-device-width

This triggers the validation error because max-device-width is deprecated:

<link rel="stylesheet" media="only screen and (max-device-width: 768px)" href="mobile.css">

Correct: using max-width instead

Replace max-device-width with max-width to query the viewport width:

<link rel="stylesheet" media="only screen and (max-width: 768px)" href="mobile.css">

Incorrect: using deprecated min-device-width in a range

<link rel="stylesheet" media="screen and (min-device-width: 768px) and (max-device-width: 1024px)" href="tablet.css">

Correct: using viewport-based equivalents

<link rel="stylesheet" media="screen and (min-width: 768px) and (max-width: 1024px)" href="tablet.css">

Incorrect: using deprecated device-aspect-ratio

<link rel="stylesheet" media="screen and (device-aspect-ratio: 16/9)" href="widescreen.css">

Correct: using aspect-ratio

<link rel="stylesheet" media="screen and (aspect-ratio: 16/9)" href="widescreen.css">

Applying the same fix in CSS @media rules

The same deprecation applies to @media rules inside stylesheets. While the W3C validator specifically flags the media attribute on <link> elements, you should update your CSS as well:

/* Deprecated */
@media only screen and (max-device-width: 768px) {
  .sidebar { display: none; }
}

/* Correct */
@media only screen and (max-width: 768px) {
  .sidebar { display: none; }
}

If your site relies on a <meta name="viewport"> tag (as most responsive sites do), the viewport width already matches the device’s CSS pixel width, so switching from device-width to width will produce identical results in virtually all cases.

The device-width, device-height, and device-aspect-ratio media features (including their min- and max- prefixed variants) refer to the physical dimensions of the entire screen, not the available space where your content is actually rendered. This distinction matters because the viewport size — the area your page occupies — can differ significantly from the full device screen size. For example, a browser window might not be maximized, or browser chrome might consume screen real estate. Using device-based queries means your responsive breakpoints may not match what users actually see.

These features were also commonly used as a proxy for detecting mobile devices, but this approach is unreliable. A small-screened laptop and a large tablet can have similar device widths, making device-based detection a poor heuristic. The W3C deprecated these features and recommends using viewport-based alternatives that more accurately reflect the rendering context of your document.

Beyond standards compliance, using deprecated media features can cause issues with future browser support. While current browsers still recognize them, there is no guarantee they will continue to do so. Replacing them now ensures your stylesheets remain functional and forward-compatible.

How to fix it

Replace each deprecated device-* media feature with its viewport-based equivalent:

The width media feature describes the width of the targeted display area of the output device. For continuous media, this is the width of the viewport including the size of a rendered scroll bar (if any). This is almost always the value you actually want when building responsive layouts.

Examples

Incorrect: using deprecated min-device-width

This triggers the validation error because min-device-width is deprecated:

<link rel="stylesheet" media="only screen and (min-device-width: 768px)" href="tablet.css">

Correct: using min-width instead

Replace min-device-width with min-width to query the viewport width:

<link rel="stylesheet" media="only screen and (min-width: 768px)" href="tablet.css">

Incorrect: using max-device-width for a mobile breakpoint

<link rel="stylesheet" media="screen and (max-device-width: 480px)" href="mobile.css">

Correct: using max-width

<link rel="stylesheet" media="screen and (max-width: 480px)" href="mobile.css">

Incorrect: using device-aspect-ratio

<link rel="stylesheet" media="screen and (device-aspect-ratio: 16/9)" href="widescreen.css">

Correct: using aspect-ratio

<link rel="stylesheet" media="screen and (aspect-ratio: 16/9)" href="widescreen.css">

Incorrect: combining multiple deprecated features

<link rel="stylesheet" media="screen and (min-device-width: 768px) and (max-device-width: 1024px)" href="tablet.css">

Correct: using viewport-based equivalents

<link rel="stylesheet" media="screen and (min-width: 768px) and (max-width: 1024px)" href="tablet.css">

The same replacements apply when these deprecated features appear in CSS @media rules or in the media attribute on <style> and <source> elements. Updating them across your entire codebase ensures consistent, standards-compliant responsive behavior.

The accept attribute provides browsers with a hint about which file types the user should be able to select through the file picker dialog. While browsers may still allow users to select other file types, the attribute helps filter the file picker to show relevant files first, improving the user experience.

The W3C validator reports this error when it encounters tokens in the accept attribute that don’t conform to the expected format. The attribute value is parsed as a set of comma-separated tokens, and each token must be one of the following:

• A valid MIME type such as application/pdf, text/plain, or image/png (the / character separating type and subtype is required).
• A file extension starting with a period, such as .pdf, .docx, or .jpg.
• One of three wildcard MIME types: audio/*, video/*, or image/*.

Common mistakes that trigger this error include using bare file extensions without the leading dot (e.g., pdf instead of .pdf), using arbitrary words that aren’t valid MIME types, or including spaces in a way that creates malformed tokens. The HTML specification (WHATWG) defines strict rules for how these tokens are parsed, and violating them produces a validation error.

Getting this attribute right matters for several reasons. First, a correctly specified accept attribute helps users by pre-filtering the file picker, so they don’t have to hunt through unrelated files. Second, assistive technologies may use this attribute to communicate accepted file types to users. Third, some browsers may silently ignore a malformed accept value entirely, removing the helpful filtering behavior you intended.

To fix the issue, review each token in your accept attribute and ensure it matches one of the three valid formats listed above. If you’re unsure of the correct MIME type for a file format, consult the IANA Media Types registry. When in doubt, dot-prefixed file extensions (like .pdf or .docx) are often simpler and more readable.

Examples

Incorrect: bare words without dots or MIME type format

<input type="file" name="document" accept="doc, docx, pdf">

The tokens doc, docx, and pdf are neither valid MIME types (no /) nor valid file extensions (no leading .), so the validator rejects them.

Incorrect: spaces creating malformed tokens

<input type="file" name="photo" accept="image/png, image/jpeg">

While most browsers handle spaces after commas gracefully, the validator may flag this depending on parsing. It’s safest to avoid spaces or keep them minimal.

Correct: using dot-prefixed file extensions

<input type="file" name="document" accept=".doc,.docx,.pdf">

Correct: using valid MIME types

<input type="file" name="document" accept="application/msword,application/vnd.openxmlformats-officedocument.wordprocessingml.document,application/pdf">

Correct: mixing MIME types, extensions, and wildcards

<input type="file" name="media" accept="image/*,.pdf,video/mp4">

This accepts all image types, PDF files, and MP4 videos. Mixing formats is perfectly valid as long as each token individually conforms to the specification.

Correct: using wildcard MIME types for broad categories

<input type="file" name="photo" accept="image/*">

This allows the user to select any image file, regardless of specific format.