agentsclimarketplace

Scan code accessibility figma

Skill southleft/skills-for-figma/skills/scan-code-accessibility-figma

Scan generated/authored HTML for accessibility violations with axe-core (Deque) running over JSDOM — structural and semantic rules: ARIA attributes and roles, accessible names, alt text, form labels, heading order, landmarks, semantic HTML, tabindex, duplicate IDs, lang attribute, and ~50 more. Use on the CODE side of a Figma-to-code workflow: triggers 'scan this HTML for accessibility', 'run axe on my component', 'check the generated code for a11y', 'axe-core scan', 'accessibility lint my markup', 'WCAG check on code', 'is this HTML accessible'. This is a standalone Node script — NO Figma connection required. Visual rules (color-contrast, focus-visible, link-in-text-block, target-size) are DISABLED because JSDOM has no layout — use lint-design-figma for visual a11y on the design side. The two together give full design+code coverage.From its SKILL.md

Install
npx -y skills add southleft/skills-for-figma --skill scan-code-accessibility-figma

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

2 things to look at

  • 12 stars12 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
  • runs commandsInstructs the agent to run 3 commands, including `cd scripts && npm install` and 2 more.

SKILL.md

4.3 KB, 942 tokens by cl100k_base, as published. Nobody here has run it

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 the codeSpec.accessibility this scan can emit).
  • This skill does not use use_figma, so the figma-use conventions 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-contrast and color-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

  1. Install deps once (in this skill's scripts/ dir):
    cd scripts && npm install
    
    Installs axe-core and jsdom.
  2. Run the scan against an HTML file or an inline string:
    node scan.mjs path/to/component.html
    node scan.mjs --html '<button>Save</button>'
    
    Optional flags:
    • --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 a codeSpecAccessibility object (semantic element, role, aria-label, focusVisible, keyboard interactions, disabled/error support) ready to drop into check-design-parity-figma's codeSpec.accessibility.
  3. Read the JSON on stdout: violations grouped by rule with severity (critical/warning/info from axe impact), wcagTags, helpUrl, and up to 10 offending nodes each, plus a summary.

A bare HTML fragment is auto-wrapped in <!DOCTYPE html><html lang="en">…<body>… before scanning.

Output shape

{
  "engine": "axe-core", "version": "4.x", "mode": "jsdom-structural",
  "note": "JSDOM mode: structural/semantic checks only. Visual rules disabled — use lint-design-figma.",
  "categories": [ { "rule": "button-name", "severity": "critical", "count": 1, "description": "...", "wcagTags": ["wcag2a","wcag412"], "helpUrl": "...", "nodes": [ { "html": "...", "target": ["button"], "failureSummary": "..." } ] } ],
  "summary": { "critical": 1, "warning": 0, "info": 0, "total": 1 }
}

Severity mapping: axe critical/seriouscritical, moderatewarning, minorinfo.

What ships with it: 2 files

8.5 KB alongside SKILL.md, 1 of them executable

scripts/

Gives 0 of the 12 instructions most quality gates skills give in 942 tokens

Counted across 1,524 of the 2,830 authors here whose files we hold, read 2026-09-06

  • Read full output and check exit codein 45 of 1524, across 40 files
  • Verify output confirms the claimin 44 of 1524, across 39 files
  • Identify the command that proves the claimin 43 of 1524, across 39 files
  • Execute the full verification commandin 36 of 1524, across 30 files
  • Produce a verification reportin 34 of 1524, across 18 files
  • Review git diff changesin 30 of 1524, across 16 files
  • Fix build failures immediatelyin 29 of 1524, across 9 files
  • Group findings by severityin 28 of 1524
  • State claim only with evidencein 27 of 1524, across 22 files
  • Verify regression tests with red-green cyclein 26 of 1524, across 22 files
  • Run the full test suitein 26 of 1524, across 25 files
  • Run test suite with coveragein 25 of 1524, across 10 files

Said here and by no other author read

  • run axe-core against HTML using JSDOM
  • wrap HTML fragments in standard document structure
  • filter rules by WCAG tag sets
  • scope scans to specific CSS selectors
  • emit codeSpecAccessibility object for parity checks

Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.

Keep looking

Skills are one crate of 325,949. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.