Inclusive by Infrastructure: Engineering Design Systems for Emergent Interaction Models

Introduction: The Infrastructural Imperative for Inclusive Design

For teams building digital products today, the concept of a design system is familiar territory. It's the shared library of buttons, inputs, and patterns that promises consistency and speed. Yet, a persistent, quiet tension exists: these systems, built for the known, often struggle with the unknown. They excel at rendering a perfect desktop form but may fracture when faced with a voice-only user, a complex gesture command, or an AI agent attempting to navigate an interface on a user's behalf. This guide argues that true inclusivity is achieved not by bolting on features, but by engineering it into the infrastructure of the design system itself. We are moving from designing for specific modalities to engineering for emergent interaction models—those not yet fully defined but inevitable given technological trajectories. This overview reflects widely shared professional practices as of April 2026; verify critical details against current official guidance where applicable. The core pain point we address is the costly, reactive scramble to retrofit accessibility and new interaction support. By shifting perspective to "inclusive by infrastructure," teams can build systems that are inherently more adaptable, future-proof, and fundamentally equitable.

The Limitation of the Component-Centric Model

Traditional design systems are often component-centric. A team defines a <Button> with specific props for color, size, and state. Accessibility becomes an attribute list: `aria-label`, `tabindex`. This model treats inclusion as a property of a component, not a behavior of a system. When a new interaction model emerges—say, gaze control for AR glasses—every component requires re-auditing and re-engineering. The system lacks a foundational layer that understands intent ("activate this") separate from mechanism (click, tap, voice). This creates technical debt and exclusion by default, as new users with new tools hit dead ends built into the very foundation.

Defining Emergent Interaction Models

Emergent interaction models are patterns of human-computer interaction that gain significant traction, driven by advances in hardware, AI, and user behavior. They are often non-traditional and multimodal. Examples include conversational UI (voice and chat), spatial interactions (gesture, gaze, proximity), adaptive interfaces that reconfigure based on user ability or context, and agentic interactions where non-human AI actors operate the UI. These models don't replace the mouse and keyboard; they layer atop and beside them. A system built only for pointer and keyboard events has no native way to handle a "swipe left to confirm" gesture or a voice command to "navigate to the next data card." The infrastructure must be agnostic to the input source.

The Shift from Compliance to Capability

The business and ethical case for this shift is clear. Reactive compliance follows standards like WCAG, which is essential but often a trailing indicator. Building infrastructural capability means your system can meet compliance requirements more efficiently and, more importantly, serve needs that regulations haven't yet codified. It turns inclusion from a cost center (audits, remediation) into a quality and innovation accelerator. Products built on such systems can enter new markets and support new devices faster, with less rework. The mindset changes from "Does this component pass audit?" to "What interactions can this system support?"

Core Architectural Principles: Building the Adaptive Foundation

To engineer a design system for emergent interactions, you must embed specific principles into its architecture. These are not visual design tokens but foundational logic layers that dictate how the system understands and responds to user intent. Think of it as moving from a library of photographs (static, fixed) to a graphics engine (dynamic, responsive to input). The goal is to separate the "what" (user intent) from the "how" (interaction modality) and the "how it looks" (presentation). This decoupling is the single most important technical concept for achieving infrastructural inclusion. It allows the same core functionality to be rendered and operated via a screen reader, a voice assistant, or a gesture controller, with each modality receiving an optimized experience from a shared intent model.

Principle 1: Intent-Based Abstraction

Every interactive element must be defined first by its semantic intent, not its visual presentation or default trigger. Instead of a `<Button>`, think of an `<Action>` primitive with an `intent` property such as "submit," "dismiss," or "navigate." The system's logic layer maps this intent to available modalities. A "submit" intent could be fulfilled by a click, a "say 'submit'" voice command, a double-tap gesture, or an automated agent triggering the action. The component's visual representation (a button, a voice prompt highlight) becomes a render output based on context. This requires designing an ontology of intents for your application domain, which becomes the core contract between logic and presentation.

Principle 2: Modality Agnosticism

The system's event handling and state management must be abstracted away from DOM-specific events (`onClick`, `onKeyDown`). Implement a central interaction bus or state machine that accepts input events from any source: a pointer, a keyboard, a gesture recognizer, a voice intent parser, or an API call. This bus normalizes these inputs into canonical "action requests" (e.g., `{ intent: 'activate', target: 'save-button' }`) that components are built to respond to. Consequently, adding support for a new input device means writing one adapter to the bus, not refactoring dozens of components.

Principle 3: Context-Aware Responsiveness

Responsive design has meant adapting layout to viewport size. For emergent models, it must adapt behavior and presentation to interaction context. The system needs to be aware of the primary input modality (voice, touch, gaze), environmental constraints (noisy, hands-free), and user preferences (reduced motion, high contrast). This context should be propagated through the system, allowing components to adjust their affordances. A card component might reveal a larger touch target in a touch context, or emit a sonic cue in a voice-only flow. This moves responsiveness from CSS media queries to a holistic runtime context API.

