accesslint-scan

Identify accessibility violations in live web pages via Chrome DevTools Protocol.

Updated Jun 24, 2026
One-click install
npx skills add https://github.com/udsy19/.claude --skill accesslint-scan-udsy19
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: accesslint-scan
Source: https://github.com/udsy19/.claude/tree/main/skills/accesslint-scan
Command: npx skills add https://github.com/udsy19/.claude --skill accesslint-scan-udsy19

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes scripts (resource) components.

What problem does it solve?

This Skill quickly identifies accessibility issues in live web pages, ensuring that your site meets WCAG standards without the need for manual testing.

Core Features & Use Cases

  • Live Page Audit: Scan live web pages for accessibility violations.
  • Detailed Reporting: Provide precise location of each violation, including DOM selector and source file:line.
  • Configurable: Use URL, config target name, or default target from accesslint.config.json.
  • Use Case: For a UI change, use this Skill to verify accessibility compliance.

Quick Start

Run the accesslint-scan skill with the URL of the page you want to audit.

Frequently Asked Questions about accesslint-scan

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I audit live web pages for WCAG accessibility issues?

You can audit live web pages for WCAG accessibility issues by providing a URL or configuring a target in accesslint.config.json. The tool uses Chrome DevTools Protocol to output detailed violation locations.

How does an automated accessibility audit locate violations in the source code?

An automated accessibility audit locates violations by inspecting the live DOM through Chrome DevTools Protocol. It outputs a detailed list mapping each violation to its exact DOM selector and source file:line.

Can I use a configuration file instead of a URL to scan for accessibility violations?

Yes, you can use a configuration file instead of a URL to scan for accessibility violations. The tool accepts a config target name or defaults to a target defined in your accesslint.config.json file.

What is the best way to verify UI accessibility compliance after a design change?

The best way to verify UI accessibility compliance after a design change is to run an automated scan against the live page. This instantly identifies WCAG violations without requiring manual testing.

Does the AccessLint scan require manual testing to identify accessibility issues?

No, the AccessLint scan does not require manual testing to identify accessibility issues. It operates using the AccessLint core engine to automatically detect and report WCAG violations on live web pages.

What limitations exist when auditing live pages for accessibility violations?

A limitation when auditing live pages for accessibility violations is that the scan requires a URL or config target name. It operates via Chrome DevTools Protocol, meaning it analyzes the current live state rather than static code files.