Google Lighthouse is an open-source tool that provides insights about the quality of web pages. It’s commonly used for analyzing site performance, search engine optimization (SEO) metrics, and accessibility — but as a web accessibility tool, Lighthouse is quite limited.
Lighthouse, like all automated accessibility tests, is prone to false negatives (missing accessibility barriers that affect real users) and false positives (finding accessibility barriers that don’t actually exist).
Here’s an overview of how Lighthouse scores accessibility, along with tips for accurately auditing web content for accessibility compliance.
Lighthouse Accessibility Scores: A Quick Primer
Automated accessibility tools try to identify barriers that are likely to affect users with disabilities by checking your code against common standards. Many tools use the Web Content Accessibility Guidelines (WCAG), the consensus international standards for digital accessibility.
Lighthouse doesn’t directly reference WCAG, but Google provides a page explaining how Lighthouse accessibility scoring works. Each accessibility issue is analyzed with a pass-or-fail test with an assigned weight, and the final score is a weighted average of all tests.
For example, including aria-hidden=”true" on the <body> element has a weight of 10. This is a bad practice, since aria-hidden”true” removes content from the accessibility tree, which may prevent people who use screen readers and other assistive technology (AT) from perceiving that content.
Obviously, that’s bad for the user, since <body> content is important by definition. Websites that make this mistake will suffer a major hit to their Lighthouse Accessibility score.
Automated accessibility tests aren’t intended to find every barrier
But while Lighthouse is useful for finding certain issues, the tool’s documentation has an important disclaimer:
“Only a subset of accessibility issues can be automatically detected so manual testing is also encouraged.”
In other articles, we’ve written in detail about the accessibility issues that Lighthouse might miss, including:
- Other misuses of the aria-hidden=”true" attribute that hide important content from AT users.
- Keyboard traps, which prevent keyboard users from navigating past content or changing their keyboard focus.
- CSS mistakes that prevent users from seeing keyboard focus and pointer focus indicators.
- Any WCAG criterion that requires human judgment, such as inaccurate image alt tags, subheadings, and page titles.
Developer and web accessibility advocate Manuel Matuzovic has an article detailing his attempts to build the most inaccessible site possible with a perfect Lighthouse score, which is well worth a read. Matuzovic created a site that is almost completely unusable, even with a mouse and keyboard — and while Lighthouse has improved since Matuzovic published his piece, it’s still far from perfect.
And while false negatives are a big problem, false positives can be just as disruptive for your accessibility initiative. For example, Lighthouse might generate a warning anytime the aria-hidden=”true" attribute appears, but you might have a legitimate reason to use that attribute.
To create truly accessible content, you need to understand why each remediation is important. Otherwise, you might spend dozens of hours fixing “problems" that don’t meaningfully affect users with disabilities — without addressing actual accessibility barriers.
Related: Why Is a Web Accessibility Audit Important?
Automated testing plays an important role in web accessibility conformance
While Lighthouse isn’t perfect, it’s important to remember that no automated accessibility test can find every WCAG issue. That’s not the purpose of automated testing: Automation simply allows developers to test content at scale for machine-identifiable issues, which can greatly reduce the time spent on remediation.
In other words, we’re not picking on Lighthouse. It’s a useful tool, and since Lighthouse reports are commonly used for evaluating various user experience metrics, it makes sense to include Lighthouse’s accessibility scores in a full-site audit.
However, remember that Lighthouse Accessibility scores aren’t practically useful for determining whether your content follows WCAG 2.1 Level AA (or any other version of WCAG). Full accessibility audits should use a hybrid methodology that combines automated testing with manual testing and review.
For a truly accessible website, use WCAG when testing
You can build a better approach to web accessibility testing by using an automated audit that directly references WCAG standards. Our free WCAG 2.1 Level AA Compliance Summary is a great starting point.
To create a plan for long-term compliance that includes manual testing and remediation, send us a message to connect with a subject matter expert.
