Tools That Work With Your Brain

Core Concepts

The IDE as an accessibility problem

Standard developer tooling was not designed with neurodivergent users in mind. A think-aloud study with nine university computing students using Visual Studio Code documented consistent experiences of frustration tied directly to IDE design and layout. The cognitive demands of navigating multi-modal, information-dense interfaces compound with executive function challenges — task initiation, attention management, context switching — to create friction that is embedded in the tools themselves, not the user.

This is not a marginal issue. The same study found that while customizability had positive impacts, current IDE design still falls short of adequately supporting neurodivergent engineers.

WCAG COGA: the cognitive accessibility standard

WCAG (Web Content Accessibility Guidelines) is the dominant accessibility standard for digital interfaces, but its general requirements leave significant gaps for cognitive accessibility. The Cognitive Accessibility Guidance (COGA) complements WCAG with 8 objectives and specific design patterns addressing ADHD, autism, dyslexia, and related conditions.

Where WCAG checks contrast ratios and keyboard navigation, COGA targets things like: consistent navigation, error prevention and recovery, minimizing cognitive load, and plain language. Broad WCAG compliance alone does not guarantee that a tool is usable for neurodivergent engineers. COGA fills that gap.

Universal design: flexibility as a foundation

Universal Design principles, when applied to developer tools, create environments that benefit neurodivergent users by supporting flexible interaction modes and progressive disclosure of complexity. These include keyboard shortcuts, voice recognition, customizable interface options, and the ability to reduce or reveal complexity on demand.

The key insight from universal design is that one-size-fits-all interface design is insufficient — and that accommodating neurodivergent users also improves usability for everyone. This is not a tradeoff; it is a design multiplier.

Programmability as a cognitive advantage

Developer tools have a distinctive advantage over most workplace software: they are programmable. IDEs, text editors, terminal environments, and CI/CD systems can be configured through plugins, themes, keybindings, and automation to match individual cognitive and sensory profiles.

The "code-as-configuration" nature of developer tooling — settings files, dotfiles, plugin registries — makes customization scriptable, versionable, and shareable in ways that GUI-driven workplace software cannot match. Neurodivergent-specific tools exist and are actively maintained: dyslexia-friendly themes (Squirrelsong Light, AbleShade), ADHD-focused plugins, distraction-free modes, and notification management configurations are all documented and available.

Working memory and digital tools

Digital platforms that overtax working memory reduce efficiency for users with ADHD. The specific culprits are: frequent multitasking requirements, inconsistent visual cues, complex tab switching, and unclear organizational structure. Complex task boards can induce "task paralysis" and fatigue when cognitive load exceeds executive function capacity.

Effective tool design for ADHD brains requires clear organizational architecture, consistent visual cuing, task scaffolding that prevents multitasking demands, and progressive disclosure of information to prevent cognitive overload. This applies to IDEs, project management tools, and documentation systems equally.

AI as a working memory exoskeleton

AI coding tools do not just autocomplete. They offload the cognitive scaffolding that executive function struggles to provide.

AI-assisted coding tools mitigate ADHD-related programming challenges through four primary mechanisms:

1. Cognitive scaffolding — automated pattern recognition reduces cognitive planning overhead.
2. Task decomposition — breaking complex algorithms into manageable components.
3. Real-time contextual support — reducing attention-switching costs.
4. Personalized learning systems — adapting to individual presentations over time.

Research identifies productivity increases of up to 55% in code generation for developers with ADHD when using generative AI tools. Natural-language "vibe coding" — describing intent before worrying about syntax — directly reduces executive function demands and task initiation barriers. The AI holds the scaffolding while you do the thinking.

Notifications: the interruption problem

Notifications are not a minor UX concern. For users with ADHD and autism, interrupting notifications that force focus changes disrupt workflow and compound cognitive load in ways that are difficult to recover from.

Accessible notification design means: using aria-live="polite" to queue notifications until task completion; avoiding forced focus changes except for genuinely critical alerts; respecting user timeout preferences; and enabling full keyboard navigation for notification actions. These are not "nice to have" — they are the difference between a recoverable and an unrecoverable context switch.