Principle 4: Progressive Enhancement as a Core Ethos

The system must be built in layers, with a core functional layer that works with the most basic input and output (e.g., keyboard and text), and enhanced layers that add richer interactions for capable modalities. A voice interface becomes an enhancement atop the core intent layer, not a separate parallel interface. This ensures baseline usability is always maintained, and new modalities can fail gracefully without breaking the core experience. It's the practice of building upward from a solid, inclusive foundation, not outward from a fragile, modality-specific one.

Comparing Implementation Approaches: Frameworks, Libraries, and Custom Engines

Choosing how to build this infrastructural layer is a critical decision with long-term implications. Teams typically gravitate towards one of three paths, each with distinct trade-offs in control, complexity, and compatibility. There is no universally "best" option; the right choice depends on your team's expertise, the scale of your application ecosystem, and how far beyond current web standards you need to venture. The table below compares the core approaches. It's crucial to understand that most projects will use a hybrid strategy, perhaps a library for component structure and custom code for the interaction bus.

The decision often hinges on your timeline and ambition. For many teams, starting with a strong intent abstraction within their chosen framework (Approach 1) and planning for a central interaction bus (leaning toward Approach 3) as complexity grows is a pragmatic evolution. The key is to avoid Approach 2 in isolation, as using disparate libraries without a unifying strategy is a common path to fragmented, inaccessible experiences.

A Step-by-Step Guide to Incremental Infrastructure Migration

For an existing product with a legacy design system, a full rewrite is rarely feasible. The following step-by-step guide outlines a pragmatic, incremental migration path toward an infrastructurally inclusive system. This process focuses on de-risking the transition, delivering value at each stage, and building team buy-in through tangible improvements. The overarching theme is to add the new infrastructural layers alongside the old, gradually shifting responsibility, rather than attempting a "big bang" replacement. Expect this to be a multi-quarter initiative, treated as a foundational platform investment.

Step 1: Audit and Establish an Intent Ontology

Begin by conducting an interaction audit of your existing UI. Catalog every interactive component and map it to its user intent. Group these intents into a controlled vocabulary: "Navigate," "Select," "Activate," "Dismiss," "Input," "Expand." This ontology becomes your system's Rosetta Stone. For a typical web application, you might end up with 15-20 core intents. Document these with clear descriptions and examples. This is a collaborative exercise involving design, engineering, and accessibility specialists. The output is a shared JSON schema or TypeScript definitions that will drive future development.

Step 2: Build the Interaction Bus Prototype

Before touching production components, build a small, standalone prototype of your central interaction bus. Create a simple state machine (using a library like XState or a custom class) that can accept events from different sources (mock a click, a keyboard press, a voice command) and output normalized action requests based on your intent ontology. Test it with a simple demo app, like a todo list, to prove the concept. This prototype is a learning tool to iron out the API design and event flow without the pressure of legacy code.

Step 3: Create "Dual-Purpose" Primitive Components

Now, start introducing new, infrastructural primitive components. Build an `<IntentButton>` that accepts an `intent` prop and connects to your interaction bus, but for now, also emits a traditional `onClick` event as a fallback. Style it to look identical to your old `<Button>`. You now have a component that works both ways: via the old direct event and the new intent bus. Begin using this primitive for all new feature development. This creates a compatibility layer that allows the new and old models to coexist.

Step 4: Implement a Context Provider for Modality

Develop a React Context, Vue plugin, or similar mechanism to detect and broadcast the primary input modality. Start simple: detect `pointer: fine` (mouse) vs. `pointer: coarse` (touch). Inject this context into your new primitive components. Have them adjust their rendering slightly based on context—for example, adding larger padding for coarse pointers. This proves the value of context-aware rendering and sets the stage for more sophisticated detection (voice, gaze) later.

Step 5: Develop an Adapter for a Single Emergent Modality

Choose one emergent modality relevant to your product, such as keyboard shortcuts (a form of direct manipulation) or basic voice commands using the Web Speech API. Write an adapter that listens for these inputs and translates them into action requests on your interaction bus. Connect this adapter to your demo and then to a small, non-critical part of your live application. This is your proof-of-value for extensibility, demonstrating that new interaction models can be "plugged in."

Step 6: Establish Governance and Documentation

As the new patterns solidify, create formal governance. Document the intent ontology, the interaction bus API, and the patterns for creating new primitives and adapters. Update your contribution guidelines to mandate the use of intent primitives for new work. Establish a deprecation timeline for the old, direct-event components, communicating this clearly to all product teams. This step turns experimentation into institutional practice.

Step 7: Iterate, Expand, and Sunset

