HTML Guides for bad value

A field with the readonly attribute has an aria-readonly value that doesn't match it: remove aria-readonly and keep the native attribute.

aria-readonly only accepts true or false. A value such as TRUE, 1, undefined or readonly is neither, so the validator reports two errors on the same field: a Bad value error for aria-readonly, and this one, because the value differs from what readonly states. Values like these usually come from a template that prints a variable straight into the attribute, for example a boolean that the template language writes as 1 or True.

The readonly attribute already exposes the read-only state to assistive technologies, so the field doesn't need aria-readonly at all. Remove it. If you're building a custom widget that has no native readonly attribute, such as an element with role="textbox", write aria-readonly as exactly true or false.

Other values give different messages. aria-readonly="false" next to readonly is its own error, because it contradicts the native attribute. aria-readonly="true", or a value that exactly repeats the value of readonly (such as readonly="readonly" aria-readonly="readonly"), only gets a warning that the attribute is unnecessary.

Invalid example

<label for="account">Account ID</label>

<input type="text" id="account" name="account" value="AC-1042" readonly aria-readonly="1">

Valid example

<label for="account">Account ID</label>

<input type="text" id="account" name="account" value="AC-1042" readonly>

A field with the required attribute has an aria-required value that doesn't match it: remove aria-required and keep the native attribute.

aria-required only accepts true or false. A value such as yes, 1 or required is neither, so the validator reports two errors on the same field: a Bad value error for aria-required, and this one, because the value differs from what required states. These values usually come from copying the native attribute into the ARIA one, as in aria-required="required", or from a template that prints a boolean as 1 or True.

The required attribute already tells assistive technologies that the field must be filled in, and it turns on the browser's own form validation. The field doesn't need aria-required at all, so remove it. If you're building a custom widget that can't take required, such as an element with role="combobox", write aria-required as exactly true or false.

Other values give different messages. aria-required="false" next to required is its own error, because it contradicts the native attribute. aria-required="true", or a value that exactly repeats the value of required (such as required="required" aria-required="required"), only gets a warning that the attribute is unnecessary.

Invalid example

<label for="email">Email</label>

<input type="email" id="email" name="email" required aria-required="yes">

Valid example

<label for="email">Email</label>

<input type="email" id="email" name="email" required>

The itemscope attribute is part of the HTML Microdata specification, used to define the scope of structured data on a page. It works alongside itemtype and itemprop to provide machine-readable metadata about your content, which search engines and other tools can use to better understand your pages.

In HTML, boolean attributes follow a specific rule: their mere presence on an element represents a true state, and their absence represents false. Unlike JavaScript or other programming languages where you might write itemscope="true" or itemscope="false", HTML boolean attributes do not work this way. The only valid forms for a boolean attribute are:

• The attribute name alone: itemscope
• The attribute with an empty value: itemscope=""
• The attribute with its own name as the value: itemscope="itemscope"

Assigning any other value — including "true" or "false" — is invalid HTML. This is especially confusing because itemscope="false" does not disable the attribute. Since the attribute is still present on the element, the browser treats it as active. This can lead to incorrect structured data being generated, which may cause search engines to misinterpret your content.

This issue matters for several reasons:

• Standards compliance: Invalid attribute values violate the HTML specification, causing W3C validation errors.
• Structured data accuracy: Incorrect microdata markup can result in search engines misreading your page content, potentially affecting rich search results.
• Developer intent: Writing itemscope="false" suggests you want to disable the attribute, but it actually does the opposite — the attribute remains active.

To fix this, simply use the bare attribute name when you want it enabled, or remove it entirely when you don't.

Examples

Incorrect: assigning "true" to itemscope

<html itemscope="true" itemtype="https://schema.org/WebPage">

<!-- ... -->

</html>

Incorrect: assigning "false" to itemscope

This does not disable itemscope — the attribute is still present, so the browser treats it as active.

<div itemscope="false" itemtype="https://schema.org/Product">

<span itemprop="name">Widget</span>

</div>

Correct: using the bare attribute

<html itemscope itemtype="https://schema.org/WebPage">

<!-- ... -->

</html>

Correct: using an empty string value

This is an equally valid way to specify a boolean attribute, though the bare form is more common and readable.

<div itemscope="" itemtype="https://schema.org/Product">

<span itemprop="name">Widget</span>

</div>

Correct: removing the attribute entirely

If you don't need itemscope on the element, simply omit it.

<html lang="en">

<head>

<title>My Page</title>

</head>

<body>

<p>No microdata here.</p>

</body>

</html>

Correct: a complete example with microdata

<!DOCTYPE html>

<html lang="en" itemscope itemtype="https://schema.org/WebPage">

<head>

<title>My Product</title>

</head>

<body>

<div itemscope itemtype="https://schema.org/Product">

<h1 itemprop="name">Super Widget</h1>

<p itemprop="description">The best widget money can buy.</p>

</div>

</body>

</html>

This same rule applies to all HTML boolean attributes, such as hidden, disabled, checked, required, readonly, autoplay, and defer. None of them accept "true" or "false" as values — they are either present or absent.

When you write a phone link using <a href="callto:...">, you may encounter two distinct problems at once. First, the callto: scheme is a legacy, non-standard protocol originally associated with Skype. The correct and widely supported URI scheme for telephone links is tel:, as defined by RFC 3966. Second, spaces within URI scheme data are illegal characters. URIs must not contain unencoded spaces anywhere, and telephone URIs specifically expect a compact phone number composed of digits, hyphens (-), dots (.), and an optional leading plus sign (+) for international dialing.

The W3C validator raises this error because the value provided to href violates URI syntax rules. Browsers may still attempt to handle the link, but behavior will be inconsistent — some mobile browsers may not recognize callto: at all, and spaces in the URI can cause the number to be parsed incorrectly or truncated. Using the standard tel: scheme with a properly formatted number ensures the link works reliably across devices and platforms, including mobile phones, VoIP applications, and assistive technologies.

How to fix it