Typography: not aesthetics, ergonomics

Font choices in a code editor are not aesthetic preferences. They are accessibility decisions with measurable consequences.

Increased inter-letter spacing has a significantly larger and more reliable effect on reading performance for dyslexic individuals than font selection alone. A spacing improvement of approximately 35% of average letter width measurably improves readability. Critically, the benefits commonly attributed to specialized dyslexia fonts like Dyslexie derive primarily from their increased spacing characteristics — not their distinctive letter shapes.

For code specifically, sans-serif monospaced fonts outperform serif and proportional fonts for dyslexic programmers. The monospace characteristic provides consistent letter width, making character differentiation easier. The combination of sans-serif style (simplified letter forms) and monospace formatting (equal-width characters) produces substantially better readability outcomes.

Fig 1

Plain language in interfaces

Neurodivergent users demonstrate stronger preference for and better comprehension with plain language in interface copy, error messages, and documentation. Avoiding jargon, using short sentences, and providing concrete rather than abstract instructions reduce cognitive load across ADHD, autism, and dyslexia presentations. Error messages that say "Something went wrong" rather than "ECONNRESET: connection reset by peer" are not just friendlier — they are faster to process when executive resources are already taxed.

Accommodations vs. participatory design

There is a meaningful difference between receiving an accommodation and shaping your tools. Research on assistive technologies for neurodivergent populations demonstrates that participatory and co-design methods — integrating neurodivergent users, designers, and clinicians in continuous engagement, not one-off feedback sessions — produce more effective tools than traditional top-down development.

This applies directly to developer tooling. An employer providing a screen reader is passive accommodation. A neurodivergent engineer configuring their own VS Code settings, contributing to an accessibility plugin, or advocating for sensory-friendly tooling choices in their team is participatory design. Both matter, but only one treats the engineer as an expert in their own experience.

Effective accommodations also require individualization, not diagnostic categories. Preferences vary significantly within ADHD, autism, and dyslexia groups — what reduces friction for one person may increase it for another. The goal is customizable controls, not uniform solutions.

Step-by-Step Procedure

Auditing and configuring your development environment

Use this procedure to systematically reduce cognitive friction in your tooling. Work through it in sections — you do not need to complete it in one session.

Step 1: Typography baseline

1. Open your IDE font settings.
2. Set the font to a sans-serif monospaced typeface (options: JetBrains Mono, Fira Code, Cascadia Code, IBM Plex Mono).
3. Increase letter-spacing. In VS Code: "editor.letterSpacing": 0.5 as a starting point. Research supports approximately 35% of average letter width — experiment upward from 0.3.
4. Increase line height to at least 1.5 ("editor.lineHeight": 1.5).
5. Note: if you use a specialized dyslexia font like Dyslexie, understand the benefit is primarily from its spacing — you can replicate most of the effect with a well-spaced standard monospace font.

Step 2: Theme and visual noise

1. Install a theme with high contrast and clear syntax differentiation. Avoid themes with many similar-value colors in the same region.
2. Enable or trial a distraction-free or zen mode (VS Code: View > Appearance > Zen Mode).
3. Disable or reduce decorations you do not actively use: minimap, breadcrumbs, status bar items, activity bar badges.

Step 3: Notification and interruption management

1. Audit which notification types interrupt your focus. In VS Code: check Settings > Notifications.
2. Disable non-critical auto-popups. Prefer notifications that appear in a status bar or badge rather than modal interruptions.
3. If you use system-level notifications for your IDE or build tools, configure them to batch or use "Do Not Disturb" profiles during deep work sessions.

Decision point: If you cannot navigate the settings interface itself without frustration, that is diagnostic information. Start with a community-maintained starter config (search for "ADHD VS Code settings" or "dyslexia VS Code setup") rather than building from scratch.

Step 4: AI integration

