common-accessibility

Apply WCAG 2.2 and ARIA practices to UI components.

1|Updated Mar 19, 2026
One-click install
npx skills add https://github.com/wildbitca/ai-resources --skill common-accessibility
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: common-accessibility
Source: https://github.com/wildbitca/ai-resources/tree/main/skills/common-accessibility
Command: npx skills add https://github.com/wildbitca/ai-resources --skill common-accessibility

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve?

Accessibility is often overlooked, leading to non-compliant web interfaces that exclude users. This Skill provides a concrete baseline of WCAG 2.2, ARIA, and semantic HTML practices to help teams build inclusive UIs and reduce accessibility risks.

Core Features & Use Cases

  • Semantic HTML First: use native semantics to convey structure and role, minimizing reliance on non-semantic divs for interactive controls.
  • ARIA Guidelines: when needed, apply ARIA roles and properties carefully to enhance accessibility without overriding native semantics.
  • Keyboard Navigation: ensure all interactive elements are reachable and operable via keyboard with clear focus indicators.
  • Color & Contrast: provide sufficient contrast ratios and avoid conveying information solely with color.
  • Testing & Validation: references to automated and manual testing tools (axe-core, screen readers) to verify accessibility.
  • Anti-Patterns: common pitfalls to avoid (divs masquerading as buttons, missing labels, focus traps).

Quick Start

Review your UI components and apply accessible patterns to meet WCAG 2.2 standards in the current project.

Frequently Asked Questions about common-accessibility

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I make my web components accessible with WCAG 2.2 standards?

To make web components accessible with WCAG 2.2, prioritize semantic HTML over non-semantic divs, ensure full keyboard navigation with visible focus indicators, and apply ARIA roles only when native semantics are insufficient.

When should I use ARIA roles instead of semantic HTML for UI accessibility?

Use ARIA roles for UI accessibility only when native HTML elements cannot convey the required structure or interaction. Semantic HTML is preferred as it provides built-in accessibility without the risk of overriding native behaviors.

How do I check color contrast ratios for WCAG compliance?

To check color contrast for WCAG compliance, verify that your UI provides sufficient contrast ratios between text and background. Ensure information is not conveyed solely through color to maintain accessibility for all users.

Does this accessibility guidance work for React and Vue projects?

Yes, this accessibility guidance applies to React, Vue, and plain HTML projects. It provides ARIA-compliant practices, semantic HTML usage, and keyboard navigation patterns suitable for these frameworks during UI development and audits.

What are common accessibility anti-patterns to avoid in web development?

Common web accessibility anti-patterns include using divs masquerading as buttons, missing input labels, and creating focus traps. Avoid these pitfalls by using native semantic elements and testing with screen readers.

How do I validate keyboard navigation for screen reader compatibility?

To validate keyboard navigation and screen reader compatibility, use automated testing tools like axe-core alongside manual screen reader testing. Ensure all interactive elements are operable via keyboard with clear focus indicators.