1. Replace callto: with tel: — The tel: scheme is the standard for phone number links and is supported by all modern browsers and mobile operating systems.
2. Remove spaces and slashes — Strip out any spaces, slashes, or parentheses from the phone number. These characters are not valid in a tel: URI without percent-encoding, and they serve no functional purpose in the link target.
3. Use a leading + for international numbers — If applicable, include the full international dialing code prefixed with + (e.g., +1 for the US, +49 for Germany). This makes the link work regardless of the caller's location.
4. Optional visual separators — If you want visual separators within the href for readability in your source code, use hyphens (-) or dots (.), which are permitted in tel: URIs. However, the simplest and safest approach is digits only (plus the optional leading +).

Examples

Incorrect: callto: with spaces and slashes

This triggers the validator error because spaces and slashes are illegal in URI scheme data, and callto: is non-standard.

<a href="callto:07142/ 12 34 5">Call us</a>

Incorrect: tel: with spaces

Even with the correct tel: scheme, spaces in the phone number are still invalid URI characters.

<a href="tel:07142 12 34 5">Call us</a>

Correct: tel: with digits only

<a href="tel:0714212345">Call us</a>

Correct: International number with + prefix

<a href="tel:+490714212345">Call us</a>

Correct: Using hyphens for readability

Hyphens are valid characters in tel: URIs and can improve source code readability without affecting functionality.

<a href="tel:+49-07142-12345">Call us</a>

Displaying a formatted number to the user

You can still show a human-friendly formatted number as the visible link text while keeping the href value clean and valid.

<a href="tel:+490714212345">+49 (0) 7142 / 12 34 5</a>

This approach gives you the best of both worlds: the link text is easy for users to read, and the href value is a valid, standards-compliant tel: URI that works reliably across all devices and passes W3C validation.

The autocomplete attribute helps browsers autofill form fields with previously saved user data. The HTML specification defines a strict set of valid values, and each one maps to a specific type of information (like a name, email address, phone number, or street address). The string "contact" by itself is not a valid autofill field name — it's a contact type token, which is a modifier meant to be combined with a field name to distinguish between different types of contact information.

The HTML spec defines two contact type tokens: "home", "work", "mobile", "fax", and "pager" (for phone-related fields), as well as the broader "shipping" and "billing" scoping tokens. The token "contact" doesn't exist as a standalone value at all. You may have confused it with a contact type prefix pattern like "home email" or "work tel", or you may have intended to use a specific field name entirely.

Getting the autocomplete value right matters for several reasons. Browsers rely on these exact tokens to offer relevant autofill suggestions. Screen readers and assistive technologies may also use this information to help users understand what data a field expects. An invalid value means the browser will likely ignore the attribute entirely, degrading the user experience — especially on mobile devices where autofill is heavily used.

To fix the issue, determine what kind of information the input field is collecting and use the appropriate autofill field name. Common valid values include "name", "email", "tel", "street-address", "postal-code", "organization", and "username". If you want to indicate that this is specifically a contact email or phone (as opposed to, say, a billing one), you don't use "contact" — instead, you can omit the modifier entirely or use a section-scoping approach.

Examples

❌ Invalid: Using "contact" as the autocomplete value

<label for="email">Contact Email</label>

<input type="email" id="email" name="email" autocomplete="contact">

The value "contact" is not a recognized autofill field name, so the browser cannot determine what to autofill.

✅ Fixed: Using a valid autofill field name

<label for="email">Contact Email</label>

<input type="email" id="email" name="email" autocomplete="email">

The value "email" is a valid autofill field name that tells the browser to suggest saved email addresses.

✅ Fixed: Using a valid combination with a section or contact type token

If you need to differentiate between types of phone numbers, you can use tokens like "home", "work", or "mobile" as prefixes:

<label for="work-tel">Work Phone</label>

<input type="tel" id="work-tel" name="work-tel" autocomplete="work tel">

<label for="home-email">Personal Email</label>

<input type="email" id="home-email" name="home-email" autocomplete="home email">

Common valid autocomplete values

Here are some frequently used valid autofill field names:

For the complete list of valid values and their permitted combinations, refer to the WHATWG autofill specification.

The lang attribute on any HTML element must be a valid IANA language subtag (like en, fr, or ja), not a programming language name.

The lang attribute specifies the natural (human) language of the element's content, used by browsers, screen readers, and search engines for accessibility and localization purposes. Values like csharp, javascript, or python are not valid because they are not human languages registered in the IANA Language Subtag Registry.

This issue commonly arises when using <code lang="csharp"> to indicate the programming language of a code snippet. While the intention makes sense, lang is not the right attribute for this purpose.

To indicate a programming language on a <code> element, the recommended convention from the HTML specification is to use the class attribute with a language- prefix (e.g., class="language-csharp"). This is also the pattern used by popular syntax highlighting libraries like Prism.js and highlight.js.

If the code content is written in a specific human language (like English), you can still use lang="en" alongside the class.

Bad Example

<pre>

<code lang="csharp">

Console.WriteLine("Hello, World!");

</code>

</pre>

Good Example

<pre>

<code class="language-csharp">

Console.WriteLine("Hello, World!");

</code>

</pre>

The HTML specification defines a set of implicit ARIA roles (also called "native semantics") for many HTML elements. The <dialog> element's implicit role is dialog, which means assistive technologies like screen readers already announce it correctly without any explicit ARIA markup. When you add role="dialog" to a <dialog> element, you're restating what the browser and accessibility tree already know—and the ARIA in HTML specification explicitly restricts this.

The ARIA in HTML spec maintains a list of allowed roles for each HTML element. For <dialog>, the only permitted role override is alertdialog (for dialogs that require an immediate response from the user). Setting role="dialog" is not listed as an allowed value because it duplicates the native semantics, and the spec treats such redundancy as a conformance error. This is why the W3C Validator reports: Bad value "dialog" for attribute "role" on element "dialog".

Why this matters

• Standards compliance: The W3C Validator enforces the ARIA in HTML specification, which prohibits redundant role assignments on elements that already carry that role implicitly. Valid markup ensures your pages conform to web standards.
• Accessibility clarity: While most assistive technologies handle redundant roles gracefully today, unnecessary ARIA attributes add noise to the codebase and can cause confusion about whether the element's native semantics are intentionally being overridden. The first rule of ARIA is: don't use ARIA if a native HTML element already provides the semantics you need.
• Maintainability: Removing redundant attributes keeps your HTML clean and easier to maintain. Future developers won't need to wonder whether the explicit role was added intentionally to work around a bug.

