include

Audits designs against WCAG 2.2 and guides inclusive, accessible experience design.

Updated Jul 21, 2026
One-click install
npx skills add https://github.com/rakedzior/rootine --skill include-rakedzior
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: include
Source: https://github.com/rakedzior/rootine/tree/main/agent/skills/include
Command: npx skills add https://github.com/rakedzior/rootine --skill include-rakedzior

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Design teams often ship interfaces that exclude users with disabilities because accessibility is treated as a late compliance checkbox rather than a design discipline, creating legal risk under ADA, EAA, and Section 508. ## Core Features & Use Cases - WCAG 2.2 Design Guidance: Translates the four WCAG principles (Perceivable, Operable, Understandable, Robust) into concrete design decisions covering contrast, keyboard navigation, touch targets, and semantic HTML. - Screen Reader & Keyboard Experience Design: Provides methodology for reading order, landmarks, heading hierarchy, live regions, 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 handing off a new checkout flow, run an accessibility audit to verify keyboard operability, screen reader announcements, color contrast ratios, and touch target sizes, then deliver a prioritized remediation plan to engineering. ## Quick Start Audit this checkout flow design 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 design for WCAG 2.2 accessibility?

Audit against the four WCAG principles: check color contrast ratios (4.5:1 for text), keyboard operability of all interactive elements, visible focus indicators, touch targets of at least 24x24 CSS pixels, and semantic HTML structure. Combine automated scans with manual keyboard and screen reader testing.

What accessibility issues do automated tools miss?

Automated tools like axe, Lighthouse, and WAVE catch roughly 30% of issues, mostly programmatic ones like missing alt text or low contrast. The remaining 70% — illogical reading order, confusing interaction patterns, poor focus management — require manual testing with real assistive technology.

How do I test a website with a screen reader?

Use VoiceOver on Mac/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 are the WCAG touch target size requirements?

WCAG 2.2 requires a minimum of 24x24 CSS pixels for touch targets, 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.

Is web accessibility legally required?

Yes, WCAG conformance is legally mandated in many jurisdictions: the ADA in the US, the European Accessibility Act in the EU, Section 508 for US government, and AODA in Ontario, Canada. Web accessibility lawsuits have increased every year for a decade.

When should ARIA be used instead of native HTML?

ARIA should only supplement HTML when no native element exists for the pattern. The first rule of ARIA is to prefer native elements like button and nav; incorrect ARIA, such as role="button" without keyboard handlers, is worse than no ARIA at all.