Decoding the Neurodiversity Paradigm: How Customizable AT is Reshaping User-Agent Collaboration

The neurodiversity paradigm reframes cognitive differences not as deficits to be fixed, but as natural variations requiring flexible environments. For assistive technology (AT), this means moving from a prescriptive model—where a tool dictates how a user should interact—to a collaborative one, where the user and the agent (the software) co-create the interaction. This shift is not just philosophical; it has concrete implications for how AT is designed, deployed, and maintained. In this guide, we examine the mechanics, trade-offs, and pitfalls of customizable AT from a practitioner's perspective.

Where Customizable AT Meets Real-World Workflows

Customizable AT shows up in environments where users have complex, fluctuating needs that off-the-shelf solutions cannot address. Think of a knowledge worker with ADHD who needs to toggle between a high-focus mode (distraction-free interface, limited notifications) and a collaborative mode (chat open, shared document editing). Or a developer with dyslexia who relies on a screen reader but also needs syntax highlighting and code navigation that the AT does not natively support. These are not edge cases—they are the norm in neurodiverse teams.

The core mechanism is user-agent collaboration: the user defines rules, triggers, and behaviors that the AT agent follows, but the agent also learns from user corrections and adapts over time. For example, a customizable text-to-speech tool might let the user set pronunciation exceptions, adjust reading speed per document type, or create macros for repeated phrases. The agent then remembers these preferences and applies them contextually.

We see this pattern in open-source AT like NVDA (NonVisual Desktop Access) with its extensive add-on ecosystem, and in commercial tools like Dragon NaturallySpeaking's custom voice commands. However, the degree of customization varies widely. Some tools offer a settings panel with checkboxes; others expose a scripting API. The choice between these approaches depends on the user's technical skill and the support infrastructure available.

One composite scenario: A QA engineer with autism uses a screen reader daily but finds standard navigation overwhelming during regression testing. She creates a custom script that collapses non-critical UI sections, announces only test failures, and reads log files in a condensed format. This script, shared with her team, becomes a productivity multiplier—but also a maintenance burden when the application UI changes. The collaboration is dynamic: the user adapts the agent, and the agent adapts to the user's feedback loop.

Another scenario: A remote team includes members with varying cognitive styles—some need minimal visual clutter, others need rich visual cues. They adopt a customizable dashboard tool where each person can toggle widgets, colors, and alert types. The team lead initially worries about inconsistency, but finds that customization reduces errors and support tickets. The catch is that onboarding new members requires documenting the customization options, and some users feel overwhelmed by the choices. Here, the field context reveals that customization is not a panacea; it requires deliberate design and training.

Foundations Readers Often Misunderstand

A common misconception is that customizable AT is inherently better than fixed AT. In reality, customization introduces complexity that can harm usability if not managed well. The neurodiversity paradigm does not demand infinite configurability—it demands that the tool can adapt to the user's needs without imposing a high cognitive load. Practitioners often confuse 'customizable' with 'configurable.' A configurable tool has preset options; a customizable tool allows users to define new behaviors. The latter requires more user effort and technical skill.

Another misunderstanding: that customization is a one-time setup. In practice, needs change—a user's sensory sensitivities may vary with stress, fatigue, or environment. Effective user-agent collaboration means the AT can switch profiles or adapt in real time. For instance, a user might have a 'morning' profile with slower speech rate and larger fonts, and an 'afternoon' profile with faster navigation and condensed output. Tools that only support static presets miss this dynamic aspect.

There is also confusion about who owns the customization. In many organizations, IT or accessibility teams configure AT for users, assuming they know best. This top-down approach contradicts the neurodiversity paradigm, which centers the user's expertise on their own needs. A better model is co-configuration: the expert provides a base setup and teaches the user how to modify it, then steps back. This requires training for both the user and the support team.

