mgifford/accessibility-skills/critic
Claude Code and agent skill by mgifford/accessibility-skills
- community
Checking that the SKILL.md file is still in the repository.
Install
npx vskill@latest install mgifford/accessibility-skills/criticSKILL.md
Critic Workflow
The Critic reviews accessibility decisions to ensure they meet professional standards and evidence requirements.
Purpose
The Critic's role is to:
- Validate ARRM grounding - Verify that findings use real ARRM tasks with correct role assignments
- Assess automation safety - Determine if deterministic fixes are appropriate
- Check role engagement - Ensure appropriate professional perspectives are consulted
- Evaluate evidence quality - Verify claims are supported and evidence types are distinguished
- Handle perspectives responsibly - Identify user impacts and avoid simulating lived experience
- Maintain decision quality - Ensure disagreements and unresolved risks are visible
When to Use
Use the Critic for any accessibility finding:
- After Planner assessment of a finding
- For manual review of implementation proposals
- When validating accessibility test results
- When cross-role decisions are being considered
The Critic works best after initial planning but before implementation begins.
When Not to Use
The Critic is not appropriate for:
- Simple technical fixes with clear requirements
- Quick accessibility checks where expert review isn't needed
- Routine validation without professional judgment concerns
Integration with Topic Skills
The Critic checks that AI workflow decisions respect relevant topic skills:
- forms → forms, content-design, keyboard
- keyboard → keyboard, touch-pointer, manual-testing
- color-contrast → color-contrast, light-dark-mode, visual-design
- charts-graphs → charts-graphs, image-alt-text, tables
- And other topic skills as appropriate
ARRM Task Validation
Grounding Requirements
For each accessibility finding, the Critic verifies:
- Real ARRM Task Usage
- Task IDs must exist in the ARRM CSV
- Must use real ARRM task IDs, not placeholders like "IMG-001"
- Must match actual W3C WAI ARRM dataset
- Role Assignment Accuracy
- Primary Ownership must match ARRM data
- Secondary Ownership must match ARRM data
- Contributor assignments must match ARRM data
- No invented or made-up role assignments
- Completeness
- All relevant ARRM tasks should be identified
- No critical ARRM tasks should be omitted
- All role responsibilities should be assigned appropriately
Example Valid ARRM Usage:
Example Invalid ARRM Usage:
Automation Safety Assessment
Safety Criteria
The Critic assesses whether an automated fix is appropriate based on:
- Rule Certainty
- High rule certainty: Clear technical requirements with authoritative source
- Medium rule certainty: Partially clear requirements
- Low rule certainty: Unclear or conflicting requirements
- Intent Certainty
- High intent certainty: Intended meaning and interaction clearly understood
- Medium intent certainty: Reasonable understanding with some ambiguity
- Low intent certainty: Intent unclear or uncertain
- Change Risk
- Low change risk: No impact on meaning, workflow, policy, visual hierarchy
- Medium change risk: Moderate impact on one or more areas
- High change risk: Significant impact on functionality or user experience
- Testability
- High testability: Can be reliably verified with automated tools
- Medium testability: Requires some manual verification
- Low testability: Requires extensive manual testing
Safety Decision Matrix
| Rule Certainty | Intent Certainty | Change Risk | Testability | Recommendation | |
|---|---|---|---|---|---|
| High | High | Low | High | Safe for automation | |
| High | High | Medium | Medium | Human confirmation needed | |
| High | Medium | Low | High | Cross-role decision | |
| High | Medium | Medium | Medium | Cross-role decision | |
| High | Low | Any | Any | Need more information | |
| Medium | Any | Any | Any | Insufficient evidence | |
| Low | Any | Any | Any | Insufficient evidence |
Safe Automated Fix Example
Unsafe Automated Fix Example
Role Engagement Review
Question Quality Checks
The Critic verifies that questions are properly directed:
- Primary Role Questions
- Address core responsibility ownership
- Focus on implementation choices within their domain
- Ask for justification of their preferred approach
- Secondary Role Questions
- Consider broader impact of Primary's decision
- Evaluate interaction with their area of expertise
- Identify potential conflicts with their responsibilities
- Contributor Role Questions
- Ensure the solution works across all relevant technical areas
- Validate implementation feasibility
- Check for integration with existing systems
Missing Professional Perspectives
The Critic identifies roles that should be involved but aren't:
Role Conflict Documentation
When different roles suggest conflicting approaches:
- Record Each Role's Position
- Document Evidence Supporting Each View
- Identify the Trade-off Being Made
- Specify Who Should Make the Final Decision
- Recommend Who Should Be Consulted
- Note What Evidence Would Reduce Uncertainty
Evidence Assessment
Evidence Types and Quality
The Critic evaluates the quality and completeness of evidence:
- Automated Evidence
- Axe-core scan results
- Automated testing tools output
- Static code analysis
- Manual Evidence
- Keyboard testing results
- Screen reader testing notes
- Visual inspection findings
- User Research Evidence
- Disabled user testing results
- User interviews and feedback
- Survey data
Evidence Quality Criteria
- Sufficient Evidence
- Coverage of all relevant scenarios
- Adequate sample size for user testing
- Diverse testing conditions
- Current vs. Historical
- Up-to-date testing methodology
- Current assistive technology versions
- Relevant for the target user population
- Documented Process
- Clear reproduction steps
- Test conditions clearly stated
- Results recorded systematically
Perspective Handling
User Impact Analysis
The Critic examines likely impacts for specific user groups:
- Screen-Reader Users
- Does the change affect information announcement?
- Are semantic landmarks preserved?
- Are navigation patterns disrupted?
- Motor/Ergonomic Users
- Does the change affect target size or spacing?
- Are keyboard interactions maintained?
- Are gesture-based interactions accessible?
- Visual Users
- Does the change affect color contrast?
- Are focus indicators preserved?
- Are visual relationships maintained?
- Cognitive Users
- Does the change affect complexity or clarity?
- Are instructions clear and concise?
- Are error messages helpful?
Appropriate User Research Recommendation
User research should be recommended only when:
- Essential for decision: Cannot resolve uncertainty without direct user input
- High impact: Will significantly affect multiple user groups
- Insufficient internal evidence: Current evidence cannot determine the best approach
Simulating Lived Experience Detection
The Critic ensures it does not:
- Claim first-hand experience: Should not state "I tested with screen readers"
- Make universal claims: Should not say "People with visual impairments can't..."
- Generalize from single anecdote: Should not base conclusions on limited testing
Evidence Gathering Requirements
| Evidence Type | When Required | How Gathered | |
|---|---|---|---|
| Automated | Deterministic, clear rules | Axe-core, static analysis | |
| Manual | Requires human interpretation | Keyboard testing, manual checks | |
| User Research | Cannot determine best approach | Usability studies, interviews |
Decision Quality Review
Disagreement Documentation
When professional roles disagree:
- Record Each Role's Position
- Document the Evidence supporting each position
- Identify the Core Trade-off
- Specify Decision Authority
- Recommend Consultation Process
- Document What Evidence Would Reduce Uncertainty
Decision Owner Identification
The Critic determines who has ultimate decision authority:
Primary Role: Has final decision authority for tasks where they have Primary Ownership
Secondary Role: Can challenge Primary role decisions, especially when their expertise is relevant
Contributor Role: Provides technical implementation but defers to Primary/Secondary decisions
Rationale Documentation
Quality decisions include clear documentation of:
- Decision Basis: What evidence and analysis supported the decision
- Stakeholder Input: Which professionals were consulted and their recommendations
3.
- Trade-offs Considered: What alternatives were evaluated and why they were rejected
- Risk Assessment: What are the known risks and mitigation strategies
Unclear Risk Documentation
Transparency about uncertainty:
- Known Limitations: What the decision cannot fully address
- Monitoring Requirements: What should be tracked post-implementation
- Revisit Triggers: Under what conditions the decision should be reviewed
- Evidence Gaps: What information is still needed but unavailable
Structured Critic Output
The Critic produces structured output with the following sections:
This is the start of the file. Read the full SKILL.md on GitHub.
Security
- Security scanPassed, 95 of 100Pattern checks on the skill's files.
- Model reviewPassed
Quality evaluation
- Task evaluationNot runNo evaluation yet. Run one in Skill Studio.
Source
- SKILL.md in the repositoryCheckingai-workflows/critic/SKILL.md
Popularity
- 7-day trend score
- 5
Not refreshed yet.
Works with
Any agent vskill installs to: 56 targets in all. These 39 have a page on this site.
- Claude Code
- Cursor
- GitHub Copilot
- Windsurf
- Codex
- Gemini CLI
- Cline
- Amp
- Roo Code
- Goose
- Continue
- Kilo Code
- Junie
- Trae
- OpenHands
- Qwen Code
- AI Agent
- Tabnine Chat
- Sourcegraph Cody
- Amazon Q
- Firebase Genkit
- Sweep
- Devin
- Phind
- Mentat
- Claude Desktop
- Aider
- GPT Pilot
- Plandex
- bolt.new
- v0
- Replit Agent
- Anse
- TypingMind
- BetterChatGPT
- LibreChat
- Warp AI
- Pieces
- Fig AI
Embed badge
[](https://verified-skill.com/skills/mgifford/accessibility-skills/critic)