With the foundation and governance in place, the work becomes cyclical. Iterate on the ontology and bus based on real usage. Develop adapters for more modalities. Gradually migrate high-priority legacy components to the new primitives, measuring improvements in accessibility scores and development velocity for new features. Finally, sunset the legacy component APIs, completing the migration. The system is now an inclusive infrastructure, ready to evolve.

Real-World Scenarios and Composite Examples

To move from theory to practice, let's examine anonymized, composite scenarios that illustrate the challenges and solutions in context. These are based on common patterns observed across the industry, not specific, verifiable client engagements. They highlight the tangible impact of an infrastructural approach on product development, team velocity, and user experience.

Scenario A: The E-Commerce Platform and Voice Commerce

A team maintaining a large e-commerce design system faced a directive to explore "voice shopping." Their legacy system had robust `<ProductCard>` and `<AddToCartButton>` components. The initial, reactive approach was to build a separate, parallel voice interface that queried the backend API directly, bypassing the UI. This created inconsistency, duplication of logic, and a fractured user journey. Switching to an infrastructural approach, the team first defined intents for the card: "view product details," "add to cart," "compare." They refactored the `<ProductCard>` into a presentational component driven by an `<ProductIntentController>` that managed state via the interaction bus. The voice interface adapter could now emit the same "add to cart" intent as a mouse click. The UI responded visually (e.g., a confirmation animation), and the cart logic remained single-source. The result was a unified experience where a user could say "add that to my cart" while looking at the screen, and see it happen, creating a cohesive multimodal journey. The infrastructure built for voice also immediately improved screen reader navigation, as the intent layer provided clearer semantics.

Scenario B: The Data Dashboard and Spatial Analytics

A B2B analytics company wanted to prototype a version of its complex dashboard for use in immersive, spatial environments (e.g., VR rooms for data exploration). Their existing dashboard was a dense forest of charts, filters, and tables built with a component library tied to mouse hover and click events. Gesture controls like "pinch to zoom" on a chart or "grab and throw" to filter were impossible to integrate without rewriting everything. The team took six weeks to implement an interaction bus and redefine their core components around intents like "filter by dimension," "zoom timeseries," and "select data point." The visual components became "renderers" that subscribed to data and intent state. They then built a spatial adapter that mapped hand-tracking gestures from a VR SDK to those intents. The surprising outcome was that the new, intent-driven components were also far easier to test in 2D; they could simulate a "zoom timeseries" intent without mocking a gesture, speeding up their unit test suite. The infrastructure enabled the exploratory spatial feature without destroying the core product, and the cleaner architecture reduced bugs in the main application.

Scenario C: The Internal Tool and Adaptive Interfaces

An enterprise developed internal tools used by employees with a wide range of abilities and work contexts, including some with repetitive strain injuries who relied on switch devices and voice control. The tool's design system was "accessible" in that it passed automated WCAG tests, but its linear, tab-heavy workflows were inefficient for power users and cumbersome for switch device users. The team implemented a context system that could detect a user's preferred input profile ("mouse/keyboard," "switch/scanning," "voice dense," "voice minimal"). Based on this, the interaction bus would reconfigure the available intent shortcuts. For a "switch/scanning" profile, the UI would automatically group related intents into logical scan zones and prioritize a linear flow. For a "voice dense" profile, it would expose all possible voice commands contextually. The adaptive infrastructure, driven by user-controlled context, created a personalized layer on top of the same intent-based components, dramatically improving efficiency and satisfaction across the diverse workforce without forking the codebase.

Governance, Testing, and Maintaining the Living System

An infrastructural design system is not a one-time build; it's a living platform that requires active, thoughtful governance and robust verification methods. The complexity shifts from managing pixel-perfect components to ensuring the integrity of the intent layer, the correctness of modality adapters, and the consistency of the contextual behavior. Without strong governance, the system can become a confusing abstraction that developers bypass, reintroducing fragility. Testing must evolve from visual regression to interaction logic and state machine verification.

Governance Model: The Platform Team Mandate

Successful governance often centers on a small, cross-functional platform team with a mandate to maintain the core infrastructure—the intent ontology, interaction bus, and core primitives. This team does not own all components; instead, they provide the tools and rules. Product teams own domain-specific components (like a `<DataChart>`) but must build them using the sanctioned primitives and intents. The platform team's key responsibilities include curating the intent ontology (approving new intents), maintaining the central adapters for common modalities, providing golden-path templates, and running a compatibility suite that ensures new changes don't break existing modality support. Their authority comes from enabling other teams to move faster and more inclusively.

Testing Strategy: Beyond Screenshots

