figma-scan-code-accessibility
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 con
npx skills add southleft/figma-console-mcp-skills --skill figma-scan-code-accessibility --agent claude-code
Same command for any agent — swap --agent for codex, cursor, copilot.
Weekly change comes from our own snapshots, not the repository page — it measures attention, not adoption.
# figma-scan-code-accessibility — axe-core + JSDOM scan of HTML Run [axe-core](https://github.com/dequelabs/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 `figma-lint-design` (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 `figma-lint-design`. Those rules are intentionally disabled here. - **Per-component design scorecard** → use `figma-audit-accessibility`. - **Design-vs-code parity** → use `figma-check-design-parity` (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 wron
- Skill boundaries
- Why visual rules are disabled
- Usage
- Output shape
cd scripts && npm install node scan.mjs path/to/component.html node scan.mjs --html '<button>Save</button>'
What does the figma-scan-code-accessibility skill do?
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 con
How do I install it?
Run `npx skills add southleft/figma-console-mcp-skills --skill figma-scan-code-accessibility --agent claude-code` — it drops the skill into your project so the agent can pick it up. Swap the --agent value for codex, cursor or copilot if you use one of those.
Where does this skill come from?
From southleft/figma-console-mcp-skills, a repository with 67 stars. We read it straight from the repository tree rather than a submitted listing, so what you see here is what is actually published.
Is a popular skill a good skill?
Not necessarily. Stars measure attention, not adoption — a repository can trend for a week and be abandoned. That is why we show the weekly change from our own snapshots next to the total, instead of a single flattering number.