Reviews pasted HTML or JSX for the accessibility defects a screen reader or keyboard user hits first, and names the WCAG 2.2 success criterion for each. It flags images without a text alternative, form fields without a label, buttons and links with no accessible name, clickable elements that a keyboard cannot reach, focusable content hidden from assistive technology, personal-data fields without autocomplete, data tables without header cells and pages without a language, and it marks heading levels that skip and positive tabindex values as best-practice findings, not WCAG failures. Each finding has a fixed code, the element, the criterion and a fix, then one verdict. Use to review HTML for accessibility, audit a component or page markup for WCAG issues, or check a form or template before release.
Accessibility Review: WCAG Defects in Markup is a tested SKILL.md that reviews pasted HTML or JSX for the accessibility defects a screen reader or keyboard user hits first, and names the WCAG 2.2 success criterion for each; an agent buys it once for $0.03 over x402.
A full accessibility audit or a legal compliance report. It reads pasted markup as text, so it cannot judge colour contrast, focus styles, zoom, screen reader behaviour or script it was not given, and it reports only the ten listed defects.
Tested 2026-10-08 with a strong and a weak model.
| Sonnet | Haiku | |||
|---|---|---|---|---|
| with | without | with | without | |
| Planted defects named (14 snippets) | 14/14 | 14/14 | 14/14 | 14/14 |
One run per model and snippet, the same word-based check on both sides. Both models found every planted defect without the skill too, so the skill adds no detection here. What it changes is the answer: one coded line per defect and a verdict, about 90 output tokens on average from Sonnet against about 1,000 without it. Without the skill both models also told the user, under should-fix, to empty the alt on an image that has a sensible one, and to replace a div that already works as a keyboard button; with the skill neither of those correct snippets got a finding.
Same cases and the same checks with and without the skill. The cases are ours, written around what the skill is for; with a handful of cases, a difference of one or two is within noise.
Our own test text, before and after the skill ran. Excerpts only.
Before
<article> <h2>Our new office</h2> <img src="/img/office-front.jpg"> <p>We moved to the old printing house on Market Street.</p> </article>
After
[IMG-ALT] img src="/img/office-front.jpg": no alt attribute, so a screen reader may announce the file name or skip the image (1.1.1 Non-text Content). Fix: add a short description such as alt="Front of the old printing house on Market Street", or alt="" if the image is purely decorative. Verdict: blocks some users
Any language. Tried in: English.
Perpetual, non-exclusive; use and modify for yourself incl. paid work; no resale or republishing. Holder: Georgi Kalchev, aiskills402.com. Full terms.
Current version 1.0.0, updated 2026-10-08. Whoever bought an earlier version gets new ones free through the same re-download token.
v1.0.0 · 2026-10-08
First release: reviews pasted HTML or JSX for accessibility and lists each defect with a fixed code, the element, the WCAG 2.2 criterion and a fix, then a verdict (blocks some users, fix before release, no known issues). Blocking: images without a text alternative or with a file name as alt, fields with only a placeholder, buttons and links without an accessible name, clickable divs a keyboard cannot reach, focusable content inside aria-hidden. Before release: fields asking for the user's own details without autocomplete, data tables without header cells, a page without a language, skipped heading levels and positive tabindex, the last two marked as best practice.
Ten you can see in markup: images with no text alternative or a file name as alt, fields with only a placeholder, buttons and links with no accessible name, clickable divs a keyboard cannot reach, focusable content inside aria-hidden, personal-data fields with no autocomplete, data tables with no header cells, a page with no language, skipped heading levels and positive tabindex. Each finding names the WCAG 2.2 criterion, or says best practice where no criterion fails.
For finding defects, probably not: in our test Sonnet and Haiku found every planted defect without the skill too. What the skill gives you is the shape of the answer: one coded line per defect and a verdict a script can act on, about 90 output tokens from Sonnet instead of about 1,000, and no should-fix advice on markup that is correct.
No, and a checker does not replace it either. On our test markup an automated engine confirmed nine of thirteen planted defects; the four it missed (a file name as alt, a clickable div, a table without header cells, missing autocomplete) are ones engines usually miss. Run both, and test with a keyboard and a screen reader before release.
No. The skill treats the markup as data. In our test a comment telling the reviewer to report no findings sat above an icon button with no name, and both models still reported the button.
Claude Sonnet and Haiku found all 14 accessibility defects we planted in HTML, checklist or not. Without one, each fix sat inside a page of advice.
8 Oct 2026 · 4 min read
Code & Engineering
Reviews a code change (a diff or a changed file pasted as text) and reports real problems ranked by severity — correctness bugs, security holes, data loss, missing error handling, edge cases, resource leaks — each with location, reason and a concrete fix in words. Use when asked to review code, a diff or a pull request, check a change for bugs, or find security problems in a snippet.
SEO & Content
Writes the SEO title, meta description and (on request) the H1 heading for one web page, in the page's own language, inside hard character limits, matching what the searcher wants. Use when asked to write or rewrite a page title, meta description, SEO snippet or H1 for a page, product, service, article or landing page.
Code & Engineering
Reviews pasted Cloudflare Workers code and configuration (a Worker, a Next.js app on OpenNext, D1 queries, wrangler config) for platform pitfalls that pass every local test and then fail in production or quietly cost money. It flags the edge runtime under OpenNext, D1 queries that bind more than 100 parameters as data grows, LIKE patterns over D1's 50-byte limit, reading rowsAffected where D1 returns meta.changes, interactive transactions D1 does not have, secrets kept in plain vars, outbound fetch code that treats only a thrown error as failure, client hop-by-hop headers forwarded to fetch, and unbounded queries on the request path. Each finding has a fixed code, the place, the reason and a fix, then one verdict. Use to review a Cloudflare Worker before deploy, check D1 or wrangler code, or audit a Next.js app running on Cloudflare.