HTML Guides

Hidden inputs are designed to carry data between the client and server without any user interaction or visual presence. The browser does not render them, screen readers do not announce them, and they are entirely excluded from the accessibility tree. Because aria-* attributes exist solely to convey information to assistive technologies, adding them to an element that assistive technologies cannot perceive is contradictory and meaningless.

The HTML specification explicitly prohibits aria-* attributes on input elements with type="hidden". This restriction exists because WAI-ARIA attributes — such as aria-label, aria-invalid, aria-describedby, aria-required, and all others in the aria-* family — are meant to enhance the accessible representation of interactive or visible elements. A hidden input has no such representation, so these attributes have nowhere to apply.

This issue commonly arises when:

• JavaScript frameworks or templating engines apply aria-* attributes indiscriminately to all form inputs, regardless of type.
• A developer changes an input's type from "text" to "hidden" but forgets to remove the accessibility attributes that were relevant for the visible version.
• Form libraries or validation plugins automatically inject attributes like aria-invalid onto every input in a form.

To fix the issue, simply remove all aria-* attributes from any input element that has type="hidden". If the aria-* attribute was meaningful on a previously visible input, no replacement is needed — the hidden input doesn't participate in the user experience at all.

Examples

Incorrect: hidden input with aria-invalid

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

<input type="hidden" name="referer" value="https://example.com" aria-invalid="false">

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

</form>

Correct: hidden input without aria-* attributes

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

<input type="hidden" name="referer" value="https://example.com">

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

</form>

Incorrect: hidden input with multiple aria-* attributes

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

<input

type="hidden"

name="session_token"

value="abc123"

aria-label="Session token"

aria-required="true"

aria-describedby="token-help">

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

</form>

Correct: all aria-* attributes removed

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

<input type="hidden" name="session_token" value="abc123">

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

</form>

Correct: aria-* attributes on a visible input (where they belong)

If the input is meant to be visible and accessible, use an appropriate type value instead of "hidden":

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

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

<input

type="text"

id="username"

name="username"

aria-required="true"

aria-invalid="false"

aria-describedby="username-help">

<p id="username-help">Enter your registered email or username.</p>

<button type="submit">Log in</button>

</form>

An <li> element inside an element with role="listbox" may only carry a role value of option or group.

The listbox role turns a list into a select-like widget, so assistive technologies expect every item in it to be a selectable option, optionally organized under a group. Any other role on the items, such as menuitem, button, or tab, contradicts the structure announced by the container, and screen readers can no longer present the widget coherently. This often happens in hand-rolled dropdowns built on <ul> and <li>, where the container got role="listbox" but the items kept a role from an earlier design.

If the items really are selectable choices, give them role="option". If they are something else entirely, change the container role instead of forcing the items. And when the widget is a plain single or multiple choice, a native <select> needs no ARIA at all.

Invalid example

The items use menuitem, which is not allowed inside a listbox:

<ul role="listbox" aria-label="Sort order">

<li role="menuitem">Newest first</li>

<li role="menuitem">Oldest first</li>

</ul>

Valid example

Each item becomes an option:

<ul role="listbox" aria-label="Sort order">

<li role="option" aria-selected="true">Newest first</li>

<li role="option" aria-selected="false">Oldest first</li>

</ul>

Or use a native control and drop the ARIA roles entirely:

<label>Sort order

<select>

<option selected>Newest first</option>

<option>Oldest first</option>

</select>

</label>

An <li> element inside a <ul>, <ol>, or <menu> must not be assigned any ARIA role other than listitem.

When an <li> sits inside a standard list container (<ul>, <ol>, or <menu>) that has no explicit role attribute, the browser already treats the <li> as having an implicit role of listitem. Assigning a different role, such as role="presentation", role="option", or role="tab", contradicts the semantics of the parent-child relationship between the list and its items. Screen readers and other assistive technologies rely on this relationship to convey list structure to users.

The same restriction applies when the parent element has role="list" set explicitly. In that context, child <li> elements are still expected to carry only the listitem role.

If you need a different role on the items, restructure the markup. For example, use <div> elements instead of <ul> and <li>, and apply the appropriate roles directly. Or, if the items genuinely are list items, remove the conflicting role attribute.

Examples

Invalid: li with a non-listitem role inside a ul

<ul>

<li role="tab">Dashboard</li>

<li role="tab">Settings</li>

<li role="tab">Profile</li>

</ul>

Fixed: use appropriate elements when a different role is needed

If the items are tabs, drop the list markup and use elements that match the intended semantics:

<div role="tablist">

<button role="tab" aria-selected="true">Dashboard</button>

<button role="tab" aria-selected="false">Settings</button>

<button role="tab" aria-selected="false">Profile</button>

</div>

Fixed: keep the list but remove the conflicting role

If the content really is a list, remove the extra role:

<ul>

<li>Dashboard</li>

<li>Settings</li>

<li>Profile</li>

</ul>

Every <optgroup> needs a name: give it a label attribute, or make a <legend> element its first child.

Browsers show the group name as a heading above the group's options, and screen readers announce it when the user moves into the group. The HTML specification requires the label attribute whenever the <optgroup> has no child <legend>. Without either one, the options sit under a blank heading and screen readers have nothing to announce.

Use the label attribute unless you have a reason not to. Every browser supports it. The validator only checks that the attribute exists, so label="" passes even though the group still has no name. Write the real group name.

The <legend> child comes from customizable select, a recent addition to HTML that lets you mark up and style the group heading. Browsers without customizable select support ignore the <legend> tag and show the group without a name. Older versions of the W3C validator reject it as well: they report the <legend> as a stray start tag and still ask for label. If you use a <legend>, keep the label attribute too. Browsers that support customizable select take the name from the <legend>, and older ones fall back to the attribute.

Invalid example

<label for="car">Car</label>

<select id="car" name="car">

<optgroup>

<option value="volvo">Volvo</option>

<option value="saab">Saab</option>

</optgroup>

<optgroup>

<option value="audi">Audi</option>

<option value="bmw">BMW</option>

</optgroup>

</select>

Valid example

<label for="car">Car</label>

<select id="car" name="car">

<optgroup label="Swedish cars">

<option value="volvo">Volvo</option>

<option value="saab">Saab</option>

</optgroup>

<optgroup label="German cars">

<option value="audi">Audi</option>

