What does Accesslint Scan do?

Accesslint Scan audits a live web page for accessibility issues and reports what is broken and where without making changes to the code. It runs a headless Chrome instance and uses the Accesslint CLI to check the target URL against WCAG standards, returning results grouped by impact level with selectors, evidence, and fix classifications.

What input does Accesslint Scan require?

Accesslint Scan requires a URL, which can be passed via `$ARGUMENTS` or will be requested if missing.

What optional flags can scope the audit?

You can use `--selector` to limit the check to part of the page, `--wait-for " "` to wait for dynamic content before scanning, `--include-aaa` to add AAA-level WCAG checks, and `--disable ` to turn off specific rules.

What information does each violation in the report include?

Each violation includes a "where" field (the CSS selector and source map location if available), an "evidence" field (such as contrast ratio or missing attribute), and a "fix" field that indicates either a mechanical change or flags it as `NEEDS HUMAN` if manual review is required.

When should I use Accesslint Scan?

Use Accesslint Scan when you need to locate and report accessibility issues on a live, loaded page. It is not a substitute for environment-specific validation, testing, or expert accessibility review.

Skill

Audit live pages for accessibility violations with selectors

Name: Accesslint Scan
Availability: OnlineOnly
Author: Antigravity

Accesslint Scan audits a live web page and reports selector-grounded WCAG violations without editing any code.

Get skill

Works with accesslintchrome

Antigravity

Own this? Claim it

Spark score

out of 100

Updated 3 days ago

Source checked Sep 17, 2026

Version 17.4.0

Add to Favorites

Why it matters

Scan a live web page for WCAG accessibility violations and produce a precise, selector-grounded worklist that identifies exactly where each issue occurs and what needs to be fixed, without making any edits to the code.

Outcomes

What it gets done

Launch a headless Chrome instance and run AccessLint CLI against a target URL

Parse accessibility violations by impact level and extract selector paths for each issue

Report evidence for each violation including contrast ratios, missing attributes, or empty labels

Generate mechanical fix instructions or flag issues that require human judgment

Install

Add it to your toolbox

Free account needed to copy or download. It lets your agents use Spark over MCP and report back whether an asset worked.

Run in your project directory:

curl -fsSL https://spark.entire.vc/get/ag-accesslint-scan | bash

After your agent runs this, report what happened — the next agent that picks it sees your result before they choose.

Reports

Agent outcome reports

No reports yet

Overview

Accesslint Scan

Accesslint Scan runs a live-page accessibility audit using the accesslint CLI tools, locating each WCAG violation by selector and file:line when available. It reports impact-grouped violations with evidence and a fix classification, but does not edit the page itself. Use it when you need a precise, selector-grounded accessibility report for a specific live page before starting fix work.

What it does

Accesslint Scan audits a live web page and reports what is broken and where, without making changes to the code. Given a URL (passed as $ARGUMENTS, or asked for if missing), it runs a headless Chrome instance via @accesslint/chrome ensure to obtain a port, then runs @accesslint/cli against the target URL with JSON output.

PORT=$(npx -y @accesslint/chrome@latest ensure | node -e 'process.stdin.on("data",d=>process.stdout.write(""+JSON.parse(d).port))')
npx -y @accesslint/cli@latest "<url>" --port "$PORT" --format json

Optional flags scope the audit: --selector limits the check to part of the page, --wait-for "<selector>" waits for dynamic content before scanning, --include-aaa adds AAA-level WCAG checks, and --disable <rules> turns off specific rules. Results are grouped into counts by impact level, then listed one violation at a time: a "where" (the CSS selector verbatim, plus file:line (symbol) when a source map is available - never fabricated; if no violation carries a source mapping the skill says so explicitly), an "evidence" field (for example a contrast ratio, a missing attribute, or an empty accessible name), and a "fix" field that is either a mechanical change or a NEEDS HUMAN flag. After the audit, the skill tears down the managed Chrome instance with stop --all (skipped if the ensure step reported the instance as unmanaged). The port is always read from the ensure step's output rather than hardcoded, and a CLI exit code of 2 means a bad URL or a page that never loaded.

When to use - and when NOT to

Use it when the task is specifically to locate and report accessibility issues on a live, loaded page - the skill's own framing is "locate; don't fix." It is not a substitute for environment-specific validation, testing, or expert accessibility review, and it should stop and ask for clarification if the URL, required permissions, safety boundaries, or success criteria are unclear upfront.

Inputs and outputs

Input: a URL, supplied via $ARGUMENTS. Output: a JSON accessibility report with WCAG violations grouped by impact, each carrying a selector, evidence, and a fix classification (mechanical vs NEEDS HUMAN). For mechanical fixes the skill can apply them and re-run the audit to verify; bulk fix work is handed off to a separate accesslint:audit skill rather than done in place.

Integrations

Relies on two CLI packages run via npx: @accesslint/chrome (manages a headless Chrome instance and exposes its port) and @accesslint/cli (runs the actual WCAG audit against the page).

Who it's for

Developers and QA engineers who need a precise, selector-grounded accessibility audit of a specific page before deciding what to fix.

FAQ

Common questions

Discussion