Finally, some teams assume that customization must be code-level—writing scripts or editing config files. While that offers maximum flexibility, it excludes many users. Lower-friction customization methods, such as drag-and-drop rule builders or natural language commands, can achieve similar outcomes with less barrier. The key is to match the customization interface to the user's comfort zone, not the developer's.

Patterns That Usually Work

Based on practitioner reports and observed successes, several patterns reliably improve user-agent collaboration in customizable AT.

Layered Defaults with Progressive Disclosure

Start with a sensible default that works for the majority of users. Then expose customization options in layers: basic (font size, speech rate), intermediate (keyboard shortcuts, color themes), and advanced (scripting API, custom gestures). Users can stop at any layer. This reduces overwhelm while still offering depth. For example, the screen reader JAWS uses this model: beginners use the default settings, while power users can create custom scripts.

Context-Aware Profiles

Allow users to create profiles tied to applications, tasks, or times of day. The AT should switch profiles automatically based on context (e.g., when the user opens a PDF, switch to reading mode). This pattern works well because it reduces manual toggling. A composite example: a project manager with ADHD uses a 'focus' profile during coding (minimal notifications, monochrome display) and a 'collaboration' profile during meetings (chat visible, speech-to-text active). The profiles switch based on the active window.

Community-Driven Add-Ons

Enable users to share customizations via a marketplace or repository. This scales the benefits beyond individual users and fosters a community of practice. However, quality control is essential—poorly written add-ons can crash the AT or introduce security risks. Moderation and peer review help. NVDA's add-on store is a good model, where add-ons are curated and versioned.

Feedback Loops with Learning

Incorporate mechanisms for the AT to learn from user corrections. For example, if the user frequently adjusts speech rate upward, the AT could offer to set a new default. Or if the user repeatedly dismisses a certain type of notification, the AT could suppress it. This reduces repetitive configuration. But learning must be transparent and reversible—users should know what the AT has inferred and be able to undo it.

User Testing with Neurodivergent Participants

Involve neurodivergent users in the design and testing of customization features. What seems intuitive to a neurotypical developer may be confusing or inaccessible to someone with executive function challenges. For instance, a customization interface that requires multi-step navigation may be unusable for a user with working memory limitations. Testing early and often prevents these mismatches.

Anti-Patterns and Why Teams Revert

Despite good intentions, many teams fall into traps that undermine customization and cause them to fall back on rigid defaults.

The Infinite Options Trap

Offering too many customization options without guidance leads to decision paralysis. Users may give up and use default settings, negating the benefit. This is especially problematic for users with executive function differences. Anti-pattern example: a screen reader with 200 settings in a flat list. The fix is to group options and provide presets.

Configuration as a One-Time Project

Treating customization as a setup task that is done once and forgotten ignores the dynamic nature of user needs. Teams that do not plan for ongoing adjustments end up with stale configurations that no longer serve the user. Reversion happens when the user finds the AT increasingly unhelpful and switches to a simpler tool.

Ignoring the Support Burden

Customizable AT creates a support overhead: users will break configurations, need help with scripting, and request features. If the support team is not equipped to handle this, they may discourage customization or impose restrictions. This anti-pattern is common in enterprise environments where IT controls software installations. The result is that users are locked into a default that does not fit.

Assuming Technical Literacy

Designing customization interfaces that require programming knowledge excludes a large portion of neurodivergent users. Even users who are technically inclined may not have the spoons to learn a scripting language. Teams that assume 'power users' will do the work for others often see low adoption. Better to offer multiple levels of customization, including visual editors.

Neglecting Privacy and Security

Custom scripts or add-ons can access sensitive data (e.g., screen content, keystrokes). If the AT platform does not sandbox these extensions, users may inadvertently expose themselves to risk. Teams that ignore security may face policy pushback, leading to a ban on customization. A balanced approach is to allow only signed or reviewed add-ons.

Maintenance, Drift, and Long-Term Costs

Customizable AT is not a set-and-forget solution. Over time, several factors increase maintenance burden.

Software Updates and API Changes