<option value="bmw">BMW</option>

</optgroup>

</select>

Valid example with a legend

<label for="car">Car</label>

<select id="car" name="car">

<optgroup label="Swedish cars">

<legend>Swedish cars</legend>

<option value="volvo">Volvo</option>

<option value="saab">Saab</option>

</optgroup>

</select>

The label element represents a caption for a form control. There are two ways to associate a label with its control:

1. Implicit association — Place the form control directly inside the label element. No for attribute is needed because the browser automatically pairs the label with the nested control.
2. Explicit association — Use the for attribute on the label, setting its value to the id of the target form control. The control doesn't need to be nested inside the label in this case.

Both methods are valid on their own. The problem occurs when you combine them incorrectly: you nest an input inside a label that has a for attribute, but the input either has no id or has an id that doesn't match the for value. This creates a contradiction — the for attribute points to a specific id, yet the nested input doesn't fulfill that reference. Browsers may handle this inconsistently, and assistive technologies like screen readers could fail to announce the label correctly, harming accessibility.

Why this matters

• Accessibility: Screen readers rely on the for/id pairing to announce labels for form controls. A mismatched or missing id can leave the control unlabeled for users who depend on assistive technology.
• Standards compliance: The HTML specification requires that when a for attribute is present, it must reference the id of a labelable element. A mismatch violates this rule.
• Browser behavior: Some browsers will fall back to the implicit association when for doesn't resolve, but others may prioritize the broken explicit association, leaving the control effectively unlabeled.

How to fix it

You have two options:

1. Remove the for attribute if the input is already nested inside the label. The implicit association is sufficient on its own.
2. Add or correct the id on the nested input so it matches the for attribute value exactly.

Examples

❌ Nested input with no matching id

The for attribute says "email", but the input has no id at all:

<label for="email">

Email

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

</label>

❌ Nested input with a mismatched id

The for attribute says "email", but the input's id is "user-email":

<label for="email">

Email

<input type="email" name="email" id="user-email">

</label>

✅ Fix by removing the for attribute (implicit association)

Since the input is nested inside the label, the association is automatic:

<label>

Email

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

</label>

✅ Fix by adding a matching id (explicit association)

The for value and the id value are identical:

<label for="email">

Email

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

</label>

✅ Fix by using explicit association without nesting

If you prefer to keep the for attribute, the input doesn't need to be nested at all:

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

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

In most cases, choosing either implicit or explicit association — rather than mixing both — is the simplest way to avoid this error. If you do combine them, just make sure the for value and the id value match exactly.

The label element associates a caption with a form control. There are two ways to create this association:

1. Implicit association — Place the form control directly inside the label element. No for or id attributes are needed.
2. Explicit association — Use the for attribute on the label, setting its value to the id of the associated form control.

Both methods work independently. The problem arises when you mix them incorrectly — nesting a select inside a label that has a for attribute, but the select either has no id or has an id that doesn't match the for value. In this situation, the explicit association (via for) points to nothing or to the wrong element, while the implicit association (via nesting) still exists. This contradictory state violates the HTML specification and can cause assistive technologies like screen readers to misidentify or skip the label, reducing accessibility for users who rely on them.

The WHATWG HTML specification requires that when a for attribute is present on a label, it must reference a valid labelable element by id. If the form control is already nested inside the label, the for attribute is redundant — but if present, it still must correctly reference that control.

How to Fix

You have two options:

1. Remove the for attribute — If the select is already inside the label, implicit association handles everything. This is the simplest fix.
2. Add or correct the id — Keep the for attribute but ensure the select has a matching id.

Examples

❌ Incorrect: for attribute with no matching id

The for attribute references "age", but the select has no id at all:

<label for="age">

Age

<select>

<option>Young</option>

<option>Old</option>

</select>

</label>

❌ Incorrect: for attribute with a mismatched id

The for attribute references "age", but the select has a different id:

<label for="age">

Age

<select id="age-select">

<option>Young</option>

<option>Old</option>

</select>

</label>

✅ Fix option 1: Remove the for attribute (implicit association)

Since the select is nested inside the label, implicit association is sufficient:

<label>

Age

<select>

<option>Young</option>

<option>Old</option>

</select>

</label>

✅ Fix option 2: Match the for attribute with the id (explicit association)

Keep the for attribute and give the select a matching id:

<label for="age">

Age

<select id="age">

<option>Young</option>

<option>Old</option>

</select>

</label>

✅ Fix option 3: Separate the label and select (explicit association only)

If you prefer to keep the select outside the label, explicit association with matching for and id is required:

<label for="age">Age</label>

<select id="age">

<option>Young</option>

<option>Old</option>

</select>

In most cases, option 1 (removing the for attribute) is the cleanest solution when the control is already nested. Use explicit association when the label and control are in separate parts of the DOM, such as in complex table or grid layouts.

The <article> element is meant to wrap independent, self-contained content such as blog posts, news stories, forum posts, product cards, or user comments. The W3C validator raises this warning because an <article> without a heading has no programmatic label, making it harder for users—especially those relying on screen readers—to understand what the article is about and to navigate between multiple articles on a page.

Screen readers often present a list of landmarks and headings to help users jump through a page's structure. When an <article> has no heading, it appears as an unlabeled region, which is confusing and defeats the purpose of using semantic HTML. A heading inside the <article> acts as its identifying title, giving both sighted users and assistive technology a clear summary of the content that follows.

This is a warning rather than a hard validation error, but it signals a real accessibility and usability concern. In nearly all cases, every <article> should contain a heading. The heading level you choose should fit logically within the document's heading hierarchy—typically <h2> if the <article> sits directly under the page's main <h1>, or <h3> if it's nested inside a section that already uses <h2>.

How to fix it

1. Add a heading element (<h2>–<h6>) as one of the first children inside each <article>.
2. Choose the correct heading level based on the document outline. Don't skip levels (e.g., jumping from <h1> to <h4>).
3. Make the heading descriptive. It should clearly summarize the article's content.

If your design doesn't visually display a heading, you can use CSS to visually hide it while keeping it accessible to screen readers (see the examples below).

Examples

❌ Article without a heading (triggers the warning)

<h1>Latest news</h1>

<article>

<p>Our new product launched today with great success.</p>

</article>

<article>

<p>We are hiring frontend developers. Apply now!</p>

