HTML Guide
To fix the W3C HTML Validator issue stating that an element with a role="menuitem" must be contained in, or owned by, an element with role="menubar" or role="menu", you need to ensure that your menuitem elements are properly nested within a menubar or menu element. This is important for accessibility, as it helps assistive technologies understand the structure and relationship of the elements.
The menuitem role indicates the element is an option in a set of choices contained by a menu or menubar.
Here is a step-by-step guide to fixing this issue:
1. Using role="menubar"
If your menuitem elements are part of a horizontal menu (like a navigation bar), they should be nested within an element with role="menubar".
Example:
<nav role="menubar">
<div role="menuitem">Home</div>
<div role="menuitem">About</div>
<div role="menuitem">Contact</div>
</nav>
2. Using role="menu"
If your menuitem elements are part of a submenu or a vertical menu, they should be contained within an element with role="menu".
Example:
<div role="menu">
<div role="menuitem">Item 1</div>
<div role="menuitem">Item 2</div>
<div role="menuitem">Item 3</div>
</div>
Ensuring Proper Nesting
Ensure that all your menuitem elements are either directly or indirectly (via a child-parent relationship) contained within a menubar or menu element.
Complete Example with Nested Menus:
Here is a more complex example, including nested menus for a drop-down scenario.
Example:
<nav role="menubar">
<div role="menuitem">Home</div>
<div role="menuitem">
About
<div role="menu">
<div role="menuitem">Team</div>
<div role="menuitem">History</div>
</div>
</div>
<div role="menuitem">Contact</div>
</nav>
In this example, the main navigation (menubar) contains menuitem elements, and one of those menuitem elements contains a nested menu with additional menuitem elements inside it.
By ensuring your menuitem elements are contained within appropriate parent elements (menubar or menu), you will resolve the W3C HTML Validator issue and improve your web page’s accessibility.
Elements with the role tab must either be a child of an element with the tablist role, or have their id part of the aria-owns property of a tablist.
An element with the tab role controls the visibility of an associated element with the tabpanel role. The common user experience pattern is a group of visual tabs above, or to the side of, a content area, and selecting a different tab changes the content and makes the selected tab more prominent than the other tabs.
Example:
<div class="tabs">
<div role="tablist" aria-label="Sample Tabs">
<button role="tab" aria-selected="true" aria-controls="panel-1" id="tab-1" tabindex="0">
First Tab
</button>
<button role="tab" aria-selected="false" aria-controls="panel-2" id="tab-2" tabindex="-1">
Second Tab
</button>
</div>
<div id="panel-1" role="tabpanel" tabindex="0" aria-labelledby="tab-1">
<p>Content for the first panel</p>
</div>
<div id="panel-2" role="tabpanel" tabindex="0" aria-labelledby="tab-2" hidden>
<p>Content for the second panel</p>
</div>
</div>
A button element, or an element with the role=button attribute, is not allowed to be nested inside an <a> element.
A descendant element with a tabindex attribute cannot be nested inside an element that uses role="button".
The role="button" attribute marks an element as a button for assistive technologies, but true button elements (using the button tag) should typically manage focus and tab order on their own. Adding a nested element with tabindex inside a role=”button” container can confuse keyboard navigation and accessibility tools. Each tabbable element should have a clear, non-overlapping place in the focus order.
Incorrect example (causes the error):
<div role="button">
<span tabindex="0">Click me</span>
</div>
Corrected example 1: Move tabindex to the container
<div role="button" tabindex="0">
<span>Click me</span>
</div>
Corrected example 2: Use a native button element
<button>
<span>Click me</span>
</button>
Whenever possible, use native elements like button, as they provide correct focus, keyboard, and accessibility behavior without extra attributes or roles. Only use role="button" with proper keyboard and accessibility support if absolutely necessary, and avoid tabbable descendants within such containers.
An <a> element cannot contain a descendant element with the attribute tabindex.
A button element cannot contain a descendant element with the attribute tabindex.
The id attribute of an HTML element, used to identify the element when linking, scripting or styling, must be unique in the whole document and must not contain whitespace.
Technically, in HTML5, the value for an id attribute may contain any character, except whitespace characters. However, to avoid inadvertent errors, only ASCII letters, digits, _, and - should be used and the value for an id attribute should start with a letter.
<img> tags, used to include images on a document, require an alt attribute to describe the contents of the image. This is essential for users that cannot see the image (like screen reader users), or as an alternate text when the image cannot be displayed. Example:
<img src="photo.jpg" alt="Person holding a cat" />
When an img element has an empty alt attribute, its role is implicitly decorative, so it must not specify a role attribute.
The autocomplete attribute is used to control if the browser can provide assistance in filling out form field values, and it only makes sense for visible, not hidden, inputs.
It is available on <input> elements that take a text or numeric value as input, <textarea> elements, <select> elements, and <form> elements.
To fix this issue, you can remove the autocomplete attribute from the input element with type=hidden. Here is an example:
<!-- Wrong code -->
<input type="hidden" name="phone" value="12345" autcomplete="off">
<!-- Correct code -->
<input type="hidden" name="phone" value="12345">
The aria-* attributes are part of the WAI-ARIA (Web Accessibility Initiative-Accessible Rich Internet Applications) suite. They are used to improve the accessibility of web pages. However, when we use an input element with a type attribute whose value is hidden, we imply that the element is invisible and has no interaction with the user. Therefore, it doesn’t make sense to add aria-* attributes to it.
To fix this issue, you need to remove the aria-* attributes from the input element with type=hidden. Here is an example:
<!-- Wrong code -->
<input type="hidden" name="referer" value="https://example.com" aria-invalid="false">
<!-- Correct code -->
<input type="hidden" name="referer" value="https://example.com">
When nesting an input element inside a label that has a for attribute, the id attribute of the input is required to match it.
The label element represents a caption in a user interface. The caption can be associated with a specific form control, known as the label element’s labeled control, either using the for attribute, or by putting the form control inside the label element itself.
When the input is inside the label, there’s no need to specify a for attribute as there can only be one input, as in this example:
<label>
Age
<input type="text" name="age">
</label>
However, if the for attribute is specified, then it must match the id of the input like this:
<label for="user_age">
Age
<input type="text" name="age" id="user_age">
</label>
When nesting a select element inside a label that has a for attribute, the id attribute of the select is required to match it.
The label element represents a caption in a user interface. The caption can be associated with a specific form control, known as the label element’s labeled control, either using the for attribute, or by putting the form control inside the label element itself.
When the select is inside the label, there’s no need to specify a for attribute as there can only be one select, as in this example:
<label>
Age
<select>
<option>young</option>
<option>old</option>
</select>
</label>
However, if the for attribute is specified, then it must match the id of the select like this:
<label for="age">
Age
<select id="age">
<option>young</option>
<option>old</option>
</select>
</label>
The <article> element can be used to define complete, self-contained compositions of a document, for example blog posts. Consider using a heading element (any of <h2> to </h6>) to present each article.
Example:
<h1>Our blog</h1>
<article>
<h2>How to validate accessibility</h2>
<p>Use Rocket Validator for a in-depth scan</p>
</article>
<article>
<h2>How to monitor sites for accessibility</h2>
<p>Define schedules in Rocket Validator</p>
</article>
The aria-required attribute is used to indicate to screen reader users that a form input is required. As there is now in HTML a general required attribute which works with most user agents, it’s unnecessary to use both at the same time. In general, you can rely solely on the required attribute, unless you want to provide backwards compatibility on old screen reader software versions.
Example:
<form action="order.">
<!-- This will raise a warning on unnecesary attributes -->
<input id="city" name="city" aria-required="true" required />
<!-- You can use this instead -->
<input id="city" name="city" required />
</form>
The autocomplete attribute is not valid on input types that do not return numeric or text data, being valid for all input types except checkbox, radio, file, or any of the button types.
A <meta> tag has been found that is either malformed, or in a bad place within the document. Check its attributes and context.
For example, the following HTML contains a valid <meta> tag that is raising an issue because of bad context, caused by an <img> tag that shouldn’t be there:
<!DOCTYPE html>
<html lang="">
<head>
<title>Test</title>
<img src="photo.jpg" alt="A smiling cat" />
<meta charset="utf-8" />
</head>
<body>
<p>Some content</p>
</body>
</html>
If we fix that document and move the <img> tag within the body, the issue raised about <meta> disappears because it’s now in a valid context:
<!DOCTYPE html>
<html lang="">
<head>
<title>Test</title>
<meta charset="utf-8" />
</head>
<body>
<p>Some content</p>
<img src="photo.jpg" alt="A smiling cat" />
</body>
</html>
The controlslist attribute on the <video> element is experimental, and not yet valid in the current HTML5 standard, so you should use it with caution as it may not be supported by all browsers.
The <span> element does not have a currency attribute. Consider using custom data attributes instead, like data-currency.
The attribute displayText is not allowed on <span> elements.
This issue is commonly caused by an old integration of ShareThis via Drupal or other CMS - the old code used invalid attributes like displayText, st_url and st_title which were later changed to HTML5 custom data attributes.
The <table> element does not accept a height attribute. Use CSS instead.
Empty href attributes like href or href="" are invalid in HTML and can cause unpredictable behavior.
According to the HTML specification, the href attribute in elements such as the a and link tags must contain a valid URL or fragment reference. An empty or omitted href results in the attribute being ignored or possibly causing compatibility problems, especially in older browsers. If you intend the link to do nothing, use href="#" and prevent the default action with JavaScript, or avoid making it a link if no action is necessary.
Valid HTML for a regular link:
<a href="https://example.com">Visit Example</a>
Valid usage for a link that does nothing:
<a href="#" onclick="return false;">Do nothing</a>
If the element should not be clickable, use a different tag such as span or button:
<span>Not a link</span>
or
<button type="button">Not a link</button>
Avoid writing:
<a href>Invalid link</a>
or
<a href="">Invalid link</a>
as these will produce the validation warning you saw.
A <meta> element using the http-equiv attribute has been found in an unexpected place of the document. It should appear inside the <head> section, like in this example:
<!DOCTYPE html>
<html lang="">
<head>
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<title>Test</title>
</head>
<body>
<p>Content of the page</p>
</body>
</html>
The http-equiv attribute is used in web pages to simulate an HTTP response header. While HTTP response headers can be set from the server, not everyone has access to the server configuration, so an alternative is using <meta http-equiv> to define settings that would otherwise require setting an HTTP response header.
The most popular use of http-equiv are defining the content-type of the document as in the example above, although in HTML5 it’s preferred to use this instead:
<meta charset="UTF-8">
Another popular use of the http-equiv is setting an automatic reload of the web page, for example this will have the browser reload the page every 60 seconds:
<meta http-equiv="refresh" content="60">
However, refreshing a page automatically is a bad practice regarding accessibility, as users do not expect a page to do that, and doing so will move focus back to the top of the page, which may create a frustrating or confusing experience.
Other values that can be used with the http-equiv attribute include:
- content-security-policy
- content-length.
- content-encoding
- default-style
- window-target
Instead of using the isolang attribute to define the language of the document, you can use lang with an ISO 639-1 two character code.
For example, for Portuguese:
<html lang="pt">
labelledby is not a valid attribute for the <svg> element. Perhaps you meant aria-labelledby?
The aria-labelledby attribute establishes relationships between objects and their label(s), and its value should be one or more element IDs, which refer to elements that have the text needed for labeling.
Example:
<div id="myBillingId">Billing</div>
<div>
<div id="myNameId">Name</div>
<input type="text" aria-labelledby="myBillingId myNameId"/>
</div>
<div>
<div id="myAddressId">Address</div>
<input type="text" aria-labelledby="myBillingId myAddressId"/>
</div>