How to fix it

1. Locate any <dialog> element with a role="dialog" attribute.
2. Remove the role attribute entirely.
3. If you need the dialog to behave as an alert dialog (one that interrupts the user and demands immediate attention), use role="alertdialog" instead—this is the one permitted role override for <dialog>.

Examples

Incorrect — redundant role causes a validation error

<dialog role="dialog">

<h2>Confirm action</h2>

<p>Are you sure you want to proceed?</p>

<button>Cancel</button>

<button>Confirm</button>

</dialog>

Correct — relying on the implicit role

<dialog>

<h2>Confirm action</h2>

<p>Are you sure you want to proceed?</p>

<button>Cancel</button>

<button>Confirm</button>

</dialog>

The <dialog> element automatically exposes role="dialog" in the accessibility tree, so no explicit attribute is needed.

Correct — using an allowed role override

If the dialog represents an urgent alert that requires immediate user interaction, you can override the role with alertdialog:

<dialog role="alertdialog" aria-labelledby="alert-title" aria-describedby="alert-desc">

<h2 id="alert-title">Session expiring</h2>

<p id="alert-desc">Your session will expire in 60 seconds. Do you want to continue?</p>

<button>Stay signed in</button>

</dialog>

This is valid because alertdialog is explicitly listed as a permitted role for the <dialog> element in the ARIA in HTML specification. Note that aria-labelledby and aria-describedby are strongly recommended for alert dialogs so assistive technologies can announce the title and description properly.

The HTML <input> element's type attribute only accepts a specific set of predefined values defined in the HTML specification. These include values like text, password, email, number, date, datetime-local, checkbox, radio, and others. The value dob — presumably short for "date of birth" — is not among them.

When a browser encounters an invalid type value, it doesn't throw an error or prevent the page from loading. Instead, it treats the input as type="text". This means the input might appear to work, but you lose important benefits: there's no native date picker UI, no built-in date format validation, and no appropriate mobile keyboard. The W3C validator flags this to help you catch the mistake early.

This matters for several reasons:

• Accessibility: Valid input types provide semantic meaning to assistive technologies. A type="date" input tells screen readers that a date is expected, enabling better guidance for users.
• User experience: Native date inputs offer platform-appropriate date pickers on mobile and desktop, reducing input errors.
• Standards compliance: Using invalid attribute values produces unpredictable behavior across browsers and can break future compatibility.

To fix this issue, replace type="dob" with a recognized type. For a date of birth field, type="date" is the most appropriate choice. If you need more control over formatting, you can use type="text" with a JavaScript date picker library or custom validation.

Examples

❌ Invalid: using type="dob"

<label for="dob">Date of Birth:</label>

<input type="dob" id="dob" name="dob">

The browser will treat this as a plain text input, and the W3C validator will report: Bad value "dob" for attribute "type" on element "input".

✅ Fixed: using type="date"

<label for="dob">Date of Birth:</label>

<input type="date" id="dob" name="dob">

This uses the native HTML date input, which provides a built-in date picker in most modern browsers. You can also constrain the date range with min and max attributes:

<label for="dob">Date of Birth:</label>

<input type="date" id="dob" name="dob" min="1900-01-01" max="2025-12-31">

✅ Fixed: using type="text" with a JavaScript date picker

If you need more control over the date picker's appearance or need to support older browsers that lack native date input support, use type="text" and enhance it with JavaScript:

<label for="dob">Date of Birth:</label>

<input type="text" id="dob" name="dob" placeholder="YYYY-MM-DD">

You can then attach a JavaScript date picker library (such as Flatpickr, Pikaday, or a framework-specific component) to this input for a custom date selection experience. When using this approach, make sure to add appropriate aria-* attributes and validation to maintain accessibility.

Valid type values for reference

Here are some commonly used valid type values for the <input> element:

• text — plain text input
• date — date picker (year, month, day)
• datetime-local — date and time picker (no timezone)
• month — month and year picker
• number — numeric input
• email — email address input
• tel — telephone number input
• password — masked text input

Always choose the type that best matches the data you're collecting. For a date of birth, type="date" is the most semantically correct and user-friendly option.

A URL that starts with // needs a host name right after the two slashes, and this href has none.

An href such as //example.com/news is a scheme-relative URL. The browser keeps the scheme of the current page (http: or https:) and reads everything after the //, up to the next /, ? or #, as the host. In //?page=news, //#contact or a bare //, that part is empty. The URL Standard rejects a URL with no host, so the link has no valid destination.

The extra slash usually comes from a typo, or from a template that glued a base path ending in / onto a path starting with /. In that case the link was meant to be root-relative: /?page=news is the site's home page with a query string, and /#contact is an anchor on that page. Drop one slash and the error goes away. If the link goes to another site, put that site's host after the slashes, or write the full address, such as https://example.com/?page=news.

Invalid example

<nav>

<a href="//?page=news">News</a>

<a href="//#contact">Contact</a>

</nav>

Valid example

<nav>

<a href="/?page=news">News</a>

<a href="/#contact">Contact</a>

</nav>

The autocomplete attribute isn't a true/false switch: to turn autofill off on a <textarea>, write autocomplete="off", not autocomplete="false".

On a <textarea>, as on <input> and <select>, autocomplete takes either on or off, or autofill field names such as street-address that tell the browser what data the field expects. true and false belong to other attributes, like spellcheck and contenteditable, and the validator rejects autocomplete="true" too.

An invalid value doesn't fail safe. The HTML standard treats a value it can't parse as if the attribute weren't there, so the <textarea> falls back to its form's autocomplete setting. Unless the form says off, autofill stays on, which is the opposite of what false was meant to do.

With autocomplete="off", the browser should not save what the user types in the field or suggest values typed before. Browsers treat it as a request. The standard lets them allow users to override it, and most browsers ignore off on login fields so password managers keep working. On an ordinary message field, removing the attribute is also a valid fix.

If the goal was to stop the red underlines or the automatic corrections, those have their own attributes. spellcheck="false" turns off spelling and grammar checking, and autocorrect="off" tells the browser not to correct words as the user types. Watch the values: spellcheck takes true and false, but autocorrect takes on and off like autocomplete, so autocorrect="false" is also an error.