</article>

Each <article> here has no heading, so assistive technologies cannot identify them, and the validator raises a warning.

✅ Articles with proper headings

<h1>Latest news</h1>

<article>

<h2>Product launch a success</h2>

<p>Our new product launched today with great success.</p>

</article>

<article>

<h2>We're hiring frontend developers</h2>

<p>We are hiring frontend developers. Apply now!</p>

</article>

✅ Nested articles with correct heading hierarchy

<h1>Our blog</h1>

<article>

<h2>How to validate accessibility</h2>

<p>Use automated tools for an in-depth scan of your site.</p>

<section>

<h3>Comments</h3>

<article>

<h4>Comment by Alex</h4>

<p>Great article, very helpful!</p>

</article>

</section>

</article>

When articles are nested (e.g., comments inside a blog post), each level gets the next heading level to maintain a logical outline.

✅ Visually hidden heading for design flexibility

If your design doesn't call for a visible heading but you still need one for accessibility, use a CSS utility class to hide it visually while keeping it in the accessibility tree:

<style>

.visually-hidden {

position: absolute;

width: 1px;

height: 1px;

padding: 0;

margin: -1px;

overflow: hidden;

clip: rect(0, 0, 0, 0);

white-space: nowrap;

border: 0;

}

</style>

<article>

<h2 class="visually-hidden">Featured promotion</h2>

<p>Save 20% on all items this weekend only!</p>

</article>

This approach satisfies both the validator and assistive technologies without affecting your visual layout. Avoid using display: none or visibility: hidden, as those also hide the heading from screen readers.

The aria-hidden attribute is redundant when the hidden attribute is already present on an element.

The hidden attribute is a boolean HTML attribute that makes an element not visible and not perceivable to any user. Browsers hide the element from rendering, and accessibility tools also ignore it. The aria-hidden="true" attribute does something narrower: it removes the element from the accessibility tree but does not affect visual rendering.

When both attributes appear on the same element, aria-hidden adds nothing. The hidden attribute already tells assistive technologies to skip the element. The validator flags this as unnecessary markup.

There is one subtle difference worth knowing. aria-hidden="false" on an element with hidden would create a contradiction: the element is hidden from everyone visually, yet exposed to assistive technologies. This is almost never intentional and likely a bug.

If the goal is to hide content from all users, use hidden alone. If the goal is to hide content only from assistive technologies while keeping it visible, use aria-hidden="true" alone without hidden.

HTML examples

Before fix

<div hidden aria-hidden="true">

<p>This content is hidden from everyone.</p>

</div>

After fix

<div hidden>

<p>This content is hidden from everyone.</p>

</div>

A field with the readonly attribute is already exposed as read-only, so aria-readonly repeats the same information and can be removed.

The readonly attribute on an <input> or <textarea> tells browsers and assistive technologies that the user can't change the value. Adding aria-readonly="true" states the same thing a second time. The ARIA in HTML specification advises against it, and the validator reports it as a warning.

The same warning appears when aria-readonly repeats the exact value of readonly, as in readonly="readonly" aria-readonly="readonly", or an empty aria-readonly="" next to a bare readonly. In those cases the validator also reports a Bad value error, because aria-readonly only accepts true or false.

Remove aria-readonly and keep readonly. aria-readonly is meant for custom widgets, such as an element with role="textbox" or a grid cell, which have no native readonly attribute. If aria-readonly is set to false on a field with readonly, the two attributes contradict each other, and the validator reports that as an error instead.

Invalid example

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

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

Valid example

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

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

A field with the readonly attribute can't also have aria-readonly="false": remove aria-readonly and let the native attribute set the state.

The readonly attribute on an <input> or <textarea> already tells browsers and assistive technologies that the user can't change the value. aria-readonly="false" claims the opposite, so the field exposes two conflicting states. The ARIA in HTML specification forbids aria-readonly="false" on any element that has readonly, and the validator reports it as an error.

This often comes from a component or template that always outputs aria-readonly from a flag that defaults to false, while readonly is added separately. Decide what the field should be. If users shouldn't edit it, keep readonly and drop aria-readonly. If they should, remove readonly. aria-readonly is meant for custom widgets, such as an element with role="textbox" or a grid cell, which have no native readonly attribute.

Writing aria-readonly="true" next to readonly doesn't trigger this error. That combination is only redundant, and the validator reports it as a warning.

Invalid example

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

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

Valid example

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

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

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>

The HTML required attribute was introduced in HTML5 and tells both the browser and assistive technologies that a form field must be filled in before the form can be submitted. The aria-required attribute serves the same purpose but comes from the WAI-ARIA specification, which was designed to fill accessibility gaps in HTML. Now that required is widely supported, using both attributes on the same element is unnecessary duplication.

The W3C validator raises this warning because redundant ARIA attributes add noise to your markup without providing any benefit. One of the core principles of ARIA usage is the first rule of ARIA: if you can use a native HTML element or attribute that already has the semantics you need, use that instead of adding ARIA. The native required attribute provides built-in browser validation, visual cues, and accessibility information all at once — something aria-required alone cannot do.

Modern screen readers such as NVDA, JAWS, and VoiceOver all correctly interpret the native required attribute and announce the field as required to users. Keeping both attributes doesn't cause a functional problem, but it creates maintenance overhead, clutters your code, and signals to other developers that something special might be going on when it isn't.

How to fix it

1. If your element already has the required attribute, remove aria-required="true".
2. If your element only has aria-required="true" and you want browser-native validation, replace it with required.
3. In rare cases where you need to support assistive technologies that don't recognize the native required attribute (some very old screen reader versions), keeping both is a conscious trade-off — but for the vast majority of projects, the native attribute alone is sufficient.

Examples

❌ Redundant aria-required alongside required

<form action="/order">

<label for="city">City</label>

<input id="city" name="city" type="text" aria-required="true" required>

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

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

<label for="comments">Comments</label>

<textarea id="comments" name="comments" aria-required="true" required></textarea>

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

</form>

This triggers the validator warning on every element where both attributes appear.

✅ Using the native required attribute only

<form action="/order">

<label for="city">City</label>

<input id="city" name="city" type="text" required>

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

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

<label for="comments">Comments</label>

<textarea id="comments" name="comments" required></textarea>

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

</form>

✅ Using aria-required on a non-native element

