Design for everyone by treating accessibility as a first-class design discipline, not a compliance checklist. Part of the Intent design strategy system. Covers WCAG 2.2 for designers, screen reader experience design, keyboard navigation, cognitive accessibility, motor accessibility, inclusive design

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. Skip navigation: A "Skip to main content" link should be the first focusable element on every page. Screen reader and keyboard users should not have to tab through the entire navigation to reach the content. Understandable — Can every user understand the content and interface? Reading level: Write for your audience. Consumer products should target 8th grade reading level. Professional tools can target higher, but keep instructions and error messages as simple as possible regardless. Use short sentences. Avoid jargon. Define technical terms on first use. Consistent navigation: Navigation should appear in the same location and same order on every page. Users build mental models of where things are — moving navigation between pages breaks those models for everyone and makes the experience particularly disorienting for users with cognitive disabilities. Predictable interactions: Clicking a link should navigate. Changing a dropdown should not auto submit a form. Hovering should not trigger irreversible actions. No unexpected context changes — the user should always feel in control. Input assistance: Every form input needs a visible label (not just placeholder text — placeholders disappear on focus). Required fields must be indicated before submission. Error messages must identify the field and the problem. Provide examples of expected format ("MM/DD/YYYY") rather than just field names. Robust — Will it work with current and future assistive technologies? Valid HTML structure: Semantic HTML is the foundation. Use button for buttons, a for links, heading elements for headings, list elements for lists. Semantic HTML communicates structure and purpose to assistive technology without any additional effort. ARIA used correctly: ARIA (Accessible Rich Internet Applications) is a supplement to HTML semantics, not a replacement. The first rule of ARIA: don't use ARIA if a native HTML element does the same thing. The second rule: wrong ARIA is worse than no ARIA. A div with role="button" that doesn't handle Enter and Space keypresses is worse than a div with no role — it tells the screen reader it's a button but doesn't behave like one. Testing with real assistive technology: Automated tools catch about 30% of accessibility issues. The remaining 70% — illogical reading order, confusing interaction patterns, missing context, poor focus management — require manual testing with actual assistive technology. 2. Screen reader experience design Screen reader accessibility is not just about adding alt text to images. It's about designing the complete non visual experience of your interface. Reading order. Does the DOM order match the visual order? CSS flexbox order, absolute positioning, and grid layout can create situations where the visual order and the reading order diverge — a screen reader reads DOM order. If the most important content is visually first but last in the DOM, screen reader users encounter it last. Landmarks. Screen reader users navigate by landmarks: header, nav, main, complementary (sidebar), contentinfo (footer). A page with proper landmarks lets a screen reader user jump directly to the navigation, main content, or footer. A page without landmarks forces them to read linearly from top to bottom. Every page should have exactly one main landmark. Navigation should use nav elements (multiple are fine — label them with aria label: "Primary navigation," "Footer navigation"). Heading hierarchy. Screen reader users navigate by headings more than any other method. H1 for the page title. H2 for major sections. H3 for subsections within those. Never skip levels (H1 to H3 with no H2). Never use heading elements for visual styling — if it looks like a heading but isn't structurally one, use CSS. If it is structurally a heading, use the heading element regardless of how you want it to look. Live regions. Dynamic content that updates without a page reload — notifications, chat messages, form validation messages, auto updating data, progress indicators — needs aria live regions. Use aria live="polite" for updates that can wait until the user is idle (new chat messages, stock prices). Use aria live="assertive" only for urgent updates that shou

include