Invalid example

<form action="/contact" method="post">

<label for="message">Message</label>

<textarea id="message" name="message" rows="6" autocomplete="false"></textarea>

<button type="submit">Send</button>

</form>

Valid example

<form action="/contact" method="post">

<label for="message">Message</label>

<textarea id="message" name="message" rows="6" autocomplete="off"></textarea>

<button type="submit">Send</button>

</form>

To turn off spell checking and autocorrection instead:

<label for="snippet">Code snippet</label>

<textarea id="snippet" name="snippet" rows="6" spellcheck="false" autocorrect="off"></textarea>

The hidden attribute indicates that an element is not yet, or is no longer, relevant to the current state of the page. Browsers will not render elements that have this attribute. It's available on all HTML elements as a global attribute.

In HTML, boolean attributes like hidden, disabled, readonly, and checked follow special rules. Unlike attributes in programming languages where you might set a value to true or false, boolean attributes in HTML work by presence or absence:

• Present = the feature is on (e.g., hidden, hidden="", or hidden="hidden")
• Absent = the feature is off (the attribute is simply not in the markup)

This is a common source of confusion. Writing hidden="false" does not make the element visible. Because the attribute is still present in the markup, the browser interprets it as "this element is hidden." The actual string value "false" is ignored for the purpose of determining the boolean state. This can lead to frustrating bugs where elements remain invisible despite what looks like correct code.

According to the HTML specification, the only valid values for a boolean attribute are the empty string ("") or the attribute's own name (e.g., hidden="hidden"). Any other value, including "true" or "false", is invalid and will trigger a W3C validator error.

How the hidden attribute works with newer values

Starting with more recent updates to the HTML specification, the hidden attribute also accepts the value "until-found". When set to hidden="until-found", the element remains hidden but can be revealed by the browser's find-in-page feature or by fragment navigation. This is the only keyword value (besides the empty string and the attribute's canonical name) that changes the attribute's behavior. It does not change the fact that "false" is an invalid value.

How to fix it

• To hide an element, add the hidden attribute with no value.
• To show an element, remove the hidden attribute entirely from the markup.
• If you're toggling visibility with JavaScript, use element.hidden = false (the JavaScript property, not the HTML attribute) or element.removeAttribute('hidden').

Examples

❌ Invalid: setting hidden to "false"

<!-- The element is STILL hidden and the markup is invalid -->

<div hidden="false">You won't see this text.</div>

❌ Invalid: setting hidden to "true"

<!-- "true" is also not a valid value for a boolean attribute -->

<p hidden="true">This paragraph is hidden, but the markup is invalid.</p>

✅ Valid: using hidden without a value

<div hidden>This element is hidden from the page.</div>

✅ Valid: using hidden with an empty string or its own name

<!-- Both of these are valid ways to write boolean attributes -->

<div hidden="">Hidden element</div>

<div hidden="hidden">Also a hidden element</div>

✅ Valid: showing the element by omitting hidden

<div>This element is visible because it has no hidden attribute.</div>

✅ Valid: using hidden="until-found"

<div hidden="until-found">

This content is hidden but can be found via browser search.

</div>

Toggling visibility with JavaScript

When dynamically showing or hiding elements, use the hidden property on the DOM element rather than setting the attribute to "false":

<button type="button" id="toggle">Toggle message</button>

<p id="message" hidden>Hello! Now you can see me.</p>

<script>

document.getElementById("toggle").addEventListener("click", function () {

const msg = document.getElementById("message");

msg.hidden = !msg.hidden; // Correctly toggles the boolean property

});

</script>

Using msg.hidden = false in JavaScript correctly removes the hidden attribute from the element. This is different from writing hidden="false" directly in HTML, which keeps the attribute present and triggers the validation error.

The aria-controls attribute establishes a programmatic relationship between an interactive element (like a button or link) and the content it controls. Assistive technologies such as screen readers use this relationship to help users navigate between a control and the region it affects—for example, a button that toggles a panel or a tab that switches visible content. When the attribute is present but empty (aria-controls=""or aria-controls=" "), it signals a broken relationship: the browser and assistive technology expect a target element but find nothing.

This issue commonly occurs when aria-controls is added by a JavaScript framework or template before the target element's id is known, leaving behind an empty placeholder. It can also happen when a CMS or component library outputs the attribute unconditionally, even when no controlled region exists.

Why this matters

• Accessibility: Screen readers may announce that a control is associated with another element, but an empty reference leads nowhere. This creates a confusing or misleading experience for users who rely on assistive technology.
• Standards compliance: The HTML specification defines aria-controls as an IDREFS attribute, meaning its value must contain one or more space-separated tokens, each matching the id of an element in the same document. An empty value is invalid per both the WAI-ARIA specification and the HTML standard.
• Maintainability: Empty or placeholder ARIA attributes are a sign of incomplete implementation. They can mask bugs in dynamic UIs where the controlled element was supposed to be rendered but wasn't, or where an id was accidentally removed during refactoring.

How to fix it

1. If the element controls another region, set aria-controls to the id of that region. Make sure the target element exists in the DOM and has a unique id.
2. If the element doesn't control anything, remove the aria-controls attribute entirely. An absent attribute is always better than an empty one.
3. For dynamically rendered content, only add aria-controls after the target element and its id are present in the DOM. If using a framework, conditionally render the attribute.
4. Keep references in sync. If you rename or remove an id, update every aria-controls that references it.

Examples

Invalid: empty aria-controls

This triggers the validator error because the attribute value contains no id reference.

<a href="#" aria-controls="">Toggle details</a>

Invalid: whitespace-only value

A value with only spaces is also invalid—IDREFS requires at least one non-whitespace token.

<button type="button" aria-controls=" ">Open menu</button>

Fixed: provide a valid id reference

Point aria-controls to the id of the element being controlled.

<button type="button" aria-controls="details-panel" aria-expanded="false">

Toggle details

</button>

<div id="details-panel" hidden>

<p>Here are some additional details.</p>

</div>

Fixed: controlling multiple regions

You can reference multiple id values separated by spaces. Each id must correspond to an element in the document.

<button type="button" aria-controls="filters results">

Show filters and results