There are valid use cases for aria-required — specifically when you build custom form controls that don't use native form elements. In that scenario, aria-required is the correct choice because the native required attribute has no effect on non-form elements.

<div role="combobox" aria-required="true" aria-expanded="false" aria-labelledby="color-label">

<span id="color-label">Favorite color</span>

</div>

Here, aria-required="true" is necessary because a <div> doesn't support the native required attribute.

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 autocomplete attribute tells the browser whether and how to automatically fill in a form field based on previously entered data. It makes sense for fields where users type or select values from a predictable set — like names, emails, addresses, dates, and numbers. However, certain input types don't produce text or numeric data that browsers could meaningfully store and recall. These include checkbox, radio, file, button, submit, reset, and image.

The HTML specification explicitly limits autocomplete to the following input types: color, date, datetime-local, email, hidden, month, number, password, range, search, tel, text, time, url, and week. Using it on any other type violates the spec and produces a validation error.

Why this matters

• Standards compliance: Browsers are not required to honor autocomplete on unsupported input types, so including it has no practical effect and produces invalid markup.
• Code clarity: Invalid attributes can confuse other developers reading your code, suggesting a behavior that doesn't actually exist.
• Accessibility: Screen readers and assistive technologies rely on valid markup to accurately convey form behavior to users. Unexpected attributes can introduce ambiguity.

How to fix it

1. Identify the input type that has the autocomplete attribute.
2. If the type is checkbox, radio, file, button, submit, reset, or image, remove the autocomplete attribute.
3. If you genuinely need autocomplete behavior, reconsider whether the correct input type is being used. For example, a field that should accept text input might have been incorrectly set to type="checkbox".

Examples

❌ Invalid: autocomplete on a checkbox

<form>

<label>

<input type="checkbox" name="terms" autocomplete="off"> I agree to the terms

</label>

</form>

The browser cannot meaningfully autocomplete a checkbox, so this attribute is not allowed here.

✅ Fixed: remove autocomplete from the checkbox

<form>

<label>

<input type="checkbox" name="terms"> I agree to the terms

</label>

</form>

❌ Invalid: autocomplete on radio buttons

<form>

<fieldset>

<legend>Preferred contact method</legend>

<label>

<input type="radio" name="contact" value="email" autocomplete="off"> Email

</label>

<label>

<input type="radio" name="contact" value="phone" autocomplete="off"> Phone

</label>

</fieldset>

</form>

✅ Fixed: remove autocomplete from radio buttons

<form>

<fieldset>

<legend>Preferred contact method</legend>

<label>

<input type="radio" name="contact" value="email"> Email

</label>

<label>

<input type="radio" name="contact" value="phone"> Phone

</label>

</fieldset>

</form>

❌ Invalid: autocomplete on a file input

<form>

<label for="resume">Upload resume:</label>

<input type="file" id="resume" name="resume" autocomplete="off">

</form>

✅ Fixed: remove autocomplete from the file input

<form>

<label for="resume">Upload resume:</label>

<input type="file" id="resume" name="resume">

</form>

✅ Valid: autocomplete on supported types

<form>

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

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

<label for="bday">Birthday:</label>

<input type="date" id="bday" name="bday" autocomplete="bday">

<label for="query">Search:</label>

<input type="search" id="query" name="query" autocomplete="off">

</form>

If you want to disable autocomplete for an entire form — including checkboxes and other non-text fields — set autocomplete="off" on the <form> element itself rather than on individual inputs that don't support the attribute:

<form autocomplete="off">

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

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

<label>

<input type="checkbox" name="remember"> Remember me

</label>

</form>

The <meta charset="utf-8"> declaration is not only valid but recommended by the HTML living standard. So when the validator complains that the charset attribute is "not allowed at this point," the problem isn't the <meta> tag itself — it's what surrounds it. The HTML parser follows strict rules about which elements can appear inside <head>. When it encounters an element that doesn't belong there (like <img>, <div>, <p>, or other flow/phrasing content), it implicitly closes the <head> and opens the <body>. Any <meta> tags that come after that point are now parsed as being inside <body>, where <meta charset> is not permitted.

This is a problem for several reasons. First, the <meta charset> declaration must appear within the first 1024 bytes of the document so browsers can determine the character encoding early. If the parser moves it out of <head>, browsers may not apply the encoding correctly, potentially leading to garbled text — especially for non-ASCII characters. Second, this often signals a structural error in your HTML that could cause other unexpected rendering issues.

Common causes include:

• An element that only belongs in <body> (like <img>, <div>, <span>, or <p>) placed before <meta charset> in the <head>.
• A stray closing tag (like </head>) appearing too early.
• A <script> tag with content that causes the parser to break out of <head>.

To fix the issue, inspect the elements that appear before <meta charset> in your <head>. Move any elements that don't belong in <head> into <body>, and place <meta charset="utf-8"> as the very first element inside <head>.

Examples

Incorrect — element before <meta> forces parser out of <head>

An <img> tag inside <head> causes the parser to implicitly close <head> and open <body>. The <meta charset> that follows is now parsed as being in <body>, triggering the error.

<!DOCTYPE html>

<html lang="en">

<head>

<title>My Page</title>

<img src="photo.jpg" alt="A smiling cat">

<meta charset="utf-8">

</head>

<body>

<p>Some content</p>

</body>

</html>

Correct — <meta charset> first, invalid elements moved to <body>

<!DOCTYPE html>

<html lang="en">

<head>

<meta charset="utf-8">

<title>My Page</title>

</head>

<body>

<img src="photo.jpg" alt="A smiling cat">

<p>Some content</p>

</body>

</html>

Incorrect — stray <div> in <head> breaks context

<!DOCTYPE html>

<html lang="en">

<head>

<div>Oops</div>

<meta charset="utf-8">

<title>My Page</title>

</head>

<body>

<p>Hello</p>

</body>

</html>

Correct — only valid head elements before <meta charset>

<!DOCTYPE html>

<html lang="en">

<head>

<meta charset="utf-8">

<title>My Page</title>

</head>

<body>

<div>Content goes here</div>

<p>Hello</p>

</body>

</html>

Best practice

As a general rule, always make <meta charset="utf-8"> the very first child of <head>. This ensures the browser detects the encoding as early as possible and avoids the risk of other elements accidentally breaking the parser context before the charset is declared.

