Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx skills add southleft/skills-for-figma --skill scan-code-accessibility-figmagit clone --depth 1 https://github.com/southleft/skills-for-figmaWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/skills/southleft/skills-for-figma/scan-code-accessibility-figma)<a href="https://agentmods.dev/skills/southleft/skills-for-figma/scan-code-accessibility-figma"><img src="https://agentmods.dev/badge/skills/southleft/skills-for-figma/scan-code-accessibility-figma/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/skills/southleft/skills-for-figma/scan-code-accessibility-figma"><img src="https://agentmods.dev/badge/skills/southleft/skills-for-figma/scan-code-accessibility-figma.svg" alt="Reviewed on agentmods" width="80" height="20"></a>What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5.1 | $0.00200 | $0.01158 |
| Opus 5 | $0.00100 | $0.00579 |
| Sonnet 5 | $0.00040 | $0.00232 |
| Haiku 4.5 | $0.00020 | $0.00116 |
Grade A, and why
scan-code-accessibility-figma scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 9d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
This is a copy
86% identical to figma-scan-code-accessibility — 20 lines differ, which has more behind it and is treated as the original. This page carries a canonical link to it rather than competing with it.
How it starts
The opening of the file, as written. The whole thing — 71 lines — stays where its author put it; the contents beside it link to each section on GitHub.
scan-code-accessibility-figma — axe-core + JSDOM scan of HTML
Run axe-core (Deque's accessibility engine) against an HTML
string using JSDOM. This is the code side of the accessibility story: it checks the markup your
Figma-to-code workflow produced. It pairs with lint-design-figma (design side) to cover both ends.
Not a use_figma skill. This runs in plain Node — no Figma file, no Plugin API. axe-core owns the
rule database; this skill never invents rules.
Skill boundaries
- Design-side visual a11y (contrast, focus rings, target size, color-only) → use
lint-design-figma. Those rules are intentionally disabled here. - Per-component design scorecard → use
audit-accessibility-figma. - Design-vs-code parity → use
check-design-parity-figma(feed it thecodeSpec.accessibilitythis scan can emit). - This skill does not use
use_figma, so thefigma-useconventions do not apply.
Why visual rules are disabled
JSDOM provides a DOM but no layout engine and no computed visual styles — there is nothing to measure pixels or rendered colors against. So axe's visual rules would always be "incomplete" or wrong. The scan disables them explicitly:
color-contrastandcolor-contrast-enhanced— need rendered colors.link-in-text-block— needs surrounding text layout.target-size— needs rendered box dimensions.
Everything structural/semantic (ARIA, roles, names, labels, alt, headings, landmarks, lang, dup IDs,
tabindex, ~50 rules total) runs normally. For the visual half, run lint-design-figma on the design.
Usage
- Install deps once (in this skill's
scripts/dir):
Installscd scripts && npm installaxe-coreandjsdom. - Run the scan against an HTML file or an inline string:
Optional flags:node scan.mjs path/to/component.html node scan.mjs --html '<button>Save</button>'--tags wcag22aa— filter to a WCAG tag set (wcag2a,wcag2aa,wcag21aa,wcag22aa,best-practice). Repeatable / comma-separated.--context '#my-component'— scope the scan to a CSS selector.--include-passing— include counts of passing / incomplete / inapplicable rules.--map-to-codespec— also emit acodeSpecAccessibilityobject (semantic element, role, aria-label, focusVisible, keyboard interactions, disabled/error support) ready to drop intocheck-design-parity-figma'scodeSpec.accessibility.
- Read the JSON on stdout: violations grouped by rule with
severity(critical/warning/info from axeimpact),wcagTags,helpUrl, and up to 10 offending nodes each, plus asummary.
What ships with it
2 files beside SKILL.md in the same directory: the scripts, references and assets a skill reads on demand. Not counted in the per-session cost; read them before you install if any of them is executable.
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 9d ago First seen · 71 lines · 200 tokens per session scan A fc6f9534cce5
scan-code-accessibility-figma is a skill published in the GitHub repository southleft/skills-for-figma (14 stars, last pushed 3mo ago), licensed MIT. It adds 200 tokens to every session and 1,158 once invoked, about $0.0010 per session on Opus 5. A static security scan graded it A with 0 findings. It is 86% identical to figma-scan-code-accessibility, differing in 20 lines, and is treated as a copy.
Other skills, from other repositories
accessibility-per-component
Run an accessibility audit on a specific design system component. Trigger when someone says: accessibility check, a11y audit, WCAG compliance, is this accessible, check accessibility, does this meet WCAG, screen reader support, keyboard navigation check, or anything about auditing the accessibility of a specific…
cicd-integration
Generate CI/CD pipeline configurations that automate design system quality checks — token validation, component linting, visual regression, accessibility scanning, and release gating. Produces ready-to-use pipeline files for GitHub Actions, GitLab CI, CircleCI, or Bitbucket Pipelines, configured to enforce the…
codemod-generator
Generate codemods (automated code transformation scripts) for design system migrations — token renames, component API changes, prop deprecations, and import path updates. Produces ready-to-run jscodeshift or custom AST transform scripts that safely apply changes across consuming codebases. Trigger when someone says…
component-api-validator
Audit component APIs for consistency, breaking changes, TypeScript coverage, and contract compliance across a component library. Trigger when someone says: component prop review, verify component types are exported, component API audit, check our component interfaces, are our props consistent, API consistency check…
schema-validator
Validate token files against DTCG 2025.10, Style Dictionary, or custom schemas. Trigger when someone says: validate token JSON, check my token files for errors, schema validation for tokens, are my token files valid, DTCG compliance check, validate token format, or anything about checking whether token files are…
design-to-code-check
Check alignment between a specific design specification and its code implementation — a focused, single-component or single-screen comparison. Trigger when someone says: does this match the design, check implementation, design code alignment, what's different between the design and the build, spec check…