HTML Guides

Bad value https://www.w3.org/1998/Math/MathML for the attribute xmlns (only http://www.w3.org/1998/Math/MathML permitted here).

Namespace URIs in XML (and by extension in HTML) are identifiers, not actual URLs that a browser fetches. The W3C and WHATWG specifications define http://www.w3.org/1998/Math/MathML as the one and only valid namespace for MathML. Even though http:// and https:// point to the same server in practice, they are different strings — and namespace matching is purely a string comparison. Using https://www.w3.org/1998/Math/MathML creates what the spec considers an entirely different (and unrecognized) namespace.

This is a common mistake because modern best practices encourage using https:// for everything on the web. However, these namespace URIs were standardized long before HTTPS became the norm, and changing them would break backward compatibility across the entire XML ecosystem. The spec is explicit: only http://www.w3.org/1998/Math/MathML is permitted.

How to Fix It

You have two options depending on your document type:

HTML5 (recommended): Simply remove the xmlns attribute from the <math> element. The HTML5 parser recognizes <math> and automatically places it in the correct MathML namespace. No explicit declaration is needed.
XHTML or XML documents: If you're serving your document as application/xhtml+xml or working in an XML context where explicit namespaces are required, use the exact URI http://www.w3.org/1998/Math/MathML with http://.

