Google Lighthouse is one of the most popular tools for auditing website performance, search engine optimization (SEO), and accessibility. It has some major advantages over similar tools — perhaps most importantly, it’s free — and many developers use Lighthouse metrics to measure whether they’re meeting their goals.
However, like all automated accessibility tools, Lighthouse has significant limitations. It’s still a useful resource, but developers should understand those limitations in order to use it effectively. Here’s a look at six web accessibility barriers that Lighthouse will typically miss.
1. Inaccurate Subheadings and Titles
Automated accessibility tests work well when addressing issues that have simple “pass/fail" criteria. When barriers require human judgment, automation becomes less reliable.
The Web Content Accessibility Guidelines (WCAG) are the international standard for digital accessibility. The guidelines require webmasters to use proper semantic markup — including accurate page titles and subheadings.
This is important because many people with disabilities use assistive technology to browse the internet. People with vision impairments may use screen readers, which convert onscreen text to audio or braille.
Listening to every bit of content on a website can be time consuming, and many screen reader users “scan" through pages to find the content they need. The page title and subheadings make scanning much easier — as long as the webmaster writes clear, accurate information with the proper semantic markup.
Google Lighthouse can detect whether subheadings appear in sequential order (<h3> tags follow <h2> tags, <h4> tags follow <h3> tags, and so on). However, artificial intelligence can’t accurately determine whether the tags are actually useful to humans.
For example, if a website has an <h2> subheading that reads, “More Information,” Lighthouse won’t trigger an alert. Human users will have questions, however; “more information" about what?
The subheading tag should provide relevant details in a concise manner. To determine whether your page has useful semantic structure, you’ll need guidance from actual humans.
Related: How Headings Help People with Disabilities Navigate a Website
2. Poor Image Alt Tags
Google Lighthouse can find missing image alternative text (also called alt tags), which is an extremely common accessibility issue. In a 2022 analysis, WebAIM (Web Accessibility in Mind) found that 23.2% of all home page images had missing alternative text.
But while automated tools can find missing alt text and repetitive alternative text, they’re less handy for determining whether image alt text is accurate. If the user has vision-related disabilities, the alt text provides important context about the purpose of the image on the page — but if the alt text isn’t descriptive, it’s not helpful.
Related: 8 Common Image Alt Text Mistakes to Stop Making
3. Color That Conveys Meaning
Automated accessibility tools can detect most color contrast issues, which can help designers make decisions that improve the experiences of users with low vision, color vision deficiency, and other vision-related disabilities.
However, when color alone is used to convey information, automated tools can’t detect the problem. For example, if a form field turns red to indicate that the user needs to add additional information, Lighthouse (and other tools) won’t see this as a problem — but users who can’t perceive color may have trouble understanding why they’re unable to complete the form.
Related: Use of Color for Accessibility Explained
4. Poor ARIA Markup
WAI-ARIA (Web Accessibility Initiative - Accessible Rich Internet Applications) is a specification used to add semantic definitions to certain elements, which improves website functionality for some assistive technology users.
ARIA is a powerful tool, and when used correctly, it can improve accessibility for complex content. However, it can also create new accessibility issues. Before implementing ARIA, you’ll need to thoroughly test your markup.
Google Lighthouse can find some issues with ARIA markup, but it can miss some major barriers, including misuse of certain landmark roles.
Related: 5 Common Misconceptions About WAI-ARIA and Accessibility
5. Missing “Skip to Content" Links
“Skip" links (also called “skip navigation" or “skip to content" links) appear towards the top of a web page. When activated, they send the user directly to the beginning of the main content. This allows users to skip repetitive navigation links, which is especially beneficial for people who use screen readers and people who use a keyboard alone for navigation.
Many automated accessibility tools have trouble identifying skip links. Unfortunately, Google Lighthouse can’t determine whether a skip link is necessary — and whether a missing skip link will impact the user experience.
Related: How “Skip Navigation" Links Benefit Accessibility
6. Some Keyboard Accessibility Issues
Google Lighthouse may not identify keyboard traps, which prevent keyboard users from navigating past pop-ups and other elements. Keyboard traps can make a site completely unusable, and they’re one of the most frustrating accessibility issues.
Typically, traps occur within third-party widgets or when ARIA is misused. Google Lighthouse generally won’t attempt to navigate your website in the same way as a keyboard user (utilizing Tab and Shift-Tab to change focus).
Some automated tools can provide more accurate feedback about how keyboard focus changes. However, the best way to find keyboard accessibility issues is to manually test your content.
Related: Avoid "Keyboard Traps" To Make Your Site More Accessible
When testing content for accessibility, don’t rely on automated tools alone
Automated tests like Google Lighthouse should play a role in your long-term approach to accessibility, but many WCAG issues require human judgment and analysis.
At the Bureau of Internet Accessibility, we strongly recommend using a combination of manual and automated tests. Involving manual testers — especially testers who live with disabilities — will help you eliminate barriers and enjoy more of the benefits of accessible design.
Read about our four-point hybrid testing methodology or visit our Compliance Roadmap for more resources.