</button>

<section id="filters" hidden>

<p>Filter options...</p>

</section>

<section id="results" hidden>

<p>Search results...</p>

</section>

Fixed: remove the attribute when not needed

If the element doesn't actually control another region, simply omit aria-controls.

<a href="/details">View details</a>

Complete document with proper toggle behavior

This example shows a working toggle pattern combining aria-controls with aria-expanded for full accessibility.

<!doctype html>

<html lang="en">

<head>

<meta charset="utf-8">

<title>aria-controls Toggle Example</title>

</head>

<body>

<button type="button" aria-controls="info-panel" aria-expanded="false">

Toggle info

</button>

<div id="info-panel" hidden>

<p>Extra information goes here.</p>

</div>

<script>

const btn = document.querySelector('button');

const panel = document.getElementById('info-panel');

btn.addEventListener('click', () => {

const expanded = btn.getAttribute('aria-expanded') === 'true';

btn.setAttribute('aria-expanded', String(!expanded));

panel.hidden = expanded;

});

</script>

</body>

</html>

Conditional rendering in a framework

When using a templating system or JavaScript framework, only render aria-controls when the target id is available. Here's a conceptual example:

<!-- Good: only add the attribute when targetId has a value -->

<button type="button" aria-controls="sidebar-nav" aria-expanded="false">

Menu

</button>

<nav id="sidebar-nav" hidden>

<ul>

<li><a href="/">Home</a></li>

</ul>

</nav>

<!-- Bad: template outputs an empty value when targetId is undefined -->

<!-- <button type="button" aria-controls="">Menu</button> -->

In frameworks like React, you can conditionally spread the attribute: use aria-controls={targetId || undefined} so that when the value is empty, the attribute is omitted from the rendered HTML entirely rather than being set to an empty string.

The dir attribute on the <div> is set to an empty string. dir is an enumerated attribute that only accepts ltr, rtl, or auto, so an empty value is invalid.

The attribute sets the base text direction of an element's content: ltr for left-to-right scripts such as English, rtl for right-to-left scripts such as Arabic or Hebrew, and auto to let the browser decide from the first strongly typed character. An empty dir="" names none of these, so the browser has nothing to apply.

This normally comes from a template that prints dir="" when the variable feeding it is blank. If the element does not need an explicit direction, remove the attribute and it will inherit the direction of its parent. Otherwise, set one of the three valid values.

Invalid example

<div dir="">Welcome</div>

Valid example

Remove the attribute to inherit the direction from the parent:

<div>Welcome</div>

Or set a valid value. Use auto when the text comes from users and its direction is not known in advance:

<div dir="auto">مرحبا</div>

The dir attribute on an <input> element is set to an empty string, and dir only accepts ltr, rtl or auto.

dir sets the direction of the text inside the field. The HTML standard treats an empty or unknown value as if the attribute were missing, so the input takes its direction from its parent and dir="" changes nothing. A bare dir with no value counts as empty too, and gets the same error.

A template that fills dir from the page language can print it empty for left-to-right languages. If the field should follow the page direction, remove the attribute. If people may type in a right-to-left script such as Arabic or Hebrew, which is common in search boxes, use dir="auto" and the browser sets the direction from the first letter typed. Add dirname when the server needs that direction too. The form then submits it as an extra field, such as q.dir=rtl.

Invalid example

<form action="/search">

<input type="search" name="q" aria-label="Search" dir="">

</form>

Valid example

Remove the attribute so the field follows the page direction:

<form action="/search">

<input type="search" name="q" aria-label="Search">

</form>

Or let the field follow the text the user types:

<form action="/search">

<input type="search" name="q" aria-label="Search" dir="auto" dirname="q.dir">

</form>

The dir attribute on a <meta> element is set to an empty string, and dir only accepts ltr, rtl or auto.

dir is a global attribute, so <meta> may carry it. On a <meta> with human-readable content, such as a page description, it sets the direction of that text. An empty dir="" names no direction, so the validator rejects it. Remove the attribute if the text reads in the same direction as the page, or set rtl, ltr or auto if it doesn't.

Often nobody wrote that dir on purpose. A double quote inside the content value closes the attribute early, and the browser reads each word after it as a separate attribute with an empty value. If one of those words is "dir", you get this error, along with an "Attribute not allowed" error for each of the other words. A CMS or template that copies an excerpt into a description or og:description tag without escaping it produces exactly this. Write double quotes inside the value as ", or strip them before printing the tag.

Invalid example

<meta name="description" content="Opening hours and contact details" dir="">

Valid example

<meta name="description" content="Opening hours and contact details">

Invalid example with an unescaped quote

<meta name="description" content="How the "auto" value of the dir attribute picks a text direction">

Valid example with the quote escaped

<meta name="description" content="How the &quot;auto&quot; value of the dir attribute picks a text direction">

In a URL, the # character has a special role: it acts as the delimiter that separates the main URL from the fragment identifier. The fragment typically points to a specific section or element within the target document, often corresponding to an element's id attribute. Because # serves this reserved purpose, it cannot appear more than once in its raw form within a URL. When the validator encounters something like ##pricing or section#one#two, it flags the extra # characters as illegal.

This issue usually arises from one of these common scenarios:

• Typos — accidentally typing ## instead of #.
• String concatenation bugs — building URLs programmatically where a # is included both in the base URL and prepended to the fragment value.
• Copy-paste errors — duplicating the # when copying URLs from browser address bars or other sources.
• Literal # intended in fragment — if you genuinely need a # symbol within the fragment text, it must be percent-encoded as %23.

This matters because browsers may handle malformed URLs inconsistently. Some browsers silently strip the extra #, while others may fail to navigate to the intended fragment. Malformed URLs also cause problems for assistive technologies, web crawlers, and any tooling that parses links. Keeping your URLs well-formed ensures predictable behavior across all user agents and complies with the URL Standard and HTML specification.

Examples

Incorrect: duplicate # in the URL

The double ## makes the fragment identifier invalid:

<a href="https://example.com/faqs##pricing">Pricing</a>

Correct: single # delimiter

Remove the extra # so that pricing is the fragment:

<a href="https://example.com/faqs#pricing">Pricing</a>

Incorrect: extra # inside the fragment

