Skills fixing-accessibility
♿

fixing-accessibility

Safe

Fix Accessibility Issues

Accessibility issues can exclude users with disabilities from using your product. This skill provides clear rules and practical fixes for common accessibility problems in UI components.

Supports: Claude Codex Code(CC)
🥉 73 Bronze
1

Download the skill ZIP

2

Upload in Claude

Go to Settings → Capabilities → Skills → Upload skill

3

Toggle on and start using

Test it

Using "fixing-accessibility". /fixing-accessibility button.jsx

Expected outcome:

  • Violation: Icon button lacks accessible name (line 5)
  • Why it matters: Screen reader users cannot identify the button action
  • Fix: Add aria-label or use aria-labelledby to provide accessible name

Using "fixing-accessibility". How do I make a modal dialog accessible?

Expected outcome:

  • Key requirements for accessible modals:
  • 1. Trap focus inside the dialog while open
  • 2. Restore focus to the trigger element on close
  • 3. Set initial focus on the first interactive element
  • 4. Close on Escape key press
  • 5. Ensure proper aria-modal and role='dialog' attributes

Security Audit

Safe
v1 • 2/16/2026

All static findings are false positives. The skill is a benign accessibility guidelines document containing slash commands for invoking the skill and technical terms related to accessibility (aria-invalid, aria-describedby). No actual security risks detected.

1
Files scanned
120
Lines analyzed
0
findings
1
Total audits
No security issues found

Detected Patterns

False Positive: External Commands DetectionFalse Positive: Weak Cryptographic AlgorithmFalse Positive: System Reconnaissance
Audited by: claude

Quality Score

38
Architecture
100
Maintainability
85
Content
50
Community
100
Security
83
Spec Compliance

What You Can Build

Apply Accessibility Rules to New UI

When building new buttons, forms, or dialogs, invoke the skill to ensure all work follows accessibility best practices from the start.

Review Existing Code for Issues

Run the skill against existing UI code to identify accessibility violations, understand their impact, and get targeted fix suggestions.

Learn Accessibility Best Practices

Use the skill as a reference guide to learn about keyboard access, focus management, ARIA usage, and semantic HTML.

Try These Prompts

Apply to Current Work 
/fixing-accessibility

Apply these constraints to any UI work in this conversation.
Review a Specific File 
/fixing-accessibility <file>

Review the file against all rules below and report violations (quote the exact line or snippet), explain why it matters (one short sentence), and provide a concrete fix (code-level suggestion).
Fix a Button 
How do I make an icon-only button accessible?
Fix a Form Error 
How should I associate error messages with form fields for accessibility?

Best Practices

  • Prefer minimal, targeted fixes over large refactoring to reduce risk
  • Use native HTML elements before adding ARIA attributes
  • Test keyboard navigation manually after applying fixes
  • Quote exact code snippets when reporting violations

Avoid

  • Do not use div or span as buttons without full keyboard support
  • Do not add aria attributes when native semantics already solve the problem
  • Do not remove focus outlines without providing a visible replacement
  • Do not rely on color alone to convey state or meaning

Frequently Asked Questions

What is the priority order for fixing accessibility issues?
Priority order is: accessible names (critical), keyboard access (critical), focus and dialogs (critical), semantics (high), forms and errors (high), announcements (medium-high), contrast and states (medium), media and motion (low-medium), and tool boundaries (critical).
Does this skill automatically fix accessibility issues?
No. The skill reports violations with explanations and fix suggestions, but you must apply the fixes manually to your code.
What are accessible names and why do they matter?
Accessible names are what screen readers announce for interactive elements. Every button, link, and input must have a meaningful accessible name so users with visual impairments can understand and navigate the interface.
When should I use ARIA versus native HTML?
Always prefer native HTML elements with built-in accessibility. Use ARIA only when native elements cannot express the required semantics. Remember: if you can use a native button, do not use a div with role='button'.
How do I test if my accessibility fixes work?
Use keyboard-only navigation (Tab, Shift+Tab, Enter, Escape), screen reader testing (NVDA, VoiceOver), and browser accessibility inspectors. The skill provides guidance but does not replace manual testing.
What is focus trapping in dialogs?
Focus trapping keeps keyboard focus inside a modal dialog while it is open. Users should not be able to tab to elements behind the dialog. When the dialog closes, focus must return to the element that opened it.

Developer Details

Author

ibelick

License

MIT

Repository

https://github.com/ibelick/ui-skills/tree/main/skills/fixing-accessibility/

Ref

main

File structure

📄 SKILL.md