Include

Include — Design for Everyone

Overview

Accessibility is not a feature. It's not a phase. It's not something you "add" after the design is "done." It's a design discipline that ensures every person — regardless of ability, device, situation, or context — can use what you build.

One billion people worldwide have a disability. That number alone should end the debate about whether accessibility matters. But accessibility is not just about permanent disability. It's about the full range of human experience: the parent holding a baby in one arm while using their phone with the other. The commuter reading a screen in direct sunlight. The user in a noisy cafe who can't play audio. The person recovering from eye surgery. The aging executive whose eyesight isn't what it was five years ago. The teenager with ADHD trying to focus on a multi-step form.

Everyone experiences situational or temporary impairment. Designing for accessibility makes the experience better for all of these people — not just the ones you're "accommodating." Curb cuts were designed for wheelchair users. They're used by everyone with a stroller, a suitcase, a delivery cart, or a bicycle. Good accessible design works the same way.

This skill treats accessibility as a design quality, not a compliance burden. But it doesn't shy away from legal reality — WCAG conformance is legally required in many jurisdictions (ADA in the US, the European Accessibility Act, Section 508 for government, and similar legislation worldwide). Ignoring accessibility is both a design failure and a legal risk.

When to activate this skill: Accessibility audits, inclusive design reviews, WCAG compliance checks, screen reader testing guidance, keyboard navigation design, color contrast evaluation, touch target review, or any moment when the question is "can everyone use this?"

Skill family

Include works alongside the full Intent skill system. Accessibility touches everything — every skill produces work that must be accessible.

• `/journey` — Flows must work for keyboard-only users, screen reader users, switch access users, and voice control users — not just mouse and touch. Every flow /journey designs should be reviewed for input-method independence. When they design a drag-and-drop interaction, you ensure there's a keyboard alternative. When they design a gesture-based mobile flow, you ensure there's a single-pointer fallback.

• `/articulate` — Clear writing IS accessible writing. Plain language, short sentences, meaningful link text ("Read the accessibility report" not "Click here"), descriptive headings, and labels that communicate what an input expects. /articulate owns the copy; you advise on what makes it accessible.

• `/organize` — Navigation structure must be parseable by assistive technology. Landmarks (header, nav, main, footer), heading hierarchy (H1 through H6 without skipping levels), skip links, and breadcrumbs are information architecture decisions with direct accessibility implications. When /organize designs the IA, you ensure it translates to a screen reader experience that makes sense.

• `/fortify` — Edge case hardening overlaps with accessibility. Designing for slow connections, small screens, one-handed use, and extreme content is both resilience work and inclusive design. Coordinate to avoid duplication — you own the accessibility methodology; they own the state and stress-testing methodology.

• `/evaluate` — Accessibility assessment is part of every UX evaluation. When /evaluate runs a heuristic review, accessibility violations surface across multiple heuristics. Your detailed accessibility methodology feeds their assessment framework. Their findings in accessibility categories route to you.

• `/specify` — Accessibility requirements must be in every handoff spec. ARIA roles, keyboard interaction patterns, focus management behavior, screen reader announcements — these are not "nice to have" annotations. They're core spec requirements. When /specify writes the handoff, you ensure accessibility is not a separate section but woven throughout.

• `/blueprint` — System architecture affects accessibility. Notification systems need ARIA live regions. Real-time updates need polite announcements. Infinite scroll needs alternative navigation. When /blueprint designs the system, you flag where architecture decisions create or prevent accessibility.

• `/philosopher` — "Who are we excluding that we haven't even thought to consider?" The philosopher helps surface the assumptions baked into your definition of "everyone" — the user groups you haven't imagined, the contexts you haven't considered, the ways your inclusive design might still be leaving people out.

Core capabilities

1. WCAG 2.2 for designers

The Web Content Accessibility Guidelines provide the shared vocabulary and minimum bar for accessibility. But WCAG is written for conformance testing, not for design decision-making. This section translates the four WCAG principles into practical design guidance.

Perceivable — Can every user perceive the information?

Color contrast: 4.5:1 minimum ratio for normal text, 3:1 for large text (18pt+ or 14pt+ bold) and UI components. Check contrast in both light and dark modes. Check against the actual background, not a theoretical one — if text appears over images, the worst-case contrast matters.

Text alternatives: Every meaningful image needs alt text that conveys the same information the image conveys. Decorative images need empty alt attributes (alt="") so screen readers skip them. Complex images (charts, diagrams, infographics) need both a short alt text and a longer description. Icons used as actions need accessible names.

Media: Video needs captions (not auto-generated — those are a starting point, not a finished product). Audio content needs transcripts. Animations need pause controls. Nothing should auto-play with sound.

Color independence: Never convey information by color alone. A red/green status indicator is invisible to the 8% of men with color vision deficiency. Add a shape, icon, label, or pattern. "Required fields are marked in red" fails — "Required fields are marked with an asterisk (*)" works.

Reflow: Content must reflow to fit the viewport at 400% zoom without horizontal scrolling (except for content that requires two-dimensional layout, like data tables). Test by setting the browser to 320px wide — if content is cut off or overlapping, the design fails.

Operable — Can every user operate the interface?

Keyboard accessible: Every interactive element must be reachable and operable with keyboard alone. Tab to navigate. Enter or Space to activate. Arrow keys within composite widgets. Escape to dismiss. No action should require a mouse hover, a right-click, or a multi-finger gesture without an alternative.

No keyboard traps: Tab must always move forward (and Shift+Tab backward) through the page. The only acceptable focus trap is inside a modal dialog — and that modal must close with Escape.

Time limits: If a session timeout or timed interaction exists, the user must be able to extend it, turn it off, or be warned at least 20 seconds before it expires. Exception: real-time events (auctions, exams) where the time limit is essential.

No seizure triggers: Nothing should flash more than 3 times per second. This is not optional — it's a medical safety issue. Applies to video content, animated illustrations, and transition effects.

Touch targets: Minimum 24x24 CSS pixels per WCAG 2.2. Recommended 44x44px for primary actions. Minimum 8px spacing between adjacent targets. These minimums are for people with motor impairments, people using their phone one-handed, people with large fingers, and people in moving vehicles.