The controlslist attribute was proposed to give developers a way to hint to the browser which default media controls to show or hide. It accepts values like nodownload, nofullscreen, and noremoteplayback, allowing you to selectively disable specific buttons in the browser's built-in media player UI. For example, controlslist="nodownload" hides the download button on the video player.

However, this attribute was never adopted into the WHATWG HTML Living Standard or any W3C specification. It remains a Chromium-specific feature, meaning it only works in browsers like Chrome and Edge. Firefox, Safari, and other non-Chromium browsers simply ignore it. Because it's not part of any standard, the W3C HTML Validator rightfully reports it as an invalid attribute.

While using controlslist won't break your page — browsers that don't recognize it will silently ignore it — relying on non-standard attributes has downsides:

• Standards compliance: Your HTML won't validate, which can mask other real issues in validation reports.
• Browser compatibility: The behavior only works in Chromium-based browsers, giving an inconsistent experience across browsers.
• Future uncertainty: Non-standard attributes can be removed or changed without notice.

To fix this, you have a few options. The simplest is to remove the attribute entirely if the customization isn't critical. If you need fine-grained control over media player buttons, the most robust approach is to build custom media controls using JavaScript and the HTMLMediaElement API. For the specific case of disabling remote playback, there is a standardized attribute — disableremoteplayback — that you can use instead.

Examples

❌ Invalid: Using the non-standard controlslist attribute

<video src="video.mp4" controls controlslist="nodownload nofullscreen"></video>

The validator will report: Attribute "controlslist" not allowed on element "video" at this point.

✅ Valid: Removing the attribute

<video src="video.mp4" controls></video>

The simplest fix is to remove controlslist and accept the browser's default controls.

✅ Valid: Using custom controls with JavaScript

<video id="my-video" src="video.mp4"></video>

<div class="custom-controls">

<button id="play-btn">Play</button>

<input id="seek-bar" type="range" min="0" max="100" value="0">

<button id="fullscreen-btn">Fullscreen</button>

</div>

<script>

const video = document.getElementById("my-video");

document.getElementById("play-btn").addEventListener("click", () => {

video.paused ? video.play() : video.pause();

});

</script>

By omitting the controls attribute and building your own UI, you have full control over which buttons appear — across all browsers.

✅ Valid: Using disableremoteplayback for that specific need

<video src="video.mp4" controls disableremoteplayback></video>

If your goal was specifically controlslist="noremoteplayback", the standardized disableremoteplayback attribute achieves the same result and is valid HTML.

Audio element

The same issue and solutions apply to the <audio> element:

<!-- ❌ Invalid -->

<audio src="song.mp3" controls controlslist="nodownload"></audio>

<!-- ✅ Valid -->

<audio src="song.mp3" controls></audio>

The HTML specification defines a specific set of allowed attributes for each element. The <span> element supports global attributes (such as id, class, style, title, etc.) but does not recognize currency as a valid attribute. When you add a non-standard attribute like currency to an element, the W3C validator flags it because it doesn't conform to the HTML standard.

This pattern often appears in e-commerce sites, financial applications, or internationalization contexts where developers want to associate a currency code (like USD, EUR, or GBP) with a price displayed in a <span>. While browsers will typically ignore unrecognized attributes without breaking the page, using them creates several problems:

• Standards compliance: Invalid HTML can lead to unpredictable behavior across different browsers and future browser versions.
• Maintainability: Other developers (or tools) won't recognize non-standard attributes, making the codebase harder to understand and maintain.
• Accessibility: Assistive technologies rely on valid, well-structured HTML. Non-standard attributes may be ignored or misinterpreted.
• JavaScript interoperability: The HTMLElement.dataset API is specifically designed to work with data-* attributes, providing a clean and standard way to read custom data from elements.

The fix is straightforward: HTML provides the data-* attribute mechanism specifically for embedding custom data on elements. Any attribute prefixed with data- is valid on any HTML element, and its value is accessible in JavaScript via the element.dataset property.

Examples

❌ Invalid: Non-standard currency attribute

<span currency="USD">49.99</span>

This triggers the validation error because currency is not a recognized attribute for <span>.

✅ Fixed: Using a data-currency attribute

<span data-currency="USD">49.99</span>

The data-currency attribute is valid HTML. In JavaScript, you can access its value like this:

const span = document.querySelector('span');

console.log(span.dataset.currency); // "USD"

✅ Alternative: Using data-* with richer markup

If you need to convey more structured information, you can combine multiple data-* attributes:

<span class="price" data-currency="EUR" data-amount="29.99">€29.99</span>

✅ Alternative: Using microdata or structured markup

For SEO and machine-readable data, consider using established vocabularies like Schema.org:

<span itemscope itemtype="https://schema.org/MonetaryAmount">

<meta itemprop="currency" content="USD">

<span itemprop="value">49.99</span>

</span>

This approach provides semantic meaning that search engines and other consumers can understand, while remaining fully valid HTML.

The HTML specification defines a specific set of global attributes (like class, id, title, style, etc.) that are allowed on all elements, plus element-specific attributes for certain tags. Any attribute that isn't part of these standard sets and doesn't follow the data-* custom attribute convention is considered invalid and will trigger a validation error.

This issue is especially common with older integrations of third-party tools like ShareThis, AddThis, or similar social sharing widgets, particularly when embedded through a CMS like Drupal or WordPress. These older implementations relied on proprietary attributes such as displayText, st_url, and st_title directly on <span> or other elements. Modern versions of these tools have since migrated to valid data-* attributes.

Why This Matters

• Standards compliance: Non-standard attributes violate the HTML specification, meaning your markup is technically invalid and may behave unpredictably across browsers.
• Forward compatibility: Browsers could introduce a native displaytext attribute in the future with entirely different behavior, causing conflicts with your code.
• Accessibility: Assistive technologies rely on well-formed HTML. Non-standard attributes can confuse screen readers or other tools that parse the DOM.
• Maintainability: Using the standardized data-* convention makes it immediately clear to other developers that an attribute holds custom data, improving code readability.

How to Fix It