Testing must operate at three levels. First, unit tests verify the logic of the interaction bus and state machines: "Given input X, does it produce normalized action Y?" Second, integration tests verify that components respond correctly to intents across different simulated contexts (e.g., does the `<IntentButton>` visually highlight when focused via keyboard but not via mouse?). These can use tools like Testing Library with custom render contexts. Third, automated accessibility and interaction flow tests use tools like Axe-core combined with custom scripts that programmatically trigger intents via different simulated modalities (keyboard, voice command script) and assert on the resulting UI state and ARIA attributes. Visual regression testing becomes less about pixels and more about the correctness of focus indicators, live region announcements, and other modality-specific feedback.

Documentation as an Interactive Contract

Documentation cannot be a static style guide. It must be an interactive contract that demonstrates the system's capabilities. Build a living documentation site where developers can not only see component code but also interact with them using different modalities. Include a "modality simulator" that lets a developer toggle the context to "voice," "touch," or "keyboard" and see how the component's affordances and documentation change. List every available intent and which components consume them. Document the process for proposing a new intent or building a new adapter. This interactive doc site becomes the primary onboarding tool and source of truth.

Versioning and Deprecation of Intents

The intent ontology is a public API and must be versioned semantically. A change from `intent="submit"` to `intent="commit"` is a breaking change that requires a major version bump and a migration path. The governance team must manage deprecation cycles for intents, providing adapters that map old intents to new ones during a transition period. This discipline prevents the fragmentation of the interaction model and ensures that all modalities continue to work across versions of the system. It treats the interaction layer with the same seriousness as a backend API.

Common Questions and Practical Concerns

Adopting this paradigm raises legitimate questions from designers, engineers, and product managers. Addressing these concerns head-on is crucial for organizational buy-in. The questions below reflect typical hesitations, grounded in the practical realities of shipping product under constraints.

Isn't This Over-Engineering for Most Products?

It can be, if applied dogmatically. The key is proportionality. Not every product needs a full custom interaction engine for gaze control. However, the core principle of separating intent from mechanism has value at any scale. Even a simple start—defining an intent prop on your button components and using a context to adjust touch targets—is a step toward infrastructural thinking that pays dividends in accessibility and future flexibility. The degree of investment should match the anticipated diversity of interaction models in your product's future. For a marketing site, keep it simple. For a complex application or a platform, the investment is justified.

How Do We Convince Leadership to Invest in This?

Frame the investment in terms of risk reduction and efficiency, not just "doing the right thing." Argue that retrofitting for new modalities (like voice or legislation) is exponentially more costly than building the capability in from a foundational layer. Position it as a platform investment that accelerates all future feature development by providing a consistent, testable model for interaction. Use the composite scenarios as thought experiments to illustrate the cost of the reactive path versus the proactive one. Tie early wins, like improved accessibility audit scores or faster development of a multimodal prototype, to business metrics.

Does This Lock Us Into a Proprietary Architecture?

It creates an abstraction layer, which is a form of lock-in, but one with strategic benefits. The lock-in is to your own product's interaction model, not to a third-party framework. By adhering to web standards (like ARIA) within your intent layer, you maintain a bridge to the wider ecosystem. The risk is mitigated by designing the intent ontology and bus API as clean, well-documented internal contracts. This is similar to the "lock-in" of having a well-designed internal data model—it's a valuable asset, not a liability.

How Do We Handle Design Handoff and Prototyping?

This requires evolving design tools and processes. Designers must move from mocking up static screens to defining user flows and intent maps. Tools like Figma are beginning to support variables and component properties that can mirror intent states. The handoff artifact becomes a specification of intents, flows, and context-dependent variations, alongside the visual mockups. Prototyping should occur within the live system's documentation environment, where designers can test interactions across modalities, not just in a static interaction tool.

What's the Biggest Common Pitfall?

The most common failure mode is building the infrastructure but allowing teams to circumvent it via "escape hatches" for the sake of short-term speed. This recreates the fractured experience the system was meant to prevent. Governance and tooling must make the right path (using intents) the easiest path. This means providing excellent components, clear documentation, and automated linting that flags direct event usage in new code. The infrastructure must be a compelling convenience, not a bureaucratic hurdle.

Conclusion: Building for the Next Interaction, Not the Last One

The trajectory of human-computer interaction is clear: it is diversifying. The mouse and keyboard are not going away, but they are being joined and sometimes replaced by voice, gesture, gaze, and intelligent agents. A design system that is merely a catalog of yesterday's components becomes a bottleneck to innovation and a source of exclusion. By engineering inclusivity into the infrastructure—through intent abstraction, modality-agnosticism, and context-awareness—we build systems that are inherently more resilient, adaptable, and humane. This is not a speculative future; it is a necessary evolution of professional front-end architecture today. The shift requires upfront investment in thinking and platform work, but it repays that investment by turning your design system from a constraint into an enabler, capable of meeting users wherever and however they choose to interact. Start by defining your first intent, and build outward from there.