mcpField
L
lighthouse-scanner

lighthouse-scanner

github.com/community-accessTesting & quality429234 installsUpdated today
Repository

About lighthouse-scanner

lighthouse-scanner is a skill for accessibility review workflows that helps identify and interpret Lighthouse CI results. It relates scores, audit violations, and run-to-run changes to local axe-core scans.

Key features

  1. 01Detect Lighthouse CI workflows and configs
  2. 02Parse accessibility scores and audit results
  3. 03Correlate Lighthouse and axe-core findings
  4. 04Identify regressions from score changes
  5. 05Extract reports from GitHub Actions artifacts

Use cases

  1. 01Check whether a repository configures Lighthouse CI
  2. 02Summarize accessibility audits for URLs
  3. 03Compare local scans with CI findings
  4. 04Review drops in accessibility scores

Install

Copy the command and run it in a terminal.

$npx skills add https://github.com/community-access/accessibility-agents --skill lighthouse-scanner

After installing, type/lighthouse-scannerin Claude Code to confirm it loaded.

Details

From the project README

Lighthouse CI Accessibility Integration

What Is Lighthouse CI?

Lighthouse CI is a suite of tools for running Google Lighthouse audits in CI pipelines. The most common GitHub Actions integration uses treosh/lighthouse-ci-action.

Lighthouse provides:

  • Performance, accessibility, best practices, and SEO scoring (0-100)
  • Individual audit results with pass/fail status and detailed findings
  • Score budgets and assertions to fail builds on regressions
  • HTML and JSON report artifacts
  • Score comparison across runs for trend tracking

Accessibility focus: The Lighthouse accessibility category runs a subset of axe-core rules and reports a weighted score from 0-100 along with individual audit violations.

Detecting Lighthouse CI Presence

Workflow File Detection

Search for workflow files referencing Lighthouse CI:

# Search for the treosh Lighthouse CI action
grep -rl "treosh/lighthouse-ci-action" .github/workflows/

# Search for official Lighthouse CI CLI usage
grep -rl "lhci autorun\|lighthouse-ci" .github/workflows/

Patterns to match in YAML:

- uses: treosh/lighthouse-ci-action@v12
Configuration File Detection

Lighthouse CI uses configuration files in the repository root:

# Check for Lighthouse CI config files
ls lighthouserc.js lighthouserc.json .lighthouserc.js .lighthouserc.json .lighthouserc.yml 2>/dev/null
Config FileFormat
lighthouserc.jsJavaScript module
lighthouserc.jsonJSON
.lighthouserc.jsJavaScript module (dotfile)
.lighthouserc.jsonJSON (dotfile)
.lighthouserc.ymlYAML (dotfile)
Configuration Structure

Key fields in Lighthouse CI config:

{
  "ci": {
    "collect": {
      "url": ["https://example.com", "https://example.com/about"],
      "numberOfRuns": 3
    },
    "assert": {
      "assertions": {
        "categories:accessibility": ["error", {"minScore": 0.9}]
      }
    },
    "upload": {
      "target": "temporary-public-storage"
    }
  }
}
SectionPurposeAgent Use
ci.collect.urlURLs to auditScope of CI scanning
ci.collect.numberOfRunsHow many times to run each URLReliability indicator
ci.assert.assertionsScore budgets and thresholdsRegression detection
ci.upload.targetWhere to store reportsReport retrieval

Parsing Lighthouse Accessibility Results

Accessibility Score

Lighthouse computes a weighted accessibility score from 0-100 based on individual audit results.

Score RangeGradeInterpretation
90-100AGood accessibility
70-89B-CSome issues to address
50-69DSignificant issues
0-49FCritical accessibility failures
Individual Audit Results

Each Lighthouse accessibility audit corresponds to an axe-core rule:

Audit IDaxe-core RuleWCAG CriterionWeight
image-altimage-alt1.1.110
color-contrastcolor-contrast1.4.37
labellabel1.3.17
button-namebutton-name4.1.27
link-namelink-name2.4.47
html-has-langhtml-has-lang3.1.17
document-titledocument-title2.4.27
heading-orderheading-order1.3.13
meta-viewportmeta-viewport1.4.410
bypassbypass2.4.17
tabindextabindex2.4.37
aria-allowed-attraria-allowed-attr4.1.210
aria-hidden-bodyaria-hidden-body4.1.210
aria-required-attraria-required-attr4.1.210
aria-rolesaria-roles4.1.27
aria-valid-attr-valuearia-valid-attr-value4.1.27
aria-valid-attraria-valid-attr4.1.210
Severity Mapping

Lighthouse uses weights rather than impact levels. Map to the agent severity model based on weight and audit pass/fail:

Lighthouse WeightAudit StatusAgent Severity
10FailCritical
7FailSerious
3FailModerate
1FailMinor
AnyPassN/A (not reported)

Correlation with Local Scans

Lighthouse-to-axe-core Mapping

Since Lighthouse uses axe-core under the hood, correlation is straightforward:

  1. Match by audit/rule ID: Lighthouse audit IDs correspond directly to axe-core rule IDs
  2. Match by URL: Compare scanned URLs from Lighthouse config with local scan targets
  3. Boost confidence: Findings confirmed by both Lighthouse CI and local axe-core scan receive high confidence
Source Comparison
ScenarioInterpretationAction
Found by Lighthouse AND local scanHigh confidenceReport as high confidence, full severity weight
Found by Lighthouse onlyEnvironment-specificReport as medium confidence, note "CI-only finding"
Found by local scan onlyNot covered by Lighthouse subsetReport as medium confidence, note "local-only finding"
Lighthouse score regressedNew accessibility issues introducedFlag as regression, prioritize in report

Score Regression Detection

Track Lighthouse accessibility scores across runs to detect regressions:

Comparing Scores
{
  "url": "https://example.com",
  "previousScore": 95,
  "currentScore": 87,
  "delta": -8,
  "status": "regressed",
  "newFailures": ["color-contrast", "image-alt"],
  "newPasses": []
}
Regression Thresholds
DeltaSeverityAction
Score drops 10+ pointsCriticalImmediate attention, likely multiple new violations
Score drops 5-9 pointsSeriousNew violations introduced, review before merge
Score drops 1-4 pointsModerateMinor regression, track for follow-up
Score unchanged or improvedN/ANo regression detected

Structured Output Format

When lighthouse-bridge normalizes Lighthouse data, it produces findings in this format:

{
  "source": "lighthouse-ci",
  "ruleId": "color-contrast",
  "wcagCriterion": "1.4.3",
  "wcagLevel": "AA",
  "severity": "serious",
  "confidence": "high",
  "url": "https://example.com/login",
  "element": "button.submit-btn",
  "description": "Element has insufficient color contrast ratio",
  "lighthouseWeight": 7,
  "lighthouseScore": {
    "overall": 87,
    "previousOverall": 95,
    "delta": -8,
    "status": "regressed"
  }
}

GitHub Actions Integration

treosh/lighthouse-ci-action

The most common Lighthouse CI GitHub Action:

- name: Run Lighthouse CI
  uses: treosh/lighthouse-ci-action@v12
  with:
    urls: |
      https://example.com
      https://example.com/about
    uploadArtifacts: true
    configPath: ./lighthouserc.json
Action Inputs
InputRequiredDescription
urlsYes (or in config)Newline-separated URLs to audit
configPathNoPath to Lighthouse CI config file
uploadArtifactsNoUpload HTML reports as workflow artifacts
temporaryPublicStorageNoUpload to temporary public storage for sharing
runsNoNumber of runs per URL (default: 1)
budgetPathNoPath to a Lighthouse budget JSON file
Extracting Results from Artifacts

Lighthouse CI uploads results as workflow artifacts. To retrieve scores:

  1. Download the artifact from the workflow run
  2. Parse the JSON report files
  3. Extract categories.accessibility.score for the overall score
  4. Extract individual audits.{audit-id} results for violations

Comments

Markdown supported