1. Install an AI coding assistant (GitHub Copilot, Continue, Cody, or equivalent).
2. Configure it for inline suggestions rather than modal pop-ups.
3. Practice using it for task decomposition: describe what you want in plain language before writing any code. Let the AI generate a structural scaffold; then edit and refine. This pattern externalizes working memory.

Step 5: COGA self-audit

Apply the following questions to any interface you use regularly:

COGA objective	Question to ask
Consistent navigation	Does the interface behave the same way in different contexts?
Error prevention	Does the tool prevent mistakes, or just report them after?
Plain language	Are error messages and labels concrete and jargon-free?
Memory independence	Do I need to remember state across context switches?
User control	Can I control notification timing and interruptions?
Adaptability	Can I customize information density and visual presentation?

Note where the tool fails. This becomes your case for advocacy or your plugin development backlog.

Step 6: Version and share your configuration

1. Export or version your settings (VS Code: Settings Sync, or commit your settings.json and extensions list to a dotfiles repository).
2. Share useful configurations with teammates or publicly. Participatory design includes the community — your configuration is potentially someone else's accessibility solution.

Worked Example

Configuring VS Code for a mixed ADHD and dyslexia profile

Context: An engineer with ADHD and dyslexia is experiencing fatigue and frequent context loss during code review sessions. They find the default VS Code interface visually noisy, lose their place in long files, and get derailed by build notification pop-ups mid-thought.

Step 1 — Typography changes:

{
  "editor.fontFamily": "JetBrains Mono, monospace",
  "editor.fontSize": 14,
  "editor.letterSpacing": 0.5,
  "editor.lineHeight": 1.6,
  "editor.wordWrap": "on"
}

The monospaced sans-serif font and increased letter spacing target dyslexia-related character recognition. Word wrap prevents horizontal scrolling during review, which adds a context-switching cost.

Step 2 — Visual noise reduction:

{
  "editor.minimap.enabled": false,
  "breadcrumbs.enabled": false,
  "workbench.statusBar.visible": true,
  "editor.renderLineHighlight": "all",
  "editor.scrollBeyondLastLine": false
}

The minimap is removed (a source of visual complexity rarely consulted), line highlighting is enabled to make the current position visually anchored, and the scroll boundary is capped to reduce disorientation in long files.

Step 3 — Notification control:

The engineer configures their OS "Do Not Disturb" to suppress all non-critical notifications during scheduled review blocks. In VS Code, they disable the auto-opening Problems panel and configure the build task to write output to a log file rather than the integrated terminal (reducing surprise interruptions).

Step 4 — AI scaffolding for review:

During code review, instead of trying to hold the entire PR context in working memory, the engineer pastes individual functions into their AI assistant and asks: "What does this function do? What edge cases should I check?" The AI generates a summary that acts as an external memory anchor for the review comment they are writing.

Outcome: The typography changes reduce reading fatigue. The visual noise reduction keeps attention on the current line. Notification control prevents unrecoverable context switches. The AI integration offloads the working memory demand of holding PR context while composing review comments.

Active Exercise

Accessibility audit of your current setup

This exercise has two parts. Complete Part A before Part B.

Part A: Document the friction (15 minutes)

Over the course of one work session, keep a running note (paper or a separate text file — not another tab) of every moment when your tooling generates friction. Be specific:

• What triggered the interruption?
• Where did it come from in the interface?
• How long did it take to recover your focus?

At the end of the session, categorize your notes:

• Typography/readability friction
• Notification/interruption friction
• Navigation/layout friction
• Working memory demand (something you had to hold in your head unnecessarily)

Part B: Apply one change per category (next session)

Choose the highest-friction item from each category and apply one targeted change:

• Typography: Change one font setting. Note whether readability improves.
• Notifications: Disable one source of interruption. Note the difference.
• Navigation: Enable one feature or disable one UI element that reduces visual noise.
• Working memory: Use your AI assistant to externalize one thing you would normally try to hold in your head.

After the session, write two to three sentences on what changed and what you would change next. This is your personalization log — the beginning of a versioned configuration that represents your cognitive profile.