Accessibility Compliance

by aj-geddes3f5182cfd739No license355 starsListed Oct 8, 2026Updated Oct 8, 2026Repository updated 7 months ago

Implement WCAG 2.1/2.2 accessibility standards, screen reader compatibility, keyboard navigation, and a11y testing. Use when building inclusive web applications, ensuring regulatory compliance, or improving user experience for people with disabilities.

Instructions onlySoftware Development
AI-generated overview

Guides implementation of WCAG 2.1/2.2 web accessibility, screen reader support, and keyboard navigation.

What it does
This skill provides instructions and reference guides for implementing web accessibility following WCAG 2.1/2.2, covering semantic HTML with ARIA, keyboard navigation, focus management, color contrast, screen reader announcements, and accessible React components. It includes a component template and best-practice do and don't lists. It produces guidance and code patterns rather than running any tooling itself.
When to use it
Use it when building public-facing or inclusive web applications, pursuing WCAG AA or AAA compliance, supporting screen readers such as NVDA, JAWS, or VoiceOver, or meeting ADA and Section 508 requirements. It also fits accessibility audits and keyboard-only navigation work.
Requirements
No scripts or tooling are required; it is instructions and reference documents only. An agent capable of reading the bundled reference guides and template is sufficient.

Accessibility Compliance

Table of Contents

Overview

Implement comprehensive accessibility features following WCAG guidelines to ensure your application is usable by everyone, including people with disabilities.

When to Use

  • Building public-facing web applications
  • Ensuring WCAG 2.1/2.2 AA or AAA compliance
  • Supporting screen readers (NVDA, JAWS, VoiceOver)
  • Implementing keyboard-only navigation
  • Meeting ADA, Section 508, or similar regulations
  • Improving SEO and overall user experience
  • Conducting accessibility audits

Quick Start

Minimal working example:

html
<!-- Bad: Non-semantic markup --><div class="button" onclick="submit()">Submit</div>
<!-- Good: Semantic HTML --><button type="submit" aria-label="Submit form">Submit</button>
<!-- Custom components with proper ARIA --><div  role="button"  tabindex="0"  aria-pressed="false"  onclick="toggle()"  onkeydown="handleKeyPress(event)">  Toggle Feature</div>
<!-- Form with proper labels and error handling --><form>  <label for="email">Email Address</label>  <input    id="email"    type="email"    name="email"    aria-required="true"// ... (see reference guides for full implementation)

Reference Guides

Detailed implementations in the references/ directory:

GuideContents
Semantic HTML with ARIA [blocked]Semantic HTML with ARIA
React Component with Accessibility [blocked]React Component with Accessibility
Keyboard Navigation Handler [blocked]Keyboard Navigation Handler
Color Contrast Validator [blocked]Color Contrast Validator
Screen Reader Announcements [blocked]Screen Reader Announcements
Focus Management [blocked]Focus Management

Best Practices

✅ DO

  • Use semantic HTML elements
  • Provide text alternatives for images
  • Ensure sufficient color contrast (4.5:1 minimum)
  • Support keyboard navigation
  • Implement focus management
  • Test with screen readers
  • Use ARIA attributes correctly
  • Provide skip links
  • Make forms accessible with labels
  • Support text resizing up to 200%

❌ DON'T

  • Rely solely on color to convey information
  • Remove focus indicators
  • Use only mouse/touch interactions
  • Auto-play media without controls
  • Create keyboard traps
  • Use positive tabindex values
  • Override user preferences
  • Hide content only visually that should be hidden from screen readers

Source and attribution

Source:aj-geddes/useful-ai-promptsinskills/accessibility-complianceat commit3f5182c

License: No license

Content belongs to its original authors. SourceWeft indexes it from a public repository.

Report or request removal