Here, the fragment portion overview#details contains a raw #, which is not allowed:

<a href="/docs#overview#details">Details</a>

Correct: percent-encode the literal #

If you truly need a # as part of the fragment text, encode it as %23:

<a href="/docs#overview%23details">Details</a>

In most cases though, this pattern suggests the URL structure should be rethought. A cleaner approach is to link directly to the intended fragment:

<a href="/docs#details">Details</a>

Incorrect: programmatic concatenation error

A common bug in templates or JavaScript is prepending # when the variable already includes it:

<!-- If defined as defined as fragment = "#pricing", this produces a double ## -->

<a href="https://example.com/faqs#pricing">Pricing</a>

Correct: ensure only one # is present

Make sure either the base URL or the fragment variable includes the #, but not both:

<a href="https://example.com/faqs#pricing">Pricing</a>

Fragment-only links

Fragment-only links (links to sections within the same page) follow the same rule — only one #:

<!-- Incorrect -->

<a href="##contact">Contact Us</a>

<!-- Correct -->

<a href="#contact">Contact Us</a>

A | (pipe) character in the fragment portion of a URL must be percent-encoded as %7C to be valid.

The href attribute on an <a> element must contain a valid URL. According to the URL specification, certain characters — including the pipe | — are not permitted as literal characters in a URL fragment (the part after #). The W3C validator flags this because the browser may handle it inconsistently, and it violates the URL standard.

To fix it, replace every | in the URL with its percent-encoded equivalent: %7C.

HTML Examples

❌ Invalid: literal pipe in fragment

<a href="https://example.com/page#section|one">Link</a>

✅ Valid: percent-encoded pipe in fragment

<a href="https://example.com/page#section%7Cone">Link</a>

If you control the target page, consider redesigning the fragment identifiers to avoid special characters altogether — for example, using hyphens or underscores like #section-one instead.

A URL fragment identifier is the part of a URL that follows the # character. It typically points to an element on the page that has a matching id attribute. According to the URL specification, certain characters — including spaces — are not allowed to appear literally in a URL. When the W3C HTML Validator encounters a raw space in a fragment, it reports this as an illegal character.

This issue matters for several reasons. Browsers may handle unescaped spaces in fragments inconsistently, leading to broken in-page navigation. Screen readers and other assistive technologies rely on well-formed URLs to navigate users to the correct section of a page. Additionally, spaces in id attributes are themselves invalid in HTML — the id attribute must not contain any ASCII whitespace characters. So the root cause often involves two separate violations: an invalid id and an invalid fragment URL.

The best approach is to use hyphens (-) or underscores (_) instead of spaces in your id values, then match the fragment accordingly. This produces clean, readable, and shareable URLs (e.g., page.html#contact-info instead of page.html#contact%20info). If you're working with a CMS or build tool that auto-generates id values with spaces, configure it to produce hyphen-separated, lowercase identifiers instead.

If you absolutely cannot change the id values (e.g., they're generated by a third-party system), you can percent-encode the spaces as %20 in the href. This satisfies URL syntax rules, but note that an id containing spaces is still invalid HTML on its own. Fixing the id is always the preferred solution.

Examples

Invalid: space in fragment and id

This triggers the validator error because href="#My Section" contains an unescaped space. The id="My Section" is also invalid HTML since id values cannot contain spaces.

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

<h2 id="My Section">My Section</h2>

Fixed: hyphen-separated fragment and id

Replace spaces with hyphens in both the id and the fragment. This is the cleanest and most widely recommended approach.

<a href="#my-section">Go to section</a>

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

Fixed: underscore-separated fragment and id

Underscores work equally well if you prefer that convention.

<a href="#my_section">Go to section</a>

<h2 id="my_section">My Section</h2>

Alternative: percent-encoding the space

Encoding the space as %20 resolves the fragment URL error, but the id with a space is still invalid HTML. Use this only as a last resort when you cannot control the id values.

<a href="#My%20Section">Go to section</a>

<!-- Note: this id is still invalid HTML due to the space -->

<h2 id="My Section">My Section</h2>

Full valid document

A complete example demonstrating multiple in-page links with properly formatted fragments and id values:

<!doctype html>

<html lang="en">

<head>

<title>Page sections</title>

</head>

<body>

<nav>

<ul>

<li><a href="#getting-started">Getting Started</a></li>

<li><a href="#advanced-usage">Advanced Usage</a></li>

<li><a href="#frequently-asked-questions">FAQ</a></li>

</ul>

</nav>

<h2 id="getting-started">Getting Started</h2>

<p>Introduction content here.</p>

<h2 id="advanced-usage">Advanced Usage</h2>

<p>Advanced content here.</p>

<h2 id="frequently-asked-questions">Frequently Asked Questions</h2>

<p>FAQ content here.</p>

</body>

</html>

The href of an <a> element has a literal space in its URL path, and the URL is too long for the validator to quote in the message.

A valid URL has no literal spaces. In the path (the part after the domain and before any ? or #), a space has to be percent-encoded as %20. Browsers encode the space themselves when someone follows the link, so the link often works, but the href is still not a valid URL.

The validator usually prints the bad value between Bad value and for attribute. When the value is 200 characters or longer, it leaves the value out, which is why this message has nothing between them. Values that long tend to come from file names written as whole sentences, or from a block of text pasted into a link field by mistake. To find the link, check the source line shown with the issue, or search the page source for href values that contain spaces.

The fix is the same as for a short URL: replace each space with %20. If you control the file, a short name with hyphens instead of spaces, such as annual-report.pdf, is easier to link to. If the href holds text that was never meant to be a URL, put the right address back in the link.

Invalid example

<a href="/downloads/reports/Annual report on community health programs and volunteer outreach in the northern region with survey results, budget breakdown and recommendations for the next two financial years.pdf">

Download the annual report

</a>

Valid example

<a href="/downloads/reports/Annual%20report%20on%20community%20health%20programs%20and%20volunteer%20outreach%20in%20the%20northern%20region%20with%20survey%20results,%20budget%20breakdown%20and%20recommendations%20for%20the%20next%20two%20financial%20years.pdf">

Download the annual report

</a>

URLs follow strict syntax rules defined by RFC 3986. Only a specific set of characters are allowed directly in a URL path segment — these include letters, digits, hyphens (-), periods (.), underscores (_), and tildes (~), along with a handful of sub-delimiters like !, $, &, ', (, ), *, +, ,, ;, and =. Any character outside this set — including spaces, angle brackets (< >), curly braces ({ }), pipe characters (|), backslashes (\), carets (^), and backticks (`) — must be percent-encoded.

Percent-encoding replaces the character with a % sign followed by its two-digit hexadecimal ASCII code. For example:

This validation error matters for several reasons. First, browsers may handle illegal characters inconsistently — some may silently encode them, while others may break the link or navigate to an unexpected destination. Second, tools that parse HTML (screen readers, search engine crawlers, link checkers) rely on well-formed URLs and may fail or behave unpredictably when they encounter illegal characters. Third, standards compliance ensures your HTML works reliably across all environments.

Common causes of this error include:

• Copying and pasting URLs from documents or emails that contain unencoded spaces or special characters.
• Template variables or placeholders left in href values (e.g., {{url}}).
• File paths with spaces used directly as URLs without encoding.
• Non-ASCII characters in URLs that haven't been properly encoded.

Examples

❌ Space in the URL path

<a href="/my page/about us.html">About Us</a>

✅ Spaces percent-encoded as %20

<a href="/my%20page/about%20us.html">About Us</a>

❌ Curly braces from a template placeholder left in the markup

<a href="/products/{{product-id}}/details">View Details</a>

✅ Curly braces replaced with an actual value

<a href="/products/42/details">View Details</a>

❌ Pipe character in the path

<a href="/search/color|size">Filter Results</a>

✅ Pipe character percent-encoded as %7C

<a href="/search/color%7Csize">Filter Results</a>

❌ Angle brackets in the URL

<a href="/page/<section>">Go to Section</a>

✅ Angle brackets percent-encoded

<a href="/page/%3Csection%3E">Go to Section</a>

How to Fix

1. Identify the illegal character from the validator's error message — it typically tells you exactly which character is problematic.
2. Replace it with the correct percent-encoded equivalent using the table above or a URL encoder tool.
3. If the URL contains template syntax (like {{...}}), make sure your templating engine processes it before the HTML is served to the browser. The raw template syntax should never appear in the final rendered HTML.
4. Consider renaming files and directories to avoid spaces and special characters altogether — this is the cleanest long-term solution.

If you're generating URLs programmatically, use built-in encoding functions like JavaScript's encodeURIComponent() or PHP's rawurlencode() to ensure all special characters are properly escaped before inserting them into href attributes.

The href attribute on an <a> element contains a literal pipe character (|), which is not a valid character in a URL according to RFC 3986.

URLs have a defined set of allowed characters. The pipe character (|) is not among them. While most browsers will silently encode the pipe and follow the link anyway, the HTML specification requires that href values contain valid URLs. Characters outside the allowed set must be percent-encoded before being placed in the markup.

The percent-encoded form of | is %7C. Replace every literal | in the URL with %7C to produce a valid href value.

HTML examples

Invalid

<a href="https://example.com/search?fields=name|date|status">Search</a>

Valid

<a href="https://example.com/search?fields=name%7Cdate%7Cstatus">Search</a>

A space character in the href attribute of an <a> element is not valid in a URL. Spaces must be encoded as %20 in the query string.

URLs follow the syntax defined in RFC 3986, which does not allow literal space characters anywhere in the URL. When the W3C validator encounters a space in a query string, it flags the href value as malformed. Browsers often handle this gracefully by encoding the space automatically, but the HTML itself is still invalid.

The query component of a URL (everything after the ?) follows the same rule. If a value in the query string contains a space, replace each space with %20. An alternative encoding, +, is specific to the application/x-www-form-urlencoded format used by HTML form submissions, and is also accepted in practice by most servers. However, %20 is the universally correct percent-encoding for a space in any part of a URL.

Invalid example

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

The space between hello and world causes the validation error.

Valid example

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

Every space in the URL is replaced with %20, and the markup passes validation.

The W3C HTML Validator checks that URLs in href attributes conform to the URL standard (defined by WHATWG). While square brackets are permitted in the host component of a URL (to support IPv6 addresses like [::1]), they are not valid unescaped characters in the query string — the part of the URL that comes after the ?. When the validator encounters a literal [ or ] in the query portion, it flags it as an illegal character.

This issue commonly arises when working with APIs or server-side frameworks that use square brackets in query parameters to represent arrays or nested data structures. For example, PHP-style query strings like ?filter[name]=foo or ?ids[]=1&ids[]=2 contain brackets that must be encoded for valid HTML.

Why this matters

• Standards compliance: The WHATWG URL Standard explicitly lists square brackets among the characters that must be percent-encoded in query strings. Invalid URLs cause W3C validation failures.
• Browser behavior: While most modern browsers are forgiving and will often handle unescaped brackets correctly, relying on this lenient parsing is fragile. Some HTTP clients, proxies, or intermediary servers may reject or mangle URLs with illegal characters.
• Interoperability: Encoded URLs are safer when copied, shared, or processed by tools like link checkers, web scrapers, or email clients that may perform strict URL parsing.

How to fix it

Replace every literal square bracket in the query string with its percent-encoded form:

If you're generating URLs dynamically in a server-side language or JavaScript, use the appropriate encoding function (e.g., encodeURIComponent() in JavaScript, urlencode() in PHP, or urllib.parse.quote() in Python) to handle this automatically.

Examples

Incorrect: literal brackets in the query string

<a href="https://example.com/search?filter[status]=active">Active items</a>

This triggers the validation error because [ and ] appear unescaped in the query.

Correct: percent-encoded brackets

<a href="https://example.com/search?filter%5Bstatus%5D=active">Active items</a>

Replacing [ with %5B and ] with %5D resolves the error. The server receiving this request will decode the values back to filter[status]=active.

Incorrect: array-style parameters with brackets

<a href="/api/items?ids[]=1&ids[]=2&ids[]=3">Load items</a>

Correct: array-style parameters encoded

<a href="/api/items?ids%5B%5D=1&amp;ids%5B%5D=2&amp;ids%5B%5D=3">Load items</a>

Note that in addition to encoding the brackets, the & characters in HTML attributes should be written as & for fully valid markup.

Incorrect: brackets in a simple value

<a href="search.html?q=[value]">Search</a>

Correct: encoded brackets in a simple value

<a href="search.html?q=%5Bvalue%5D">Search</a>

Note on brackets in the host (valid use)

Square brackets are valid in the host portion of a URL for IPv6 addresses. The following does not trigger the error:

<a href="http://[::1]:8080/page">IPv6 localhost</a>

The validator only flags brackets that appear in the query string or other parts of the URL where they are not permitted.

The W3C HTML Validator raises this error when it encounters a backslash character (\) inside the href attribute of an anchor element. According to the WHATWG URL Standard, backslashes are not valid characters in URL scheme data. URLs are defined with forward slashes (/) as delimiters — this applies to all parts of a URL, including the scheme, authority, path, query, and fragment.

This issue most commonly occurs when developers copy file paths from Windows operating systems, where backslashes are the default path separator (e.g., C:\Users\Documents\file.html), and paste them directly into HTML markup. It can also happen when server-side code generates URLs using OS-level path functions that produce backslashes on Windows.

Why this matters

• Standards compliance: The WHATWG URL Standard explicitly forbids backslashes in scheme data. Validators flag this as an error because the resulting URL is malformed.
• Cross-browser inconsistency: While some browsers may silently correct backslashes to forward slashes, this behavior is not guaranteed across all browsers or versions. Relying on browser error correction leads to fragile code.
• Broken links: Certain browsers, HTTP clients, or intermediary servers may not auto-correct the backslash, causing the link to fail entirely — resulting in 404 errors or unexpected navigation.
• Security concerns: Backslashes in URLs can be exploited in certain attack vectors like open redirects or path traversal attacks. Using well-formed URLs reduces the attack surface.

How to fix it

1. Replace all backslashes (\) with forward slashes (/) in your href values.
2. Check for URL generation in server-side code. If your application builds URLs programmatically, ensure it uses forward slashes regardless of the host operating system.
3. Use relative or absolute URLs consistently. Whether the URL is relative (images/photo.jpg) or absolute (https://example.com/images/photo.jpg), always use forward slashes.

Examples

Incorrect: backslashes in a relative path

<a href="pages\about\team.html">Meet the Team</a>

Correct: forward slashes in a relative path

<a href="pages/about/team.html">Meet the Team</a>

Incorrect: backslashes in an absolute URL

<a href="https://example.com\blog\2024\post.html">Read the Post</a>

Correct: forward slashes in an absolute URL

<a href="https://example.com/blog/2024/post.html">Read the Post</a>

Incorrect: Windows file path pasted directly

<a href="assets\downloads\report.pdf">Download Report</a>

Correct: converted to a proper relative URL

<a href="assets/downloads/report.pdf">Download Report</a>

Incorrect: mixed slashes

Sometimes a URL contains a mix of forward and backslashes, which also triggers this error:

<a href="https://example.com/images\photos\sunset.jpg">View Photo</a>

Correct: all forward slashes

<a href="https://example.com/images/photos/sunset.jpg">View Photo</a>

A quick way to audit your HTML files is to search for \ within any href (or src, action, etc.) attribute values and replace them with /. In most code editors, you can use find-and-replace scoped to attribute values to handle this efficiently.

URLs follow strict syntax rules defined by RFC 3986. Within the path segment of a URL, only a specific set of characters is allowed: unreserved characters (letters, digits, -, ., _, ~), percent-encoded characters (like %20), and certain reserved sub-delimiters. When the W3C validator encounters a character outside this allowed set in a <link> element's href attribute, it flags the error.

Common causes of this issue include:

• Template placeholders left in the URL, such as {{variable}} or ${path}, where curly braces and dollar signs haven't been resolved or encoded.
• Spaces in file paths, such as href="styles/my file.css" instead of using %20 or renaming the file.
• Copy-paste errors that introduce invisible or special Unicode characters.
• Backslashes (\) used instead of forward slashes (/), which is a common mistake on Windows systems.
• Unencoded query-like characters placed in the path portion of the URL.

This matters because browsers may interpret malformed URLs inconsistently. A URL that works in one browser might fail in another. Additionally, invalid URLs can break resource loading, cause accessibility issues when assistive technologies try to process the document, and lead to unexpected behavior with proxies, CDNs, or other intermediaries that strictly parse URLs.

To fix the issue, inspect the href value reported in the error and either:

1. Remove the illegal character if it was included by mistake.
2. Percent-encode the character if it must be part of the URL (e.g., a space becomes %20, a pipe | becomes %7C).
3. Rename the referenced file or directory to avoid special characters altogether (the simplest and most reliable approach).

Examples

Incorrect: Space in the path

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

The space character is not allowed in a URL path segment. The validator will flag this as an illegal character.

Fixed: Percent-encode the space

<link rel="stylesheet" href="styles/my%20styles.css">

Better fix: Rename the file to avoid spaces

<link rel="stylesheet" href="styles/my-styles.css">

Incorrect: Template placeholder left unresolved

<link rel="stylesheet" href="styles/{{theme}}/main.css">

Curly braces { and } are not valid in URL path segments. This commonly happens with server-side or client-side templating syntax that wasn't processed before the HTML was served.

Fixed: Use a valid resolved path

<link rel="stylesheet" href="styles/dark/main.css">

Incorrect: Backslash used as path separator

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

Backslashes are not valid URL characters. URLs always use forward slashes.

Fixed: Use forward slashes

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

Incorrect: Pipe character in the URL

<link rel="stylesheet" href="styles/font|icon.css">

Fixed: Percent-encode the pipe character

<link rel="stylesheet" href="styles/font%7Cicon.css">

Full valid document example

<!DOCTYPE html>

<html lang="en">

<head>

<meta charset="utf-8">

<title>My Webpage</title>

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

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

</head>

<body>

<h1>Welcome to my webpage!</h1>

<p>Here is some content.</p>

</body>

</html>

When in doubt, run your URL through a URL encoder or validator separately to confirm all characters are legal. As a general best practice, stick to lowercase letters, digits, hyphens, and forward slashes in your file and directory names—this avoids encoding issues entirely and makes your URLs clean and predictable.