The same rule applies to other well-known namespaces like SVG (http://www.w3.org/2000/svg) and XHTML (http://www.w3.org/1999/xhtml) — always use the http:// form specified in the standard.

Examples

Invalid: using `https://` in the namespace URI

The https:// scheme causes the validation error:

</math>

Fixed: omit `xmlns` in HTML5

In an HTML5 document, the parser handles the namespace automatically, so the cleanest fix is to drop xmlns altogether:

<!DOCTYPE html>

<head>

<title>MathML Example</title>

</head>

<body>

<math>

</math>

</body>

</html>

Fixed: use the correct `http://` URI

If you need to explicitly declare the namespace (for example, in XHTML served as XML), use the exact http:// URI:

</math>

Quick comparison

Code	Valid?
`<math xmlns="https://www.w3.org/1998/Math/MathML">`	❌ Wrong scheme
`<math xmlns="http://www.w3.org/1998/Math/MathML">`	✅ Correct URI
`<math>` (in HTML5)	✅ Namespace implied

Bad value “https://www.w3.org/1999/xlink” for the attribute “xmlns:link” (only “http://www.w3.org/1999/xlink” permitted here).

XML namespaces are identified by URI strings that act as unique names. They are never fetched or loaded by the browser — they simply serve as an identifier that must match exactly what the specification defines. The XLink namespace has been defined as http://www.w3.org/1999/xlink since its inception, and changing the protocol to https creates a completely different string that parsers and validators do not recognize.

It's a common and understandable mistake. Developers are trained to prefer https:// URLs everywhere for security, and many linting tools or habits may encourage automatically converting http:// to https://. However, namespace URIs are a special case where this rule does not apply. The string is purely declarative — no network request is made, and no security benefit comes from using https.

It's also worth noting that the xmlns:xlink attribute is largely obsolete in modern HTML. When SVG is embedded directly in an HTML5 document, browsers automatically handle namespace resolution. You only need xmlns:xlink when serving SVG as standalone XML (with an .svg file or application/xhtml+xml content type). In most cases, you can simply remove the attribute altogether and use xlink:href or, even better, the plain href attribute, which is now supported on SVG elements like <use>, <image>, and <a>.

Examples

Incorrect: using `https://` in the namespace URI

</svg>

This triggers the validation error because https://www.w3.org/1999/xlink does not match the required namespace identifier.

Fixed: using the correct `http://` namespace URI

</svg>

Preferred: removing the namespace and using plain `href`

In HTML5, you can drop the xmlns:xlink declaration entirely and use the standard href attribute instead of xlink:href:

</svg>

This is the cleanest approach for inline SVG in modern HTML documents. The xlink:href attribute is deprecated in SVG 2, and all modern browsers support plain href on SVG linking elements.

Bad value “https://www.w3.org/2000/svg” for the attribute “xmlns” (only “http://www.w3.org/2000/svg” permitted here).

An XML namespace URI is a unique identifier, not an actual web address that your browser fetches. The SVG namespace was defined as http://www.w3.org/2000/svg in the original SVG specification, and that exact string is what HTML parsers and validators expect. Even though using https everywhere is a best practice for real network requests, namespace URIs are not network requests — they are simply fixed strings used to identify which XML vocabulary an element belongs to.

When you write https://www.w3.org/2000/svg instead of http://www.w3.org/2000/svg, the validator sees an unrecognized namespace. This can also cause problems in certain XML-based contexts (such as XHTML or standalone SVG files), where the browser may fail to recognize the element as SVG at all, resulting in your graphics not rendering. In standard HTML5 mode, most browsers will still render inline SVGs correctly regardless of the xmlns value, but the markup is technically invalid and may cause issues in stricter parsing environments like XML serializers, server-side renderers, or tools that process SVG as XML.

This mistake is especially common because many developers reflexively change http to https — or their editor or linter automatically does — when they see a URL-like string. The same principle applies to other namespace URIs like http://www.w3.org/1999/xhtml for HTML and http://www.w3.org/1998/Math/MathML for MathML. These are all fixed identifiers that must not be altered.

How to Fix It

Replace https:// with http:// in the xmlns attribute value. That's it — no other changes are needed.

If your project uses automated tooling that rewrites http URLs to https, you may need to configure an exception for XML namespace URIs.

Examples

❌ Incorrect: Using `https` in the namespace URI

</svg>

This triggers the validation error because https://www.w3.org/2000/svg is not a recognized namespace value.

✅ Correct: Using `http` in the namespace URI

</svg>

✅ Correct: Inline SVG in HTML without `xmlns`

When embedding SVG directly inside an HTML5 document, the xmlns attribute is optional — the HTML parser automatically assigns the correct namespace to <svg> elements:

</svg>

This is perfectly valid HTML5. You only need the xmlns attribute when the SVG is served as a standalone .svg file or used within an XHTML document.

Bad value “icon” for attribute “role” on element “span”.

The WAI-ARIA specification defines a specific set of role values that assistive technologies like screen readers understand. These include roles such as button, checkbox, alert, dialog, img, navigation, banner, and many others. The value "icon" is not among them. When a browser or assistive technology encounters an unrecognized role, it cannot determine the element's purpose, which defeats the goal of using ARIA in the first place.

This is primarily an accessibility problem. Screen readers rely on valid ARIA roles to communicate the nature of elements to users. An invalid role like "icon" is either ignored or causes unpredictable behavior, leaving users of assistive technologies without the context they need. It's also a standards compliance issue — the W3C validator flags this because the HTML specification requires role values to match roles defined in the ARIA specification.

The fix depends on the purpose of the element:

Decorative icons (that don't convey information): Remove the role attribute entirely, or use aria-hidden="true" to explicitly hide the element from the accessibility tree.
Meaningful icons (that convey information visually): Use role="img" along with an aria-label to provide a text alternative.
Icons inside interactive elements: Hide the icon with aria-hidden="true" and ensure the parent interactive element has an accessible name through visible text or an aria-label.

Examples

❌ Invalid: Using the non-existent `"icon"` role

This triggers the validation error because "icon" is not a valid ARIA role.

✅ Fixed: Decorative icon with no role

If the icon is purely decorative and doesn't convey any meaning (e.g., it's next to text that already describes the action), simply remove the role attribute. Adding aria-hidden="true" ensures screen readers skip over it completely.

✅ Fixed: Meaningful icon using `role="img"`

If the icon conveys meaningful information that isn't available through surrounding text, use role="img" and provide a descriptive aria-label:

This tells assistive technologies that the element represents an image and gives it an accessible name of "Warning."

✅ Fixed: Icon inside a button

When an icon is placed inside an interactive element like a button, hide the icon from the accessibility tree and let the button's text or label provide the meaning:

Save

</button>

If the button has no visible text (an icon-only button), provide an aria-label on the button itself:

</button>

✅ Fixed: Icon using an `<img>` element instead

If you're using an actual image file for the icon, consider using a semantic <img> element, which has a built-in img role:

For decorative image icons, use an empty alt attribute:

Bad value “image/png, image/x-icon” for attribute “type” on element “link”: Expected a token character, whitespace or a semicolon but saw “,” instead.

Bad value “img” for attribute “role” on element “article”.

Bad value “inline-block” for attribute “display” on element “svg”.

Bad value “list” for attribute “role” on element “section”.

The section element carries implicit ARIA semantics — it maps to role="region" when given an accessible name. According to the ARIA in HTML specification, each HTML element has a set of roles it is allowed to assume, and list is not among the permitted roles for section. When the W3C validator encounters role="list" on a section, it flags this as a bad value because the role conflicts with the element's intended purpose as a sectioning landmark.

This matters for several reasons. First, assistive technologies like screen readers rely on the correct pairing of elements and roles to convey page structure. A section announced as a list creates a confusing, contradictory experience — the underlying DOM says "this is a document section" while the ARIA role says "this is a list." Second, browsers may handle conflicting semantics unpredictably, leading to inconsistent behavior across platforms. Third, the HTML specification explicitly defines which roles are valid on each element, and violating these rules means your markup is non-conforming.

The best fix is almost always to use native HTML list elements. The ul, ol, and li elements provide built-in list semantics that all browsers and assistive technologies understand without any extra ARIA attributes. Native elements also handle keyboard interaction and focus management correctly out of the box.

If your design requires a custom component where native list markup isn't feasible — for example, a complex card grid that functions as a list — you can apply role="list" to a semantically neutral element like div or span. Each direct child acting as a list item should then receive role="listitem". This approach satisfies the ARIA specification while avoiding the element-role conflict.

If you actually need a section to group content within a page region and the list is just part of that section, nest a proper list inside the section rather than trying to make the section itself behave as a list.

Examples

❌ Bad: `role="list"` on a `section` element

This triggers the validation error because list is not an allowed role for section.

</section>

✅ Fixed: Use native list elements (recommended)

Native lists provide the best accessibility support with no ARIA needed.

<ul>

</ul>

✅ Fixed: Nest a list inside the `section`

If you need the sectioning semantics of section alongside a list, nest the list inside it.

<h2 id="resources-heading">Resources</h2>

<ul>

</ul>

</section>

✅ Fixed: ARIA roles on a neutral container

Use this only when native list markup is not possible, such as for highly custom UI components.

</div>

✅ Fixed: Remove the role entirely

If the content isn't actually a list, simply remove the role attribute and let the section carry its natural semantics.

<h2>Updates</h2>

</section>

Bad value “listitem” for attribute “role” on element “article”.

The article element is a sectioning content element that represents a self-contained composition — a blog post, a news story, a forum entry, or similar independent content. Because it carries the implicit ARIA role of article, it functions as a landmark that assistive technologies recognize and expose to users for navigation. Overriding this landmark role with listitem creates a conflict: the element loses its article semantics for assistive technology users, and the listitem role itself becomes invalid because ARIA's role mapping rules don't permit it on article.

According to the ARIA in HTML specification, each HTML element has a set of allowed ARIA roles. The article element only permits a narrow set of roles (such as application, document, feed, main, none, presentation, and region). The listitem role is not among them. This restriction exists to prevent authors from creating confusing or contradictory semantics that would degrade the accessibility experience.

Beyond validation, this matters for real users. Screen readers rely on role information to convey structure. An article announced as a listitem is misleading — the user loses the ability to navigate by article landmarks, and the listitem may not function correctly without a proper parent list context. Browsers and assistive technologies expect listitem roles to appear as direct children of an element with role="list" (or within native ul/ol elements).

How to fix it

The solution depends on your intent:

If you want a list of articles, use native HTML list markup (ul or ol with li) and place each article inside a list item. This gives you both list semantics and article landmarks without any ARIA overrides.
If you can't use native list elements, use neutral div elements with role="list" and role="listitem", and nest the article inside each listitem container.
If the content isn't truly a list, simply remove the role="listitem" attribute and let the article element use its native semantics.

Examples

Invalid: `role="listitem"` on an `article` element

This triggers the validator error because listitem is not an allowed role for article.

<p>Details about this story.</p>

</article>

Valid: native list with `article` elements inside

Using ul and li provides proper list semantics while preserving the article landmark role.

<ul>

<li>

<p>Details about this story.</p>

</article>

</li>

<li>

<h2>Another item</h2>

<p>More details here.</p>

</article>

</li>

</ul>

Valid: ARIA list roles on neutral containers with nested `article` elements

When native list elements aren't suitable for your layout, use div elements for the list structure and nest each article inside.

<p>Details about this story.</p>

</article>

</div>

<h2>Another item</h2>

<p>More details here.</p>

</article>

</div>

Valid: standalone `article` without a list role

If the content doesn't belong in a list, simply remove the invalid role.

<p>Details about this story.</p>

</article>

In every case, the key principle is the same: let the article element keep its native semantics, and use the appropriate list structure around it rather than forcing a conflicting role onto it.

Bad value “mailto:X” for attribute “href” on element “a”: Illegal character after “ilto:”. “<” is not allowed.

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

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

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

A mailto: link follows URI syntax as defined by RFC 3986, which does not permit raw space characters anywhere in the URI. When the W3C validator encounters a space inside the href value of a mailto: link, it reports it as an illegal character in the scheme data. This most commonly happens due to a typo in the email address itself — for example, accidentally inserting a space in the domain name (example .com) or the local part (user name@example.com). It can also occur when query parameters like subject or body contain unencoded spaces.

This matters for several reasons. First, browsers may truncate or misinterpret the href at the space boundary, meaning the mail client may open with an incorrect or incomplete email address. Second, assistive technologies rely on well-formed URIs to communicate link destinations to users. A malformed mailto: link can confuse screen readers or prevent users from understanding where the link leads. Third, invalid markup signals poor quality to search engines and automated tools.

To fix this issue:

Check the email address for typos. Remove any accidental spaces in the local part (before @) or the domain part (after @).
Percent-encode spaces in query parameters. If you're using subject, body, or cc parameters in the mailto: URI, replace spaces with %20.
Avoid copying and pasting email addresses from formatted documents, which can introduce non-breaking spaces or other invisible whitespace characters.

Examples

Invalid — space in the email address

A space in the domain name makes the URI invalid:

<a href="mailto:user@example com">Send Email</a>

Valid — corrected email address

Remove the space to form a valid email address:

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

Invalid — space in the local part

<a href="mailto:john doe@example.com">Send Email</a>

Valid — space removed from local part

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

Invalid — unencoded spaces in subject parameter

<a href="mailto:info@example.com?subject=Hello World">Email Us</a>

Valid — percent-encoded spaces in subject parameter

Replace each space with %20 in query parameter values:

<a href="mailto:info@example.com?subject=Hello%20World">Email Us</a>

Valid — full mailto with multiple parameters

Report a Bug

</a>

Bad value “navigation” for attribute “role” on element “ul”.

In HTML, every element has a set of ARIA roles it is allowed to carry. The ul element implicitly has the list role, and the ARIA specification only permits certain roles to override it — specifically directory, group, listbox, menu, menubar, none, presentation, radiogroup, tablist, toolbar, and tree. The navigation role is not among them.

The navigation role is a landmark role, meaning it identifies a major section of the page dedicated to navigational links. HTML5 introduced the nav element specifically for this purpose, and it carries the navigation role implicitly — no role attribute needed. When you place role="navigation" on a ul, you're conflicting with the element's semantics. A ul represents a list of items, not a navigational landmark. Assistive technologies like screen readers rely on correct role assignments to help users understand page structure and navigate efficiently. An incorrect role can confuse users by misrepresenting what the element actually is.

Beyond accessibility concerns, this is a standards compliance issue. The W3C validator enforces the rules defined in the ARIA in HTML specification, which maps each HTML element to its allowed roles. Violating these rules means your markup is invalid and may behave unpredictably across different browsers and assistive technologies.

The fix is straightforward: use a nav element as the wrapper for your navigation list. This gives you the navigation landmark semantics automatically, while the ul retains its proper list role. Both elements work together — the nav tells assistive technologies "this is a navigation section," and the ul tells them "here is a list of links."

Examples

❌ Incorrect: `navigation` role on a `ul`

This triggers the validation error because navigation is not an allowed role for ul.

<li><a href="/about">About</a></li>

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

</ul>

✅ Correct: wrapping the `ul` in a `nav` element

The nav element provides the navigation landmark implicitly. No role attribute is needed.

<nav>

<ul>

<li><a href="/about">About</a></li>

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

</ul>

</nav>

✅ Correct: labeling multiple navigation landmarks

When a page has more than one nav element, use aria-label to distinguish them for screen reader users.

<ul>

<li><a href="/about">About</a></li>

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

</ul>

</nav>

<ul>

<li><a href="/privacy">Privacy Policy</a></li>

<li><a href="/terms">Terms of Service</a></li>

</ul>

</nav>

✅ Correct: using an allowed role on `ul`

If you need the ul to behave as something other than a plain list — for example, a menu in a web application — use one of its permitted roles.

<li role="menuitem"><a href="/about">About</a></li>

<li role="menuitem"><a href="/contact">Contact</a></li>

</ul>

Note that menu and menubar roles are meant for application-style menus with keyboard interaction, not for simple site navigation. For standard website navigation, the nav wrapper approach is almost always the right choice.

Bad value “new-password” for attribute “autocomplete” on element “input”: The autofill field name “new-password” is not allowed in this context.

Bad value “none” for attribute “autocomplete” on element “input”: The string “none” is not a valid autofill field name.

The autocomplete attribute tells the browser how to handle autofilling a form field. The HTML specification defines a strict set of allowed values: the keywords on and off, and a collection of autofill field names such as name, email, username, new-password, street-address, and many others. The value "none" is not part of this specification, even though it might seem like a logical choice for "no autocomplete."

This confusion likely arises because some non-web APIs and frameworks use "none" as a keyword to disable features. In HTML, however, the correct keyword to disable autocompletion is "off". Using an invalid value like "none" leads to undefined browser behavior — some browsers may ignore it entirely and autofill anyway, while others might treat it as equivalent to "on". This inconsistency can cause unexpected user experiences and potential security concerns, especially for sensitive fields like passwords or credit card numbers.

Beyond standards compliance, using valid autocomplete values improves accessibility. Assistive technologies and password managers rely on recognized autofill field names to help users fill out forms efficiently. When a valid, descriptive value like "username" or "email" is provided, browsers and assistive tools can offer more accurate suggestions.

How to fix it

Replace "none" with the appropriate valid value:

Use "off" if you want to disable autofill for the field.
Use "on" if you want the browser to decide how to autofill the field.
Use a specific autofill field name if you want to hint at the type of data expected.

Common autofill field names include: name, given-name, family-name, email, username, new-password, current-password, tel, street-address, postal-code, country, cc-number, cc-exp, and cc-name. You can also combine tokens, such as "shipping postal-code" or "billing cc-number", to provide additional context through section and hint tokens.

Note: Even with autocomplete="off", some browsers may still autofill certain fields (particularly login credentials) for security or usability reasons. This is browser-specific behavior and not something the HTML specification can override.

Examples

Incorrect: using `"none"` to disable autofill

<form>

<label for="user">Username</label>

</form>

Correct: using `"off"` to disable autofill

<form>

<label for="user">Username</label>

</form>

Correct: using a specific autofill field name

When you know what kind of data a field collects, providing a descriptive autofill field name is often better than using "on" or "off". This helps browsers offer accurate suggestions:

<form>

<label for="user">Username</label>

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

<label for="pwd">New Password</label>

</form>

Correct: using section and hint tokens

You can prefix an autofill field name with a section name or shipping/billing hint to distinguish between multiple addresses in the same form:

<form>

<label for="ship-zip">Shipping postal code</label>

<label for="bill-zip">Billing postal code</label>

</form>

Bad value “none” for attribute “autocorrect” on element “input”.

Bad value “none” for attribute “font-weight” on element “g”.

font-weight

The SVG font-weight presentation attribute controls the boldness or lightness of glyphs used to render text. According to the SVG specification, this attribute is only valid on text content elements: <text>, <tspan>, <textPath>, and the deprecated <tref>. While the <g> element is a general-purpose container for grouping SVG elements, it does not accept font-weight as a direct attribute in valid markup.

The value "none" compounds the problem because it is not a recognized value for font-weight in any context. The allowed values are:

normal (equivalent to 400)
bold (equivalent to 700)
bolder (relative to parent)
lighter (relative to parent)
A numeric value: 100, 200, 300, 400, 500, 600, 700, 800, or 900

This matters for standards compliance and predictable rendering across browsers. While some browsers may silently ignore invalid attributes or values, relying on that behavior leads to fragile code. Using valid attributes on the correct elements ensures consistent results and avoids validation errors.

If you need to apply a font-weight to multiple text elements inside a <g>, use CSS instead. You can apply a style via the style attribute on the <g>, a class, or an inline <style> block. CSS font-weight is inherited, so child text elements will pick it up.

Examples

Invalid: `font-weight="none"` on a `<g>` element

<text y="20">Hello</text>

</g>

</svg>

This triggers the validation error because <g> does not accept the font-weight attribute directly, and "none" is not a valid value.

Fixed: `font-weight` on the `<text>` element with a valid value

<g>

<text y="20" font-weight="bold">Hello</text>

</g>

</svg>

Fixed: using a numeric weight on `<text>`

<text x="100" y="20" font-weight="400">Normal text</text>

</svg>

Fixed: applying `font-weight` to a `<g>` via CSS

If you want all text inside a <g> to share the same weight, use the style attribute or a CSS class. CSS-based font-weight on a <g> is valid because CSS inheritance applies to all descendant text content.

</g>

</svg>

Fixed: using an inline `<style>` block

<style>

.heavy { font-weight: 900; }

</style>

<text y="20">Heavy text</text>

<text x="150" y="20">Also heavy</text>

</g>

</svg>

Bad value “none” for attribute “text-anchor” on element “g”.

This W3C validation error has two distinct problems combined into one message. First, the value "none" is not a recognized value for the text-anchor attribute — the only accepted values are start, middle, and end. Second, the <g> element is a generic container used to group SVG shapes together and does not support the text-anchor attribute directly.

The text-anchor attribute controls how text is aligned relative to its anchor point (the x coordinate). A value of start aligns the beginning of the text to the anchor, middle centers the text on the anchor, and end aligns the end of the text to the anchor. There is no "none" value because text always needs an alignment — start is the default if the attribute is omitted.

Why this is a problem

Invalid markup: Using an unrecognized value like "none" means browsers must guess the intended behavior, which can lead to inconsistent rendering across different environments.
Wrong element: The <g> element does not directly render text, so text-anchor has no meaningful effect on it. While CSS inheritance might cause child text elements to pick up styles from a parent <g>, the text-anchor presentation attribute is only valid on elements that actually render text content.
Standards compliance: The SVG specification explicitly defines which elements accept text-anchor and which values are allowed. Violating this produces validation errors and may cause issues with SVG processing tools.

How to fix it

Remove the attribute from the <g> element and apply it to the appropriate text element inside the group.
Replace "none" with a valid value: start, middle, or end. If you want the default behavior (left-aligned for LTR text), simply omit the attribute entirely, as start is the default.
If you need to set text-anchor for multiple text elements inside a group, use CSS instead of the presentation attribute.

Examples

❌ Invalid: `"none"` on a `<g>` element

<text x="100" y="100">Hello</text>

</g>

</svg>

✅ Fixed: valid value on the `<text>` element

<text x="100" y="100" text-anchor="middle">Hello</text>

</svg>

✅ Fixed: attribute removed entirely (uses default `start`)

<g>

<text x="100" y="100">Hello</text>

</g>

</svg>

✅ Using CSS to style text inside a group

If you want all text elements within a group to share the same alignment, apply the style via CSS rather than a presentation attribute on <g>:

<style>

.centered-text text {

text-anchor: middle;

}

</style>

<text x="100" y="50">First line</text>

<text x="100" y="100">Second line</text>

</g>

</svg>

✅ Valid use on other text-related elements

The text-anchor attribute can also be applied to <tspan> and <textPath>:

Start-aligned

<tspan x="150" dy="30" text-anchor="end">End-aligned span</tspan>

</text>

</svg>

Bad value “nope” for attribute “autocomplete” on element “form”.

The autocomplete attribute on <form> elements controls whether the browser should automatically fill in form fields based on previously entered data. Unlike autocomplete on <input> elements — which accepts a rich set of tokens like "name", "email", "street-address", etc. — the <form> element itself only accepts two values: "on" and "off".

A common workaround that gained popularity was setting autocomplete="nope" (or other made-up values like "new-password", "false", or "disabled") on the <form> element. This hack exploited the fact that some browsers would treat any unrecognized value as a signal to disable autocomplete. However, this behavior is non-standard and unreliable — browsers may ignore invalid values entirely and fall back to their default behavior, which is typically "on".

Using invalid attribute values causes several problems:

Standards compliance: The HTML specification explicitly defines the allowed values, and validators will flag anything else as an error.
Unpredictable behavior: Different browsers handle invalid values differently. What works in one browser today may stop working in the next update.
Accessibility and user experience: Assistive technologies and browser features rely on standard attribute values to function correctly. Invalid values can interfere with password managers and autofill tools that many users depend on.

It's worth noting that even with autocomplete="off", some browsers (particularly Chrome) may still autofill certain fields like login credentials for security reasons. If you need finer-grained control, apply autocomplete attributes directly on individual <input> elements using the appropriate autofill tokens from the specification.

Examples

❌ Invalid: Using a made-up value on a form

<label for="username">Username</label>

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

</form>

This triggers the error Bad value "nope" for attribute "autocomplete" on element "form" because "nope" is not a valid autocomplete value for <form>.

✅ Fixed: Using the correct value to disable autocomplete

<label for="username">Username</label>

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

</form>

✅ Using autocomplete on individual inputs for more control

If you need to disable autocomplete for specific fields while leaving others enabled, apply the attribute directly on the <input> elements instead:

<label for="username">Username</label>

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

</form>

In this example, the username field uses the standard "username" autofill token to help browsers fill it correctly, while the one-time code field has autocomplete disabled since its value should never be reused.

Bad value “nope” for attribute “autocomplete” on element “input”: The string “nope” is not a valid autofill field name.

The autocomplete attribute tells the browser how to handle autofill for a form field. The HTML specification defines a strict set of valid values, which include "on", "off", and a list of autofill field names such as "username", "new-password", "cc-number", "postal-code", and many others. When you use a value that isn't in this list — such as "nope", "false", "none", or any other made-up string — the W3C validator reports it as an invalid autofill field name.

A common reason developers use values like "nope" is as a workaround because some browsers historically ignored autocomplete="off". In older versions of Chrome and Firefox, the browser would still show autofill suggestions even when off was set, so developers discovered that using an unrecognized value like "nope" effectively tricked the browser into not showing suggestions. While this hack may have worked in practice, it produces invalid HTML and is not a reliable long-term solution since browser behavior around unrecognized values can change at any time.

Why this matters

Standards compliance: Invalid attribute values make your HTML non-conforming, which can cause issues with tooling, testing pipelines, and accessibility auditors.
Accessibility: Screen readers and assistive technologies rely on valid autocomplete values to help users fill in forms. Using a correct autofill field name like "given-name" or "email" can significantly improve the experience for users with disabilities. In fact, WCAG 2.1 Success Criterion 1.3.5 specifically recommends using valid autocomplete values for fields that collect user information.
Browser behavior: Modern browsers have improved their handling of autocomplete="off". Using the standard value is now more reliable than it once was, and using it correctly ensures predictable behavior across browsers.

How to fix it

To disable autocomplete, replace the invalid value with "off".
To enable smart autofill, use the appropriate autofill field name from the HTML specification's list of autofill field names. This is the preferred approach for most user-facing forms.
For new passwords (e.g., registration or password-change forms), use "new-password" — this tells the browser to suggest a generated password rather than filling in a saved one.

Examples

Invalid: made-up autocomplete value

Other common invalid values that trigger the same error include "false", "none", "disable", and "no".

Fixed: disabling autocomplete with `"off"`

Fixed: using a valid autofill field name

Using a specific autofill field name is often better than "off" because it helps browsers and assistive technologies understand the purpose of the field:

Fixed: common valid autocomplete values in a form

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

<label for="newpass">Password</label>

<label for="tel">Phone</label>

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

</form>

Some of the most commonly used valid values include: "name", "given-name", "family-name", "email", "username", "new-password", "current-password", "street-address", "postal-code", "country", "tel", "cc-number", and "organization". Refer to the full list in the HTML specification for all available options.

Bad value “nothanks” for attribute “autocomplete” on element “input”: The string “nothanks” is not a valid autofill field name.

The autocomplete attribute tells browsers whether and how to autofill a form field. The HTML specification defines a strict set of valid values for this attribute, known as autofill field names. These include values like "on", "off", "name", "email", "username", "new-password", "current-password", "address-line1", "postal-code", "cc-number", and many others. When you use a value that doesn't appear in this list — such as "nothanks", "nope", or "false" — the W3C validator reports it as an invalid autofill field name.

A common reason developers use made-up values is frustration with browsers ignoring autocomplete="off". Some browsers (notably Chrome) may still autofill certain fields even when autocomplete="off" is set, particularly for login-related fields. This has led to workarounds using random strings, but these are non-standard and can produce unpredictable behavior across different browsers and assistive technologies.

Why This Matters

Standards compliance: Invalid attribute values make your HTML non-conforming, which can lead to unexpected browser behavior now or in the future.
Accessibility: Screen readers and other assistive technologies may use the autocomplete attribute to help users fill in forms. A recognized value like "name" or "email" gives these tools meaningful context, while a random string provides none.
Browser behavior: Browsers are designed to interpret the standard values. An unrecognized value may be treated inconsistently — some browsers might ignore it, others might treat it as "on", and behavior could change between versions.

How to Fix It

If you want to disable autocomplete, use "off":

If you want to help browsers autofill correctly, use the appropriate autofill field name from the specification:

If autocomplete="off" isn't being respected by the browser (a known issue with some login fields in Chrome), consider these standards-compliant alternatives:

Use autocomplete="new-password" on password fields where you don't want saved passwords suggested.
Use a more specific valid token that doesn't match what the browser is trying to autofill.
Use the readonly attribute and remove it on focus via JavaScript as a supplementary measure.

Examples

❌ Invalid: arbitrary string as autocomplete value

<form>

<label for="firstName">First name</label>

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

</form>

Both "nothanks" and "nope" are not valid autofill field names and will trigger the validation error.

✅ Valid: using `"off"` to disable autocomplete

<form>

<label for="firstName">First name</label>

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

</form>

✅ Valid: using proper autofill field names

<form>

<label for="firstName">First name</label>

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

<label for="newPass">New password</label>

</form>

Using descriptive autofill tokens like "given-name", "email", and "new-password" is the best approach when you want browsers and assistive technologies to understand your form fields. For a complete list of valid autofill field names, refer to the WHATWG HTML specification's autofill section.

Bad value “numeric” for attribute “type” on element “input”.

The HTML <input> element accepts a specific set of values for its type attribute, as defined by the HTML specification. The value "numeric" is not one of them. When a browser encounters an unrecognized type value, it falls back to type="text", meaning the user gets a plain text field instead of a dedicated numeric input. This fallback behavior means you lose built-in features like increment/decrement spinner controls, numeric keyboard on mobile devices, and native client-side validation that rejects non-numeric entries.

This confusion often arises because of the inputmode="numeric" attribute, which is valid and controls which virtual keyboard appears on mobile devices. The inputmode attribute and the type attribute serve different purposes, and mixing them up leads to this validation error.

Using the correct type="number" value matters for several reasons:

Accessibility: Screen readers and assistive technologies use the type attribute to announce the expected input format to users.
User experience: Browsers display appropriate controls (spinners, numeric keypads) for type="number" inputs.
Validation: Native form validation automatically checks that the entered value is a valid number, within optional min/max bounds and matching an optional step value.
Standards compliance: Invalid type values cause W3C validation errors and signal potential bugs in your markup.

Examples

Incorrect: using `type="numeric"`

This triggers the validation error because "numeric" is not a valid type value:

<label for="quantity">Quantity:</label>

The browser will treat this as type="text", so users can type any characters, no spinner controls appear, and no numeric validation occurs.

Correct: using `type="number"`

Replace "numeric" with "number":

<label for="quantity">Quantity:</label>

This gives you a proper numeric input with optional min, max, and step attributes for constraining the allowed range and increments.

Alternative: using `inputmode="numeric"` with `type="text"`

If you need a numeric keyboard on mobile but want more control over the input (for example, accepting values like zip codes or credit card numbers that aren't truly "numbers"), you can use inputmode="numeric" on a text input instead:

Here, type="text" is valid, inputmode="numeric" triggers the numeric keyboard on mobile devices, and the pattern attribute provides validation. This approach is useful when type="number" isn't appropriate — for instance, type="number" strips leading zeros and allows scientific notation like 1e5, which is undesirable for codes and identifiers.

Summary of the fix

Before (invalid)	After (valid)	Use case
`type="numeric"`	`type="number"`	Actual numeric values (quantities, prices, ages)
`type="numeric"`	`type="text" inputmode="numeric"`	Numeric-looking codes (ZIP, PIN, credit card)

In most cases, simply changing type="numeric" to type="number" is the correct fix. Choose the inputmode approach only when you specifically need a text field with a numeric keyboard.

Bad value “”og:type”” for attribute “property” on element “meta”: The string “”og:type”” is not an absolute URL.

This error is almost always caused by copying and pasting code from a word processor, CMS rich-text editor, blog post, or PDF. These tools often auto-correct straight quotation marks (") into typographic (curly or "smart") quotes (" and "). While curly quotes look nicer in prose, they are not valid as attribute delimiters in HTML. The browser and the W3C validator only recognize the standard straight double quote (", U+0022) or straight single quote (', U+0027) as attribute value delimiters.

When the validator encounters markup like <meta property="og:type", the curly quotes are treated as part of the attribute's value. The validator then sees the value as "og:type" — a string wrapped in literal curly quote characters. Since the property attribute in RDFa (which Open Graph Protocol relies on) expects a term or an absolute URL, and "og:type" is neither, the validator reports the error.

This problem can affect any HTML attribute, but it's especially common with <meta> tags for Open Graph, Twitter Cards, and other social sharing metadata, since developers frequently copy these snippets from documentation or tutorials.

How to fix it

Find the curly quotes. Look at the property attribute value in your source code. Curly opening quotes (", U+201C) and closing quotes (", U+201D) may look nearly identical to straight quotes in some fonts, so use your editor's find-and-replace feature to search for " and ".
Replace them with straight quotes. Swap every " and " with a standard straight double quote (").
Disable smart quotes in your editor. If you're writing HTML in a rich-text editor or word processor, turn off the "smart quotes" or "typographic quotes" feature. Better yet, use a dedicated code editor (like VS Code, Sublime Text, or similar) that won't auto-replace quotes.

Examples

Incorrect — curly quotes around the attribute value

The curly " and " characters become part of the value itself, producing the validator error: Bad value "og:type" for attribute property.

Correct — straight quotes around the attribute value

Standard straight double quotes correctly delimit the attribute values, and the validator sees og:type as expected.

Correct — single straight quotes are also valid

Straight single quotes (', U+0027) work just as well as straight double quotes for delimiting HTML attribute values. Use whichever style your project prefers, but be consistent.

Full Open Graph example

<!DOCTYPE html>

<head>

</head>

<body>

<p>Hello, world!</p>

</body>

</html>

All property and content attributes use straight double quotes, ensuring clean validation and correct parsing by social media crawlers.

Bad value “polygon” for attribute “shape” on element “area”.

The shape attribute on an <area> element tells the browser what kind of clickable region to define within an image map. The HTML living standard (WHATWG) strictly limits this attribute to four values:

rect — a rectangle, defined by four coordinates: x1,y1,x2,y2 (top-left and bottom-right corners)
circle — a circle, defined by three values: x,y,r (center point and radius)
poly — a polygon, defined by a series of x,y coordinate pairs tracing the shape's vertices
default — the entire image area (no coords needed)

The value "polygon" is a common mistake — it's intuitive and used in other contexts like SVG — but it is not valid HTML. Browsers may silently fall back to default or ignore the region entirely when they encounter an unrecognized shape value, which means users could lose the ability to click that area of the image map.

Why this matters

Browser compatibility: Browsers are not required to handle invalid shape values gracefully. While some may guess your intent, others may render the clickable region incorrectly or not at all.
Accessibility: Screen readers and assistive technologies rely on valid markup to convey image map regions to users. An invalid shape value can make a region invisible to these tools, breaking keyboard navigation and alternative text announcements.
Standards compliance: Using valid attribute values ensures your markup behaves predictably across all browsers and passes automated validation checks.

How to fix it

Replace shape="polygon" with shape="poly". The coords attribute syntax stays the same — a comma-separated list of x,y pairs representing each vertex of the polygon, in order. Coordinate values are in CSS pixels relative to the image's intrinsic (natural) dimensions.

Also ensure that each <area> element includes:

An href attribute to make the region a link
An alt attribute for accessibility (required when href is present)

Examples

Invalid: using `shape="polygon"`

</map>

The validator reports: Bad value "polygon" for attribute "shape" on element "area".

Fixed: using `shape="poly"`

</map>

Changing "polygon" to "poly" resolves the error. The four coordinate pairs (10,10, 80,10, 80,60, 10,60) define a rectangular polygon. The browser automatically closes the shape by connecting the last point back to the first.

Reference: all valid `shape` values

</map>

This example demonstrates all four valid shape values with their corresponding coords syntax. Note that default does not require a coords attribute since it covers the remainder of the image.

How to Fix It

Examples

Invalid: using https:// in the namespace URI

Fixed: omit xmlns in HTML5

Fixed: use the correct http:// URI

Quick comparison

Examples

Incorrect: using https:// in the namespace URI

Fixed: using the correct http:// namespace URI

Preferred: removing the namespace and using plain href

How to Fix It

Examples

❌ Incorrect: Using https in the namespace URI

✅ Correct: Using http in the namespace URI

✅ Correct: Inline SVG in HTML without xmlns

Examples

❌ Invalid: Using the non-existent "icon" role

✅ Fixed: Decorative icon with no role

✅ Fixed: Meaningful icon using role="img"

✅ Fixed: Icon inside a button

✅ Fixed: Icon using an <img> element instead

Invalid Example

Valid Examples

Example with the issue

How to fix it

Invalid example

Valid example

Examples

❌ Bad: role="list" on a section element

✅ Fixed: Use native list elements (recommended)

✅ Fixed: Nest a list inside the section

✅ Fixed: ARIA roles on a neutral container

✅ Fixed: Remove the role entirely

How to fix it

Examples

Invalid: role="listitem" on an article element

Valid: native list with article elements inside

Valid: ARIA list roles on neutral containers with nested article elements

Valid: standalone article without a list role

Invalid example

Valid example

HTML examples

Invalid

Valid

HTML examples

Incorrect

Correct

Examples

Invalid — space in the email address

Valid — corrected email address

Invalid — space in the local part

Valid — space removed from local part

Invalid — unencoded spaces in subject parameter

Valid — percent-encoded spaces in subject parameter

Valid — full mailto with multiple parameters

Examples

❌ Incorrect: navigation role on a ul

✅ Correct: wrapping the ul in a nav element

✅ Correct: labeling multiple navigation landmarks

✅ Correct: using an allowed role on ul

Invalid Example

Valid Example

How to fix it

Examples

Incorrect: using "none" to disable autofill

Correct: using "off" to disable autofill

Correct: using a specific autofill field name

Correct: using section and hint tokens

Incorrect example

Correct example

Examples

Invalid: font-weight="none" on a <g> element

Fixed: font-weight on the <text> element with a valid value

Fixed: using a numeric weight on <text>

Fixed: applying font-weight to a <g> via CSS

Fixed: using an inline <style> block

Why this is a problem

How to fix it

Examples

Invalid: using `https://` in the namespace URI

Fixed: omit `xmlns` in HTML5

Fixed: use the correct `http://` URI

Incorrect: using `https://` in the namespace URI

Fixed: using the correct `http://` namespace URI

Preferred: removing the namespace and using plain `href`

❌ Incorrect: Using `https` in the namespace URI

✅ Correct: Using `http` in the namespace URI

✅ Correct: Inline SVG in HTML without `xmlns`

❌ Invalid: Using the non-existent `"icon"` role

✅ Fixed: Meaningful icon using `role="img"`

✅ Fixed: Icon using an `<img>` element instead

❌ Bad: `role="list"` on a `section` element

✅ Fixed: Nest a list inside the `section`

Invalid: `role="listitem"` on an `article` element

Valid: native list with `article` elements inside

Valid: ARIA list roles on neutral containers with nested `article` elements

Valid: standalone `article` without a list role

❌ Incorrect: `navigation` role on a `ul`

✅ Correct: wrapping the `ul` in a `nav` element

✅ Correct: using an allowed role on `ul`

Incorrect: using `"none"` to disable autofill

Correct: using `"off"` to disable autofill

Invalid: `font-weight="none"` on a `<g>` element

Fixed: `font-weight` on the `<text>` element with a valid value

Fixed: using a numeric weight on `<text>`

Fixed: applying `font-weight` to a `<g>` via CSS

Fixed: using an inline `<style>` block

❌ Invalid: `"none"` on a `<g>` element

✅ Fixed: valid value on the `<text>` element

✅ Fixed: attribute removed entirely (uses default `start`)

Fixed: disabling autocomplete with `"off"`

✅ Valid: using `"off"` to disable autocomplete

Incorrect: using `type="numeric"`

Correct: using `type="number"`

Alternative: using `inputmode="numeric"` with `type="text"`

Invalid: using `shape="polygon"`

Fixed: using `shape="poly"`

Reference: all valid `shape` values

Validate at scale.
Ship accessible websites, faster.