Accessibility (addyosmani) vs Accessibility (microsoft)
Two different Claude skills are both called Accessibility. Accessibility (addyosmani) and Accessibility (microsoft) install under the same name and do different jobs, which is exactly how the wrong one ends up running.
Accessibility
addyosmani
Runs accessibility checks against WCAG 2.2 and returns developer-facing issues with concrete, code-level recommendations for ARIA, keyboard focus, contrast, and semantic HTML. Unlike similarly named validators or IDE extensions, it’s focused on teaching and step‑by‑step remediation — it explains failures and how to fix them instead of acting as a strict Level‑AA certifier or an auto‑patch tool.
5 scenarios in the bank answer to it
Accessibility
microsoft/vscode
Offers tools inside the code editor to inspect and adjust the editor’s own accessibility behavior — things like toggling screen‑reader mode, examining the accessibility tree of editor UI, and checking keyboard focus and navigation in the IDE and its extensions. Unlike the WCAG/audit tools, it targets the editor’s UI and developer workflow rather than scanning websites for WCAG compliance or producing remediation for site content.
1 scenario in the bank answer to it
What is the difference between Accessibility (addyosmani) and Accessibility (microsoft)?
- Accessibility (addyosmani)
- Runs accessibility checks against WCAG 2.2 and returns developer-facing issues with concrete, code-level recommendations for ARIA, keyboard focus, contrast, and semantic HTML. Unlike similarly named validators or IDE extensions, it’s focused on teaching and step‑by‑step remediation — it explains failures and how to fix them instead of acting as a strict Level‑AA certifier or an auto‑patch tool.
- Accessibility (microsoft)
- Offers tools inside the code editor to inspect and adjust the editor’s own accessibility behavior — things like toggling screen‑reader mode, examining the accessibility tree of editor UI, and checking keyboard focus and navigation in the IDE and its extensions. Unlike the WCAG/audit tools, it targets the editor’s UI and developer workflow rather than scanning websites for WCAG compliance or producing remediation for site content.
Should I use Accessibility (addyosmani) or Accessibility (microsoft)?
The clearest answer is a situation each one is unambiguously right for. Both of these are drawn from the game's question bank.
Reach for Accessibility (addyosmani) when
During testing, a participant who uses assistive technology can't tell which inputs belong to which labels and tabbing skips the 'submit' control entirely.
accessibility-focused work finds and explains interface failures that prevent assistive tools and keyboard users from interacting: missing or incorrect labeling, improper focus order, and other practical defects, then gives concrete remediation steps. While layout tweaks or SEO changes won't fix invisible labels or broken keyboard flow, an accessibility review will identify the code-level fixes needed so those users can complete the form.
Reach for Accessibility (microsoft) when
We shipped a VS Code extension and a blind developer says he cannot reach our sidebar panel with a keyboard at all. Nothing is wrong with our website; the problem is inside the editor.
Three of these audit web pages against WCAG; only one looks at the editor itself. accessibility (microsoft/vscode) inspects the editor's own accessibility tree, screen-reader mode and keyboard focus, which is exactly where an extension's sidebar lives. The affaan-m option is the tempting one because it is the thorough WCAG 2.2 AA auditor — but a WCAG audit of your website says nothing about whether your extension panel is reachable inside VS Code.
What they have in common
Both are filed under Accessibility, the axis along which they collide. That shared ground is what makes an agent pick between them on description alone — and what makes it pick wrong.
Nearby comparisons
Reading the difference is not the same as spotting it at speed. That is the game.
Today's session