Lighthouse Accessibility Audit Guide

Web accessibility determines whether people with disabilities can use your site. This includes users who are blind, deaf, have motor impairments, cognitive disabilities, or temporary limitations like a broken arm.

Lighthouse tests accessibility using axe-core. Each scored accessibility audit is pass or fail. Automated checks cover only part of accessibility testing.

The Lighthouse accessibility score is a weighted average of applicable scored audits. A score of 85 does not mean that 85% of audits passed.

Why accessibility matters

Real users depend on it

Over 1 billion people worldwide live with disabilities. In the US, 26% of adults have some type of disability. This is a significant portion of your potential audience.

How users interact with your site:

• Screen reader users navigate by headings, links, and landmarks. If your heading hierarchy skips from h1 to h4, they lose context. If links say "click here" without context, they have no idea where they lead.
• Keyboard-only users tab through interactive elements. If a button cannot receive focus or a modal traps them, your site becomes unusable.
• Low-vision users rely on sufficient color contrast. Light gray text on white backgrounds is invisible to them.
• Motor-impaired users may use voice control or switches. Tiny touch targets and timed interactions create barriers.

Accessibility failures do not just inconvenience people. They lock them out.

Legal requirements

Web accessibility is increasingly mandated by law:

The number of website accessibility lawsuits remains high, with thousands filed annually in federal court. Plaintiffs typically target violations detectable by automated tools; these are the same issues Lighthouse flags.

Accessibility and search

Accessible content helps people understand and use a page. Some practices also help Google understand content and discover links. This does not establish the Lighthouse accessibility score as a ranking signal.

Google's link guidance recommends descriptive anchor text and links with an href. Link text gives people and Google context about the destination. A link's accessible name and its crawlable URL are separate checks.

Google also uses alt text with surrounding content to understand images. Write useful descriptions for informative images.

Google's page experience guidance says Core Web Vitals contribute to ranking. Other page experience aspects do not directly raise rankings. Improve accessibility for people, and verify crawling and indexing separately.

How Lighthouse scores accessibility

Lighthouse assigns weights based on axe user impact assessments. Each applicable scored audit contributes its full weight when it passes and zero when it fails:

Score = (Sum of passed audit weights / Sum of applicable scored audit weights) * 100

What you need to know:

• Binary results: Each audit is pass/fail. There is no "partial credit."
• Weighted scoring: A failed audit with a higher weight has a larger effect on the score.
• Not applicable: Audits that do not apply to the page do not affect the score.
• Excluded checks: Manual checks and low-impact or best-practices checks outside the scoring table do not affect the score.

A score of 100 means the applicable scored audits passed. It does not prove WCAG conformance or mean every automated check passed. W3C's evaluation guidance requires human evaluation alongside tools. Test keyboard navigation, screen readers, and tasks with disabled users.

Common accessibility issues

These are the most frequently failing audits across websites:

Names and labels

ARIA issues

Color and contrast

Document structure

Navigation

Tables

Diagnose your specific issue

How to test accessibility

Lighthouse (automated)

Run Lighthouse in Chrome DevTools:

1. Open DevTools (F12)
2. Go to Lighthouse tab
3. Check Accessibility category
4. Click Analyze page load

Review the failing audits. Each includes the failing elements and a link to documentation.

Chrome DevTools accessibility panel

For deeper inspection:

1. Open DevTools → Elements tab
2. Select an element
3. View Accessibility pane in sidebar
4. Check computed accessible name, role, and properties

The accessibility tree shows how assistive technologies interpret your page. If an element is missing from this tree, screen readers cannot find it.

axe DevTools extension

Install axe DevTools for more detailed testing than Lighthouse alone. It provides:

• Intelligent guided tests for complex issues
• Best practice violations beyond WCAG
• Issue grouping by component

Screen reader testing

Automated tools catch syntax issues. Screen reader testing reveals usability issues.

Basic screen reader test:

1. Close your eyes or turn off the monitor
2. Navigate using only keyboard
3. Can you understand the page structure?
4. Can you complete key tasks?

Keyboard testing

Tab through your page:

• Can you reach all interactive elements?
• Is focus visible at all times?
• Can you operate all controls (buttons, menus, forms)?
• Can you escape from modals?
• Is tab order logical?

If any answer is no, users with motor impairments cannot use that feature.

Framework considerations

Modern JavaScript frameworks require extra attention for accessibility:

Client-side routing: When navigation happens without page reload, screen readers may not announce the new content. Manage focus on route change.

Dynamic content: Content added via JavaScript needs appropriate ARIA live regions to announce changes.

Component libraries: Third-party UI libraries vary in accessibility quality. Audit them before adoption.

Virtual DOM: Framework abstractions can obscure accessibility issues. The rendered HTML is what matters.

Test your entire site

Checking accessibility page-by-page misses patterns. Your marketing pages might pass while app screens fail. Product pages might be accessible while the checkout flow is not.

Different templates have different issues. An author creating content might leave out alt text. A developer building components might forget ARIA labels.

Unlighthouse scans your entire site and surfaces accessibility scores for every page. You will see which templates have issues, which pages are outliers, and whether fixes work at scale.

The CLI is free and runs locally. Cloud adds scheduled monitoring to catch regressions before users report them.