---
title: "Lighthouse Accessibility Audit Guide"
description: "Master web accessibility with Lighthouse. Learn how accessibility audits work, why they matter for users and SEO, and how to fix common issues."
canonical_url: "https://unlighthouse.dev/learn-lighthouse/accessibility"
last_updated: "2025-01-18"
---

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](https://github.com/dequelabs/axe-core), the industry-standard accessibility testing engine. Each audit is binary: pass or fail. Unlike performance metrics with thresholds, accessibility either works for users or it does not.

The overall accessibility score represents the percentage of passed audits. A score of 85 means 85% of applicable audits passed.

## Why accessibility matters

### Real users depend on it

Over [1 billion people worldwide live with disabilities](https://www.who.int/news-room/fact-sheets/detail/disability-and-health). In the US, [26% of adults have some type of disability](https://www.cdc.gov/disability-and-health/articles-documents/disability-impacts-all-of-us-infographic.html). 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:

<table>
<thead>
  <tr>
    <th>
      Region
    </th>
    
    <th>
      Law
    </th>
    
    <th>
      Requirement
    </th>
  </tr>
</thead>

<tbody>
  <tr>
    <td>
      United States
    </td>
    
    <td>
      ADA, Section 508
    </td>
    
    <td>
      Public accommodations must be accessible
    </td>
  </tr>
  
  <tr>
    <td>
      European Union
    </td>
    
    <td>
      European Accessibility Act
    </td>
    
    <td>
      Digital services must meet WCAG 2.1 AA by 2025
    </td>
  </tr>
  
  <tr>
    <td>
      United Kingdom
    </td>
    
    <td>
      Equality Act 2010
    </td>
    
    <td>
      Service providers must make reasonable adjustments
    </td>
  </tr>
  
  <tr>
    <td>
      Canada
    </td>
    
    <td>
      AODA
    </td>
    
    <td>
      Ontarian organizations must meet WCAG 2.0 AA
    </td>
  </tr>
  
  <tr>
    <td>
      Australia
    </td>
    
    <td>
      DDA
    </td>
    
    <td>
      Discrimination includes inaccessible websites
    </td>
  </tr>
</tbody>
</table>

[The number of website accessibility lawsuits remains high, with thousands filed annually in federal court](https://www.w3.org/WAI/business-case/). Plaintiffs typically target violations detectable by automated tools; these are the same issues Lighthouse flags.

### SEO overlap: The "proxy signal" effect

Google has stated that accessibility scores are an *indirect* ranking factor. Accessibility features act as "proxy signals" for User Experience (UX) and content quality, which *are* ranking factors.

<table>
<thead>
  <tr>
    <th>
      Accessibility Feature
    </th>
    
    <th>
      SEO Signal Proxy
    </th>
    
    <th>
      Business Impact
    </th>
  </tr>
</thead>

<tbody>
  <tr>
    <td>
      <strong>
        Headings (H1-H6)
      </strong>
    </td>
    
    <td>
      <strong>
        Passage Ranking
      </strong>
    </td>
    
    <td>
      Helps Google index specific answers within long content for Featured Snippets.
    </td>
  </tr>
  
  <tr>
    <td>
      <strong>
        Link Names
      </strong>
    </td>
    
    <td>
      <strong>
        Internal Link Equity
      </strong>
    </td>
    
    <td>
      Descriptive anchors pass topical authority to linked pages, boosting their ranking potential.
    </td>
  </tr>
  
  <tr>
    <td>
      <strong>
        Alt Text
      </strong>
    </td>
    
    <td>
      <strong>
        Visual Search
      </strong>
    </td>
    
    <td>
      Powers Google Images and Google Lens, opening new acquisition channels.
    </td>
  </tr>
  
  <tr>
    <td>
      <strong>
        Captions/Transcripts
      </strong>
    </td>
    
    <td>
      <strong>
        Video Indexing
      </strong>
    </td>
    
    <td>
      Makes video content searchable and indexable, capturing long-tail traffic.
    </td>
  </tr>
</tbody>
</table>

#### Future proofing: mobile-first & AI

As search evolves towards AI-driven answers (SGE) and strict Mobile-First Indexing, semantic structure becomes critical. LLMs and crawlers rely on the Accessibility Tree to understand content hierarchy. If your content is hidden from screen readers (e.g., inaccessible accordions), search engines may devalue or ignore it.

## How Lighthouse scores accessibility

Lighthouse runs axe-core against your page and evaluates dozens of rules. Each applicable rule either passes or fails. The score formula:

```text
Score = (Passed Audits / Total Applicable Audits) * 100
```

What you need to know:

- **Binary results**: Each audit is pass/fail. There is no "partial credit."
- **Weighted scoring**: Some audits carry more weight based on user impact.
- **Not applicable**: If an audit does not apply (no images on page = no image-alt check), it does not affect your score.
- **Automated limitations**: Lighthouse catches 30-50% of accessibility issues. Manual testing is essential.

A perfect 100 does not mean your site is fully accessible. It means you passed all automated checks. Screen reader testing, keyboard navigation testing, and usability testing with disabled users reveal issues automation misses.

## Common accessibility issues

These are the most frequently failing audits across websites:

### Names and labels

<table>
<thead>
  <tr>
    <th>
      Issue
    </th>
    
    <th>
      Impact
    </th>
    
    <th>
      Fix Complexity
    </th>
  </tr>
</thead>

<tbody>
  <tr>
    <td>
      <a href="/learn-lighthouse/accessibility/image-alt">
        Missing image alt text
      </a>
    </td>
    
    <td>
      High
    </td>
    
    <td>
      Low
    </td>
  </tr>
  
  <tr>
    <td>
      <a href="/learn-lighthouse/accessibility/link-name">
        Links without discernible names
      </a>
    </td>
    
    <td>
      High
    </td>
    
    <td>
      Low
    </td>
  </tr>
  
  <tr>
    <td>
      <a href="/learn-lighthouse/accessibility/button-name">
        Buttons without accessible names
      </a>
    </td>
    
    <td>
      High
    </td>
    
    <td>
      Low
    </td>
  </tr>
  
  <tr>
    <td>
      <a href="/learn-lighthouse/accessibility/label">
        Form inputs without labels
      </a>
    </td>
    
    <td>
      High
    </td>
    
    <td>
      Low
    </td>
  </tr>
  
  <tr>
    <td>
      <a href="/learn-lighthouse/accessibility/frame-title">
        Frame/iframe missing title
      </a>
    </td>
    
    <td>
      Medium
    </td>
    
    <td>
      Low
    </td>
  </tr>
</tbody>
</table>

### ARIA issues

<table>
<thead>
  <tr>
    <th>
      Issue
    </th>
    
    <th>
      Impact
    </th>
    
    <th>
      Fix Complexity
    </th>
  </tr>
</thead>

<tbody>
  <tr>
    <td>
      Invalid ARIA roles
    </td>
    
    <td>
      High
    </td>
    
    <td>
      Medium
    </td>
  </tr>
  
  <tr>
    <td>
      <a href="/learn-lighthouse/accessibility/aria-required-attr">
        Missing required ARIA attributes
      </a>
    </td>
    
    <td>
      High
    </td>
    
    <td>
      Medium
    </td>
  </tr>
  
  <tr>
    <td>
      Invalid ARIA attribute values
    </td>
    
    <td>
      High
    </td>
    
    <td>
      Medium
    </td>
  </tr>
  
  <tr>
    <td>
      ARIA hidden on body
    </td>
    
    <td>
      Critical
    </td>
    
    <td>
      Low
    </td>
  </tr>
  
  <tr>
    <td>
      Duplicate ARIA IDs
    </td>
    
    <td>
      High
    </td>
    
    <td>
      Medium
    </td>
  </tr>
</tbody>
</table>

### Color and contrast

<table>
<thead>
  <tr>
    <th>
      Issue
    </th>
    
    <th>
      Impact
    </th>
    
    <th>
      Fix Complexity
    </th>
  </tr>
</thead>

<tbody>
  <tr>
    <td>
      <a href="/learn-lighthouse/accessibility/color-contrast">
        Insufficient color contrast
      </a>
    </td>
    
    <td>
      High
    </td>
    
    <td>
      Medium
    </td>
  </tr>
  
  <tr>
    <td>
      Links not distinguishable from text
    </td>
    
    <td>
      Medium
    </td>
    
    <td>
      Low
    </td>
  </tr>
</tbody>
</table>

### Document structure

<table>
<thead>
  <tr>
    <th>
      Issue
    </th>
    
    <th>
      Impact
    </th>
    
    <th>
      Fix Complexity
    </th>
  </tr>
</thead>

<tbody>
  <tr>
    <td>
      <a href="/learn-lighthouse/accessibility/document-title">
        Missing document title
      </a>
    </td>
    
    <td>
      High
    </td>
    
    <td>
      Low
    </td>
  </tr>
  
  <tr>
    <td>
      <a href="/learn-lighthouse/accessibility/html-has-lang">
        Missing HTML lang attribute
      </a>
    </td>
    
    <td>
      High
    </td>
    
    <td>
      Low
    </td>
  </tr>
  
  <tr>
    <td>
      Invalid lang attribute
    </td>
    
    <td>
      Medium
    </td>
    
    <td>
      Low
    </td>
  </tr>
  
  <tr>
    <td>
      <a href="/learn-lighthouse/accessibility/heading-order">
        Skipped heading levels
      </a>
    </td>
    
    <td>
      Medium
    </td>
    
    <td>
      Low
    </td>
  </tr>
  
  <tr>
    <td>
      Empty headings
    </td>
    
    <td>
      Medium
    </td>
    
    <td>
      Low
    </td>
  </tr>
</tbody>
</table>

### Navigation

<table>
<thead>
  <tr>
    <th>
      Issue
    </th>
    
    <th>
      Impact
    </th>
    
    <th>
      Fix Complexity
    </th>
  </tr>
</thead>

<tbody>
  <tr>
    <td>
      <a href="/learn-lighthouse/accessibility/bypass">
        No skip link or landmark
      </a>
    </td>
    
    <td>
      Medium
    </td>
    
    <td>
      Low
    </td>
  </tr>
  
  <tr>
    <td>
      <a href="/learn-lighthouse/accessibility/tabindex">
        Tabindex greater than 0
      </a>
    </td>
    
    <td>
      Medium
    </td>
    
    <td>
      Low
    </td>
  </tr>
  
  <tr>
    <td>
      Duplicate access keys
    </td>
    
    <td>
      Low
    </td>
    
    <td>
      Low
    </td>
  </tr>
</tbody>
</table>

### Tables

<table>
<thead>
  <tr>
    <th>
      Issue
    </th>
    
    <th>
      Impact
    </th>
    
    <th>
      Fix Complexity
    </th>
  </tr>
</thead>

<tbody>
  <tr>
    <td>
      Table cells missing headers
    </td>
    
    <td>
      High
    </td>
    
    <td>
      Medium
    </td>
  </tr>
  
  <tr>
    <td>
      Invalid th scope
    </td>
    
    <td>
      Medium
    </td>
    
    <td>
      Medium
    </td>
  </tr>
</tbody>
</table>

> [Diagnose your specific issue](/learn-lighthouse/accessibility#common-accessibility-issues)

## 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](https://www.deque.com/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.

<table>
<thead>
  <tr>
    <th>
      Screen Reader
    </th>
    
    <th>
      Platform
    </th>
    
    <th>
      Cost
    </th>
  </tr>
</thead>

<tbody>
  <tr>
    <td>
      NVDA
    </td>
    
    <td>
      Windows
    </td>
    
    <td>
      Free
    </td>
  </tr>
  
  <tr>
    <td>
      JAWS
    </td>
    
    <td>
      Windows
    </td>
    
    <td>
      Licensed
    </td>
  </tr>
  
  <tr>
    <td>
      VoiceOver
    </td>
    
    <td>
      macOS/iOS
    </td>
    
    <td>
      Built-in
    </td>
  </tr>
  
  <tr>
    <td>
      TalkBack
    </td>
    
    <td>
      Android
    </td>
    
    <td>
      Built-in
    </td>
  </tr>
</tbody>
</table>

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.