> 
Wiki
 / 
[aria-hidden="true"] is present on the document <body>

Accessibility Errors in Google Lighthouse

Reset filters
Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.
<dl>s do not contain only properly ordered <dt> and <dd> groups, <script>, or <template> elements
<frame> or <iframe> elements do not have a title
<html> element does not have a [lang] attribute
<html> element does not have a valid value for its [lang] attribute
<input type="image"> elements do not have [alt] text
<object> elements do not have [alt] text
<th> elements and elements with [role="columnheader"/"rowheader"] do not have data cells they describe
<video> elements do not contain a <track> element with [kind="captions"]
ARIA IDs are not all unique
Background and foreground colors do not have a sufficient contrast ratio
Buttons do not have an accessible name
Cells in a <table> element that use the [headers] attribute refer to an element id not found within the same table
Custom controls have ARIA roles
Custom controls have associated labels
Definition list items are not wrapped in <dl> elements
Document doesn't have a <title> element
Elements with an ARIA [role] that require children to contain a specific [role] are missing some or all of those required children
Form elements do not have associated labels
Form fields have multiple labels
HTML5 landmark elements are used to improve navigation
Heading elements are not in a sequentially-descending order
Image elements do not have [alt] attributes
Interactive controls are keyboard focusable
Interactive elements indicate their purpose and state
Links do not have a discernible name
List items (<li>) are not contained within <ul> or <ol> parent elements
Lists do not contain only <li> elements and script supporting elements (<script> and <template>)
Not all ARIA input fields have accessible names
Not all ARIA toggle fields have accessible names
Offscreen content is hidden from assistive technology
Presentational <table> elements do not avoid using <th>, <caption>, or the [summary] attribute
Some elements have a [tabindex] value greater than 0
The document uses <meta http-equiv="refresh">
The page does not contain a heading, skip link, or landmark region
The page has a logical tab order
The user's focus is directed to new content added to the page
User focus is not accidentally trapped in a region
Visual order on the page follows DOM order
[accesskey] values are not unique
[aria-*] attributes are not valid or misspelled
[aria-*] attributes do not have valid values
[aria-*] attributes do not match their roles
[aria-hidden="true"] elements contain focusable descendants
[aria-hidden="true"] is present on the document <body>
[id] attributes on active, focusable elements are not unique
[lang] attributes do not have a valid value
[role] values are not valid
[role]s are not contained by their required parent element
[role]s do not have all required [aria-*] attributes
[user-scalable="no"] is used in the <meta name="viewport"> element or the [maximum-scale] attribute is greater than 5

[aria-hidden="true"] is present on the document <body>

This is not a problem with native Webflow.

Using CSS to hide elements (such as a mobile menu) does NOT need ARIA.

If you create a <button> using ARIA roles, take care with this audit criteria.

‍

Google Lighthouse says

Users of screen readers and other assistive technologies need information about the behavior and purpose of controls on your web page. Built-in HTML controls like buttons and radio groups come with that information built in. For custom controls you create, however, you must provide the information with ARIA roles and attributes. (Learn more in the Introduction to ARIA.)

Screen readers and other assistive technologies don't announce content that's marked as hidden. Applying the aria-hidden="true" attribute to your <body> element hides your entire web page from assistive technology users.