include

Audit and design accessible interfaces against WCAG 2.2 criteria.

Updated May 5, 2026
One-click install
npx skills add https://github.com/TheGeekosaurus/blogging-platform-2 --skill include-thegeekosaurus
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: include
Source: https://github.com/TheGeekosaurus/blogging-platform-2/tree/main/.agents/skills/include
Command: npx skills add https://github.com/TheGeekosaurus/blogging-platform-2 --skill include-thegeekosaurus

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Design teams often ship interfaces that exclude users with disabilities because accessibility is treated as an afterthought or a compliance checkbox. This Skill provides a complete methodology for designing, auditing, and testing interfaces so that people with visual, motor, cognitive, and situational impairments can perceive, operate, and understand them. ## Core Features & Use Cases - WCAG 2.2 Design Guidance: Translates the four WCAG principles (Perceivable, Operable, Understandable, Robust) into concrete design decisions covering contrast ratios, touch targets, focus indicators, and semantic HTML. - Screen Reader & Keyboard Experience Design: Covers reading order, landmarks, heading hierarchy, ARIA live regions, form labeling, focus management, and roving tabindex patterns. - Accessibility Testing Methodology: Combines automated tools (axe, Lighthouse, WAVE) with manual keyboard, screen reader, zoom, contrast, and reduced-motion testing, plus a prioritized P0-P3 remediation plan. - Use Case: Before shipping a new checkout flow, run an accessibility audit to verify keyboard operability, screen reader announcements, color contrast, and touch target sizes, then receive a prioritized remediation plan. ## Quick Start Audit this checkout flow for WCAG 2.2 accessibility issues and produce a prioritized remediation plan.

Frequently Asked Questions about include

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

FAQPage Schema
How do I audit a website for WCAG 2.2 accessibility?▼

Run automated scans with axe, Lighthouse, or WAVE on every page, then manually test keyboard navigation, screen reader output, 200-400% zoom, and color contrast. Automated tools catch roughly 30% of issues, so manual testing with real assistive technology is required for the rest.

What color contrast ratio is required for WCAG compliance?▼

WCAG requires a 4.5:1 contrast ratio for normal text and 3:1 for large text (18pt+ or 14pt+ bold) and UI components. Check contrast against actual backgrounds including images and gradients, in both light and dark modes.

How do I test a website with a screen reader?▼

Use VoiceOver on Mac or iOS (Cmd+F5), NVDA on Windows (free), or TalkBack on Android. Listen for logical reading order, announced roles and states on interactive elements, form labels, live region updates, and meaningful heading and landmark structure.

What is the minimum touch target size for accessibility?▼

WCAG 2.2 requires a minimum of 24x24 CSS pixels, with 44x44px recommended for primary actions and at least 8px spacing between adjacent targets. Measure the tappable area including padding, not just the visible element.

Why do automated accessibility tools miss most issues?▼

Automated tools only detect programmatic problems like missing alt text or low contrast, about 30% of all issues. Illogical reading order, confusing interaction patterns, poor focus management, and missing context require human judgment and manual assistive technology testing.

When should ARIA be used instead of semantic HTML?▼

ARIA should only supplement HTML when no native element provides the needed semantics. The first rule of ARIA is to prefer native elements like button and nav, because incorrect ARIA creates a worse experience than no ARIA at all.