Accessibility (addyosmani) vs Accessibility (affaan-m)
Two different Claude skills are both called Accessibility. Accessibility (addyosmani) and Accessibility (affaan-m) 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
affaan-m/ecc
This tool inspects user interfaces against WCAG 2.2 Level AA and gives concrete checks and fixes for keyboard navigation, color contrast, and screen‑reader behavior. Unlike general accessibility guides, editor extensions, or chat-based assistants, it’s built for hands-on, change‑level audits and implementation guidance targeted specifically at WCAG 2.2 AA criteria rather than broad training or IDE integration.
1 scenario in the bank answer to it
What is the difference between Accessibility (addyosmani) and Accessibility (affaan-m)?
- 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 (affaan-m)
- This tool inspects user interfaces against WCAG 2.2 Level AA and gives concrete checks and fixes for keyboard navigation, color contrast, and screen‑reader behavior. Unlike general accessibility guides, editor extensions, or chat-based assistants, it’s built for hands-on, change‑level audits and implementation guidance targeted specifically at WCAG 2.2 AA criteria rather than broad training or IDE integration.
Should I use Accessibility (addyosmani) or Accessibility (affaan-m)?
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 (affaan-m) when
My client insists the site must meet a formal, narrowly defined set of accessibility success criteria from their audit; I need a hands‑on inspection that lists which specific criterion each failure maps to and gives concrete, implementation‑level fixes so engineers can close the exact compliance tickets.
accessibility-affaan-m is the right choice because it is built to inspect against a formal set of success criteria and produce hands‑on, criterion‑mapped checks with concrete fixes developers can apply to meet that audited standard. The most tempting wrong choice is accessibility-addyosmani — it also explains failures and gives step‑by‑step, code‑level remediation, but it’s focused on teaching remediation rather than acting as a strict, criterion‑mapped auditor or compliance checklist tool. accessibility-jezweb is tempting for clear, example‑based fixes, but it focuses on short pattern reviews and refuses to act as a full compliance scorer; accessibility-microsoft is irrelevant here because it targets accessibility of the development app/UI itself rather than auditing site content against a formal checklist.
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