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.

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 should interrupt the user (error messages, critical alerts). Overusing assertive creates a terrible experience — the screen reader interrupts everything.

Form labeling. Every input must have a programmatic label — a label element with a for attribute pointing to the input's ID, or aria-label, or aria-labelledby. Placeholder text is not a label. Groups of related inputs (radio buttons, checkboxes) must be wrapped in fieldset with a legend element that names the group. "Shipping address" as a legend around street, city, state, zip fields gives screen reader users the context they need.

State communication. Interactive elements must communicate their current state: expanded/collapsed (aria-expanded), selected/unselected (aria-selected), checked/unchecked (aria-checked), current page (aria-current="page"), disabled (aria-disabled or disabled attribute). Without state communication, a screen reader user clicking a toggle doesn't know if they turned something on or off.

Hidden content. Decorative images get aria-hidden="true" or empty alt text. Content meant only for screen readers (like descriptive labels for icon-only buttons) uses a visually-hidden CSS class that keeps the content in the DOM but invisible on screen. Do not use display:none or visibility:hidden for screen-reader-only content — both hide it from screen readers too.

3. Keyboard navigation design

Keyboard accessibility is the single most impactful accessibility feature because it serves the broadest range of users: screen reader users, users with motor impairments, power users who prefer keyboard efficiency, users with temporary injuries, and anyone whose mouse or trackpad stops working.

Focus management. Tab moves focus forward through interactive elements. Shift+Tab moves backward. The tab order should match the visual reading order. Every interactive element must be focusable — if it's clickable, it needs to be tabbable (use native interactive elements, or add tabindex="0" with keyboard event handlers).

Visible focus indicators. The currently focused element must be visually obvious. A 2px+ solid outline that contrasts with the background by at least 3:1. Not just a color change — that fails for color-blind users. Not a subtle dotted line — that's invisible to many users. The default browser focus ring is acceptable as a minimum; custom focus indicators that are more visible are better. Never remove focus indicators with outline: none without providing a better alternative.

Skip links. A "Skip to main content" link as the first focusable element on every page. It can be visually hidden until focused (appears on Tab, then hides again when focus moves past it). This lets keyboard users bypass repeated navigation blocks.

Focus traps. Focus should only be trapped inside modal dialogs. When a modal opens, focus moves into it. Tab cycles within the modal's interactive elements. Escape closes the modal and returns focus to the element that triggered it. Everything else — dropdowns, menus, sidebars — should not trap focus.

Roving tabindex for composite widgets. Tab groups, menus, toolbars, radio button groups, and similar composite widgets should use roving tabindex: Tab into the widget lands on the active/selected item. Arrow keys move between items within the widget. Tab out moves to the next widget. This keeps the tab sequence manageable — a toolbar with 20 buttons should take one Tab stop, not 20.

Custom keyboard shortcuts. If you implement custom shortcuts, document them. Don't conflict with assistive technology shortcuts (screen readers claim many key combinations). Provide a way to view, change, or disable custom shortcuts. Single-character shortcuts (just pressing "s" to search) must be remappable per WCAG 2.1 — they conflict with voice control and sticky keys.

4. Cognitive accessibility

Often overlooked, always impactful. Cognitive accessibility benefi

…

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: ghaida
• Source: ghaida/intent
• License: CC0-1.0
• Homepage: https://designwithintent.ai

Install and usage instructions live in the source repository linked above.