When the underlying application or operating system updates, custom scripts and configurations may break. Users must update their customizations, which requires time and expertise. For example, a custom NVDA script that worked with Firefox 100 may fail with Firefox 101 if the UI structure changes. Teams need to plan for regression testing of customizations.

Configuration Drift

Users may tweak settings incrementally without documenting changes, leading to a configuration that is poorly understood and hard to replicate. If the user's device is replaced, the configuration may be lost. Drift also occurs when multiple users share a device—customizations accumulate and conflict. Version control for configurations (e.g., storing them in a Git repo) can mitigate this, but it adds complexity.

Training and Knowledge Transfer

When a user who has built extensive customizations leaves the organization, their knowledge often leaves with them. New users may struggle to understand or modify the setup. Documentation and peer mentoring are essential but often neglected. The cost of onboarding a new user to a heavily customized AT environment can be high.

Emotional and Cognitive Load

For the user, maintaining customizations can be exhausting. The same executive function challenges that necessitate customization can make it hard to keep up with maintenance. Some users report feeling 'locked in' to their custom setup because changing it would require too much effort. This emotional cost is rarely accounted for in ROI calculations.

Despite these costs, many teams find that the productivity and well-being gains outweigh them—if the organization invests in support structures. A dedicated accessibility champion or a community of practice can share the maintenance load.

When Not to Use This Approach

Customizable AT is not always the right answer. There are scenarios where a fixed, well-designed default is preferable.

Low Technical Literacy or Support

If the user population has limited technical skills and there is no dedicated support team, customization may cause more frustration than benefit. In such cases, invest in finding a default that works for the majority, and offer only essential adjustments (e.g., font size).

High-Stakes, Regulated Environments

In contexts where consistency and auditability are critical (e.g., medical devices, aviation, legal document review), customization may introduce risks. A user might accidentally disable a critical feature or create a script that violates compliance. Here, a locked-down configuration with rigorous testing is safer.

Short-Term or Temporary Use

If a user only needs AT for a specific, short-term project (e.g., a conference), the overhead of customization may not be worth it. A default setup that gets the job done is more efficient. Customization pays off over longer periods where the configuration is reused.

When the User Prefers Simplicity

Some neurodivergent users prefer a consistent, predictable interface and find customization itself stressful. Forcing customization on them violates the neurodiversity paradigm's principle of respecting individual differences. Offer customization as an option, not a requirement.

Open Questions and FAQ

How do we measure the success of customizable AT?

Success is not just about task completion time; it includes user satisfaction, reduced cognitive load, and sustained usage over time. Self-report surveys, usage analytics (how often profiles are switched, how many customizations are created), and qualitative interviews provide a fuller picture. There is no single metric.

Can customization be over-engineered?

Yes. Some tools offer so many options that the interface itself becomes a barrier. A good heuristic: if the user needs a manual to configure the AT, it is probably over-engineered. The goal is to make customization easy, not comprehensive.

What role should AI play in user-agent collaboration?

AI can help by suggesting customizations based on user behavior, or by automatically adapting to context. However, AI must be transparent and under user control. Users should be able to override or disable AI suggestions. The risk is that AI makes incorrect assumptions and the user loses agency.

How do we handle customization across multiple devices?

Cloud sync of configurations is ideal, but raises privacy concerns (since configurations may contain personal data). An alternative is to store configurations locally and provide export/import tools. Some platforms use encrypted sync with user-controlled keys.

Is there a risk of digital divide?

Yes. Users who cannot afford high-end AT or lack the time to learn customization may be left behind. Open-source tools and community support can help bridge the gap, but not entirely. Practitioners should advocate for inclusive design that reduces the need for extensive customization in the first place.

Next actions for teams: audit your current AT to see if customization is accessible and well-supported; run a pilot with neurodivergent users to identify friction points; invest in documentation and peer support; and consider building a community around your AT to share customizations. The goal is not to maximize customization, but to maximize user autonomy.