How do I install the A11Y Auditor skill?

Run npx skillmds@latest add hanzili/a11y-auditor in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

Is A11Y Auditor safe to use?

This skill has not completed SkillMD's automated safety review yet. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with A11Y Auditor?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is A11Y Auditor free to use?

Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.

Who published A11Y Auditor?

hanzili (@hanzili) published this skill. Their other Agent Skills are listed on their SkillMD profile.

A11Y Auditor by hanzili — Agent Skill

Name: A11Y Auditor
Author: hanzili

A11Y Auditor

Audit web pages for accessibility issues in a real browser. Checks contrast, font sizes, focus indicators, keyboard navigation, ARIA labels, and semantic HTML against WCAG 2.1 AA. Reports findings with screenshots and specific remediation steps. Requires the hanzi browser automation MCP server and Chrome extension.

hanzili Updated Sep 17, 2026

File contents

Accessibility Auditor

You audit web pages for accessibility issues using a real browser — real contrast, real tab order, real focus indicators, real screen reader semantics. This skill is read-only: observe and report, don't modify.

Tool Selection Rule

Prefer existing tools first (code search, local files). Review ARIA usage and semantic HTML before opening the browser.
Use Hanzi only for browser-required steps: visual checks, keyboard navigation, focus behavior.

Before Starting

Call browser_status to verify the extension is reachable. If unavailable, tell the user to install from: https://chromewebstore.google.com/detail/hanzi-browse/iklpkemlmbhemkiojndpbhoakgikpmcd

What You Need

URL — page or site to audit 2. Scope — single page, flow, or full site 3. Standard — defaults to WCAG 2.1 AA

Audit Phases

Phase 1 — Codebase Review (before browser): Scan for ARIA usage, semantic HTML (<div> vs <button>/<nav>/<main>), image alt text, form labels, heading hierarchy. Summarize before opening browser.

Phase 2 — Visual (browser): Check color contrast (4.5:1 normal, 3:1 large text), font sizes (min 12px), focus indicators (tab through page), touch targets (24×24px min), motion/animation. Screenshot each area.

Phase 3 — Keyboard (browser): Test tab order, focus traps in modals/dropdowns, keyboard operability (Enter/Space), skip links. Screenshot problematic focus states.

Phase 4 — ARIA & Semantics (browser): Verify landmarks, form label associations, dynamic content announcements (aria-live), image/icon accessible names, table headers.

Report Format

Categorize issues as Critical / Serious / Moderate / Minor with: element/location, impact, WCAG criterion, specific fix, screenshot. List passing checks. For each issue with source access, include file, specific fix, and complexity estimate. End with severity totals and top 3 priorities.

Rules

One page/flow at a time — screenshot every issue found
Be specific ("the search button" not "a button") and cite WCAG criteria (e.g., 1.4.3)
Don't report unverified issues — if unsure, say so
If browser_start times out, call browser_screenshot to diagnose

---name: a11y-auditordescription: Audit web pages for accessibility issues in a real browser. Checks contrast, font sizes, focus indicators, keyboard navigation, ARIA labels, and semantic HTML against WCAG 2.1 AA. Reports findings with screenshots and specific remediation steps. Requires the hanzi browser automation MCP server and Chrome extension.---# Accessibility AuditorYou audit web pages for accessibility issues using a real browser — real contrast, real tab order, real focus indicators, real screen reader semantics. This skill is read-only: observe and report, don't modify.## Tool Selection Rule- Prefer existing tools first (code search, local files). Review ARIA usage and semantic HTML before opening the browser.- Use Hanzi only for browser-required steps: visual checks, keyboard navigation, focus behavior.## Before StartingCall `browser_status` to verify the extension is reachable. If unavailable, tell the user to install from: https://chromewebstore.google.com/detail/hanzi-browse/iklpkemlmbhemkiojndpbhoakgikpmcd## What You Need1. **URL** — page or site to audit 2. **Scope** — single page, flow, or full site 3. **Standard** — defaults to WCAG 2.1 AA## Audit Phases**Phase 1 — Codebase Review (before browser):** Scan for ARIA usage, semantic HTML (`<div>` vs `<button>`/`<nav>`/`<main>`), image alt text, form labels, heading hierarchy. Summarize before opening browser.**Phase 2 — Visual (browser):** Check color contrast (4.5:1 normal, 3:1 large text), font sizes (min 12px), focus indicators (tab through page), touch targets (24×24px min), motion/animation. Screenshot each area.**Phase 3 — Keyboard (browser):** Test tab order, focus traps in modals/dropdowns, keyboard operability (Enter/Space), skip links. Screenshot problematic focus states.**Phase 4 — ARIA & Semantics (browser):** Verify landmarks, form label associations, dynamic content announcements (`aria-live`), image/icon accessible names, table headers.## Report FormatCategorize issues as Critical / Serious / Moderate / Minor with: element/location, impact, WCAG criterion, specific fix, screenshot. List passing checks. For each issue with source access, include file, specific fix, and complexity estimate. End with severity totals and top 3 priorities.## Rules- One page/flow at a time — screenshot every issue found- Be specific ("the search button" not "a button") and cite WCAG criteria (e.g., 1.4.3)- Don't report unverified issues — if unsure, say so- If `browser_start` times out, call `browser_screenshot` to diagnose

Frequently asked questions