1. Identify all non-standard attributes on your elements (e.g., displayText, st_url, st_title).
2. Prefix each one with data- to convert it into a valid custom data attribute (e.g., data-displaytext, data-st-url, data-st-title).
3. Update any JavaScript that references these attributes. If JavaScript accesses them via element.getAttribute('displayText'), change it to element.getAttribute('data-displaytext') or use the dataset API (element.dataset.displaytext).
4. If using a CMS or third-party plugin, update the plugin or module to its latest version, which likely uses valid data-* attributes already.

Note that data-* attribute names should be all lowercase. Even if the original attribute used camelCase like displayText, the corrected version should be data-displaytext.

Examples

Invalid: Non-standard attribute on a <span>

<span class="st_sharethis" displaytext="ShareThis" st_url="https://example.com" st_title="My Page">

Share

</span>

This triggers validation errors for displaytext, st_url, and st_title because none of these are valid HTML attributes.

Valid: Using data-* attributes

<span class="st_sharethis" data-displaytext="ShareThis" data-st-url="https://example.com" data-st-title="My Page">

Share

</span>

Accessing data-* attributes in JavaScript

If your JavaScript relied on the old attribute names, update the references:

<span id="share-btn" data-displaytext="ShareThis">Share</span>

<script>

const btn = document.getElementById('share-btn');

// Using getAttribute

const text = btn.getAttribute('data-displaytext');

// Using the dataset API

const textAlt = btn.dataset.displaytext;

</script>

Valid: Using a standard attribute instead

In some cases, the intent of displaytext is simply to provide a label or tooltip. If so, a standard attribute like title may be more appropriate:

<span class="st_sharethis" title="ShareThis">Share</span>

Choose the approach that best matches your use case — data-* for custom data consumed by JavaScript, or a semantic HTML attribute if one already serves the purpose.

The <table> element in HTML supports a limited set of attributes — primarily global attributes like class, id, and style. The height attribute was never part of the HTML standard for tables (unlike width, which was valid in HTML 4 but has since been deprecated). Despite this, many browsers historically accepted height on <table> as a non-standard extension, which led to its widespread but incorrect use.

Because height is not a recognized attribute on <table>, using it means your markup is invalid and may behave inconsistently across browsers. Some browsers might honor it, others might ignore it entirely, and future browser versions could change their behavior at any time. Relying on non-standard attributes makes your code fragile and harder to maintain.

The fix is straightforward: remove the height attribute from the <table> element and use CSS to set the desired height. You can apply the CSS inline via the style attribute, or better yet, use an external or internal stylesheet with a class or ID selector.

Examples

❌ Invalid: height attribute on <table>

<table height="300">

<tr>

<td>Name</td>

<td>Score</td>

</tr>

<tr>

<td>Alice</td>

<td>95</td>

</tr>

</table>

This triggers the validator error: Attribute "height" not allowed on element "table" at this point.

✅ Fixed: Using inline CSS

<table style="height: 300px;">

<tr>

<td>Name</td>

<td>Score</td>

</tr>

<tr>

<td>Alice</td>

<td>95</td>

</tr>

</table>

✅ Fixed: Using a CSS class (preferred)

<style>

.tall-table {

height: 300px;

}

</style>

<table class="tall-table">

<tr>

<td>Name</td>

<td>Score</td>

</tr>

<tr>

<td>Alice</td>

<td>95</td>

</tr>

</table>

Using a class keeps your HTML clean and makes it easy to adjust the styling later without touching the markup. Note that min-height is often a better choice than height for tables, since table content can naturally grow beyond a fixed height, and min-height ensures the table is at least a certain size without clipping content.

Why This Happens

In HTML, certain attributes are boolean and can appear without a value (e.g., disabled, required). The href attribute is not one of them — it expects a valid URL, path, or fragment identifier as its value. When a validator encounters href with no value or an empty value, it raises a warning because the attribute is being used in a way that doesn't conform to the specification.

Writing <a href> produces a valueless attribute. Writing <a href=""> produces an attribute whose value is an empty string, which resolves to the current page's URL per the rules of relative URL resolution. Both forms are problematic:

• href without a value: The HTML spec requires href to contain a valid URL. A valueless attribute is ambiguous and was actively dropped by IE7, meaning the element would lose its link behavior entirely in that browser.
• href="": While technically parsed as a relative URL pointing to the current document, this is almost never the developer's intention. It causes the page to reload or scroll to the top when clicked, which is confusing for users and harmful for accessibility.

The Impact

• Accessibility: Screen readers rely on the href attribute to identify an <a> element as an interactive link. A missing or empty value creates confusion — the screen reader may announce it as a link but provide no destination, or may not treat it as a link at all.
• Browser compatibility: As the validator message notes, IE7 would strip the attribute entirely, meaning the element lost its link semantics and styling. While IE7 is no longer in common use, valueless attributes can still cause edge-case issues in parsers, crawlers, and automated tools.
• Standards compliance: Valid HTML ensures consistent rendering and behavior across browsers, assistive technologies, and search engine crawlers.

How to Fix It

The fix depends on your intent:

1. If the element should link somewhere, provide a real URL: href="https://example.com" or href="/about".
2. If the element is a placeholder link (e.g., during development or for JavaScript-driven actions), use href="#" and prevent the default navigation with JavaScript.
3. If the element doesn't need to be a link at all, use a <button> for interactive actions or a <span> for non-interactive text. This is often the most semantically correct choice.

Examples

❌ Incorrect: href without a value

<a href>Click here</a>

This triggers the validation warning. The attribute has no value, which is invalid for href.

❌ Incorrect: href with an empty string

<a href="">Click here</a>

This resolves to the current page URL, likely causing an unintended page reload.

✅ Correct: Provide a real URL

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

✅ Correct: Use a fragment as a placeholder

<a href="#" onclick="doSomething(); return false;">Perform action</a>

The return false prevents the page from scrolling to the top. A better modern approach uses event.preventDefault():

<a href="#" id="action-link">Perform action</a>

<script>

document.getElementById("action-link").addEventListener("click", function (e) {

e.preventDefault();

doSomething();

});

</script>

✅ Correct: Use a <button> for actions

If the element triggers a JavaScript action rather than navigating somewhere, a <button> is the most semantically appropriate choice:

<button type="button" onclick="doSomething();">Perform action</button>

Buttons are natively focusable, keyboard-accessible, and clearly communicate interactive intent to assistive technologies — no href needed.

✅ Correct: Use a <span> for non-interactive text

If the element is purely visual and shouldn't be interactive at all:

<span class="label">Not a link</span>

This removes any expectation of interactivity for both the browser and the user.

The http-equiv attribute on a <meta> element simulates an HTTP response header, allowing you to define document-level metadata that would otherwise require server configuration. Because this metadata applies to the entire document and must be processed before the page content is rendered, the HTML specification requires that <meta http-equiv> elements appear within the <head> element. Placing them in the <body> is invalid and may cause browsers to ignore them entirely, leading to unexpected behavior like incorrect character encoding, broken content security policies, or missing refresh directives.

This error commonly occurs when:

• A <meta http-equiv> tag is accidentally placed inside <body>.
• Content is copy-pasted from one document into the body of another, bringing along <meta> tags.
• A templating system or CMS injects <meta> tags in the wrong location.

Common http-equiv values

The http-equiv attribute supports several standard values:

• content-type — Declares the document's MIME type and character encoding. In HTML5, the shorthand <meta charset="UTF-8"> is preferred instead.
• refresh — Instructs the browser to reload the page or redirect after a specified number of seconds. Note that automatic refreshing is discouraged for accessibility reasons: it can disorient users, move focus back to the top of the page, and disrupt assistive technology. Avoid it unless absolutely necessary.
• content-security-policy — Defines a Content Security Policy for the document, helping prevent cross-site scripting (XSS) and other code injection attacks.
• default-style — Specifies the preferred stylesheet from a set of alternative stylesheets.

How to fix it

Find every <meta http-equiv> element in your document and ensure it is placed inside the <head> element, before any content in <body>. If the tag is duplicated or unnecessary, remove it.

Examples

❌ Incorrect: http-equiv inside <body>

<!DOCTYPE html>

<html lang="en">

<head>

<title>My Page</title>

</head>

<body>

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

<p>Hello, world!</p>

</body>

</html>

The <meta http-equiv> tag is inside <body>, which triggers the validation error.

✅ Correct: http-equiv inside <head>

<!DOCTYPE html>

<html lang="en">

<head>

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

<title>My Page</title>

</head>

<body>

<p>Hello, world!</p>

</body>

</html>

✅ Correct: using the HTML5 charset shorthand

In HTML5, you can replace <meta http-equiv="content-type" content="text/html; charset=UTF-8"> with the simpler charset attribute:

<!DOCTYPE html>

<html lang="en">

<head>

<meta charset="UTF-8">

<title>My Page</title>

</head>

<body>

<p>Hello, world!</p>

</body>

</html>

✅ Correct: Content Security Policy in <head>

<head>

<meta charset="UTF-8">

<meta http-equiv="content-security-policy" content="default-src 'self'">

<title>Secure Page</title>

</head>

The content-security-policy value is particularly placement-sensitive — browsers will ignore it if it appears outside <head>, leaving your page without the intended security protections.

The W3C HTML Validator reports this error when it encounters isolang on the <html> element because isolang is not a recognized attribute in any version of HTML. This typically happens when developers attempt to specify the document's language but use an incorrect or made-up attribute name, possibly confusing it with ISO language code terminology.

The correct attribute for declaring a document's language is lang. This attribute accepts a valid BCP 47 language tag, which in most cases is a simple two-letter ISO 639-1 code (like en for English, fr for French, or pt for Portuguese). You can also use extended subtags for regional variants, such as en-US for American English or pt-BR for Brazilian Portuguese.

Setting the lang attribute properly is important for several reasons:

• Accessibility: Screen readers use the lang attribute to select the correct pronunciation rules, ensuring content is read aloud accurately.
• SEO: Search engines use the language declaration to serve the right content to users based on their language preferences.
• Browser behavior: Browsers rely on lang for features like spell-checking, hyphenation, and selecting appropriate default fonts for the given language.
• Standards compliance: Only recognized attributes pass W3C validation, and valid markup ensures consistent, predictable behavior across browsers.

To fix this issue, simply replace isolang with lang on your <html> element. Keep the same language code value—it's the attribute name that's wrong, not the value.

Examples

❌ Incorrect: Using the invalid isolang attribute

<!DOCTYPE html>

<html isolang="pt">

<head>

<title>Minha Página</title>

</head>

<body>

<p>Olá, mundo!</p>

</body>

</html>

This triggers the error: Attribute "isolang" not allowed on element "html" at this point.

✅ Correct: Using the lang attribute

<!DOCTYPE html>

<html lang="pt">

<head>

<title>Minha Página</title>

</head>

<body>

<p>Olá, mundo!</p>

</body>

</html>

✅ Correct: Using a regional language subtag

<!DOCTYPE html>

<html lang="pt-BR">

<head>

<title>Minha Página</title>

</head>

<body>

<p>Olá, mundo!</p>

</body>

</html>

Common language codes

Here are some frequently used ISO 639-1 language codes for the lang attribute:

• en — English
• es — Spanish
• fr — French
• de — German
• pt — Portuguese
• zh — Chinese
• ja — Japanese
• ar — Arabic
• ko — Korean
• ru — Russian

The aria-labelledby attribute is part of the WAI-ARIA specification and provides an accessible name for an element by referencing the id values of other elements that contain the labeling text. Without the aria- prefix, labelledby is simply an unrecognized attribute that browsers and assistive technologies will ignore. This means your SVG graphic won't have the accessible label you intended, leaving screen reader users without a meaningful description of the content.

This issue is especially important for <svg> elements because SVG graphics are often used for icons, charts, and illustrations that need descriptive labels for accessibility. Using the incorrect attribute name means the graphic is effectively unlabeled for users who rely on assistive technology.

How to Fix It

Replace labelledby with aria-labelledby on your <svg> element. The attribute's value should be a space-separated list of one or more id values that reference elements containing the label text.

If you want to label an SVG using text that's already visible on the page, aria-labelledby is the ideal approach. You can also reference a <title> element inside the SVG itself.

Examples

❌ Incorrect: Using labelledby (invalid attribute)

<h2 id="chart-title">Monthly Sales</h2>

<svg labelledby="chart-title" role="img" viewBox="0 0 200 100">

<!-- chart content -->

</svg>

✅ Correct: Using aria-labelledby to reference an external heading

<h2 id="chart-title">Monthly Sales</h2>

<svg aria-labelledby="chart-title" role="img" viewBox="0 0 200 100">

<!-- chart content -->

</svg>

✅ Correct: Using aria-labelledby to reference the SVG's own <title>

<svg aria-labelledby="icon-title" role="img" viewBox="0 0 24 24">

<title id="icon-title">Search</title>

<path d="M15.5 14h-.79l-.28-.27A6.47 6.47 0 0 0 16 9.5 6.5 6.5 0 1 0 9.5 16c1.61 0 3.09-.59 4.23-1.57l.27.28v.79l5 4.99L20.49 19l-4.99-5z"/>

</svg>

✅ Correct: Referencing multiple label sources

You can combine multiple id values to build a composite accessible name, separated by spaces:

<h2 id="section-title">Revenue</h2>

<p id="section-desc">Q1 2024 revenue by region</p>

<svg aria-labelledby="section-title section-desc" role="img" viewBox="0 0 400 200">

<!-- chart content -->

</svg>

In this case, a screen reader would announce something like "Revenue Q1 2024 revenue by region" as the accessible name for the SVG.

Tips

• When using aria-labelledby on <svg>, also add role="img" to ensure consistent behavior across screen readers.
• If the SVG is purely decorative, use aria-hidden="true" instead of labeling it.
• The aria-labelledby attribute overrides other labeling mechanisms like aria-label or the <title> element, so use it when you want a specific label to take precedence.

The maxlength attribute provides built-in client-side validation that caps the number of characters a user can type into a field. Browsers enforce this by preventing further input once the limit is reached. However, this behavior only makes sense for input types that accept arbitrary text strings. Input types like number, date, range, and checkbox have their own value formats and constraints — a number input's value is controlled by min, max, and step, not by character count.

When you place maxlength on an unsupported input type, browsers will ignore the attribute. This means it provides no actual validation while giving a false sense of security. It also produces invalid HTML, which can cause issues with assistive technologies that may try to interpret the attribute and relay incorrect information to users. Keeping your markup valid ensures predictable behavior across browsers and a better experience for all users.

How to fix it

1. Remove maxlength from any <input> whose type is not email, password, search, tel, text, or url.
2. Use the correct constraint attributes for the input type in question. For number inputs, use min and max. For date inputs, use min and max with date strings.
3. If you genuinely need character-length validation, consider whether a text-based input type is more appropriate for your use case, or implement the constraint in JavaScript.

Examples

❌ Invalid: maxlength on a number input

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

<input type="number" id="quantity" name="quantity" maxlength="3">

The number type does not support maxlength. Browsers will ignore it, and the HTML is invalid.

✅ Fixed: using min and max for a number input

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

<input type="number" id="quantity" name="quantity" min="0" max="999">

If the goal was to limit the value to three digits, min and max are the correct constraints.

❌ Invalid: maxlength on a date input

<label for="start-date">Start date</label>

<input type="date" id="start-date" name="start-date" maxlength="10">

Date inputs have a browser-provided date picker, and their values are always in YYYY-MM-DD format. The maxlength attribute has no effect here.

✅ Fixed: using min and max for a date input

<label for="start-date">Start date</label>

<input type="date" id="start-date" name="start-date" min="2020-01-01" max="2030-12-31">

❌ Invalid: maxlength on a checkbox

<label>

<input type="checkbox" name="agree" maxlength="1"> I agree

</label>

A checkbox is a boolean toggle — character length is meaningless here.

✅ Fixed: removing the invalid attribute

<label>

<input type="checkbox" name="agree"> I agree

</label>

✅ Valid: maxlength on supported text-based types

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

<input type="text" id="username" name="username" maxlength="30">

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

<input type="email" id="user-email" name="email" maxlength="254">

<label for="user-phone">Phone</label>

<input type="tel" id="user-phone" name="phone" maxlength="15">

<label for="site-url">Website</label>

<input type="url" id="site-url" name="website" maxlength="2048">

<label for="user-pass">Password</label>

<input type="password" id="user-pass" name="password" maxlength="128">

<label for="query">Search</label>

<input type="search" id="query" name="q" maxlength="100">

All six of these input types support maxlength because they accept free-form text where limiting character count is meaningful.

The minlength attribute defines the minimum number of characters (as UTF-16 code units) that a user can enter into a text-based input field. It provides built-in client-side validation without requiring JavaScript. However, it only makes sense on input types where the user is typing free-form text. For input types like number, date, color, range, or checkbox, the concept of a minimum character length doesn't apply — these inputs have their own constrained value formats or use other attributes like min and max for validation.

When the W3C validator encounters minlength on an unsupported input type, it flags the attribute as invalid. Browsers will typically ignore the attribute silently, meaning your intended validation won't actually work. This can lead to a false sense of security where you believe the input is being validated when it isn't.

The minlength value must be a non-negative integer (0 or higher) and must be less than or equal to maxlength if both are specified. The minlength attribute also works on <textarea> elements.

Examples

❌ Incorrect: minlength on a number input

The number input type doesn't support minlength. If you want to enforce a minimum value, use the min attribute instead.

<label for="age">Enter your age</label>

<input type="number" minlength="1" id="age">

✅ Fixed: Using min for number inputs

<label for="age">Enter your age</label>

<input type="number" min="1" id="age">

❌ Incorrect: minlength on a date input

<label for="start-date">Start date</label>

<input type="date" minlength="10" id="start-date">

✅ Fixed: Remove minlength from date inputs

Date inputs have a browser-controlled format, so character length constraints don't apply. Use min and max to constrain the date range.

<label for="start-date">Start date</label>

<input type="date" min="2024-01-01" id="start-date">

✅ Correct: minlength on supported input types

Here are valid uses of minlength across all supported input types:

<label for="username">Username (at least 3 characters)</label>

<input type="text" minlength="3" id="username">

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

<input type="email" minlength="5" id="email">

<label for="pass">Password (at least 8 characters)</label>

<input type="password" minlength="8" id="pass">

<label for="phone">Phone number</label>

<input type="tel" minlength="7" id="phone">

<label for="query">Search</label>

<input type="search" minlength="2" id="query">

<label for="website">Website URL</label>

<input type="url" minlength="10" id="website">

✅ Correct: minlength with maxlength on a textarea

<label for="bio">Bio (between 10 and 200 characters)</label>

<textarea minlength="10" maxlength="200" id="bio"></textarea>

Quick Reference