Accessibility Isn't Optional in a Mental Health App

We treated accessibility as a compliance checklist for longer than we should have. WCAG contrast ratios, alt text on images, keyboard navigation, screen-reader labels — we ran the audits, fixed what came up red, and moved on. It took a testing session with actual screen reader users, watching someone try to find our crisis resources page and fail, to understand how incomplete that checklist actually was.

The gap wasn't in the code. Our automated audit tooling passed the build. The gap was between 'technically accessible' and 'usable by someone whose attention, memory, or motor control is compromised in the moment they most need the app to work.' Closing that gap meant rethinking accessibility as a design problem, not just an engineering one, and it changed how our whole team talks about what 'done' means for any feature.

What the automated audit missed

Automated accessibility tools are good at catching missing alt text, insufficient contrast, and unlabeled buttons — all things our audit correctly flagged and we fixed. What it can't catch is a navigation structure that makes logical sense to a sighted person scanning a page but is disorienting to someone moving through it linearly by screen reader, one element at a time, with no visual overview to anchor them. That gap only showed up once we watched real people use the product.

The screen reader session that changed things

We recruited screen reader users to test the app directly, and one moment from that session stuck with the team: a participant, asked to find crisis resources, took over ninety seconds and two wrong turns to get there — well past what would be reasonable for someone who actually needed it urgently. The page existed, was labeled correctly, and passed every automated check. It just wasn't where a screen reader user would think to look for it.

Cognitive load as an accessibility problem

Most accessibility guidelines focus on sensory and motor access — vision, hearing, dexterity. They say very little about cognitive load, which matters enormously in a product used disproportionately by people experiencing anxiety, depression, or acute stress, all of which measurably affect attention, working memory, and decision-making. We started treating 'can someone under cognitive strain use this' as its own accessibility category, evaluated separately from WCAG compliance, not folded into it.

Building low-stimulation mode

Low-stimulation mode reduces animation, mutes color saturation, simplifies layouts to a single column, and removes auto-playing content throughout the app. We initially scoped it as a temporary 'crisis mode' someone could toggle on during a hard moment. We changed that after realizing the toggle itself was an extra decision to make under stress — asking someone to find and enable a calming mode while overwhelmed defeats the purpose. It's now a standing preference, set once, that many users just leave on.

The mistake: crisis resources behind an accordion

The version of the app that failed our screen reader tester had crisis resources nested inside a collapsed 'Support' accordion in a settings-adjacent menu — logical from an information-architecture standpoint, invisible under pressure. We moved it to a persistent, always-visible entry point reachable from every screen in one tap, sacrificing some visual tidiness in the main navigation for something more important: findability when finding things is hard.

Keyboard navigation for a different kind of user

Standard keyboard navigation testing checks whether every function is reachable without a mouse. We added a second pass specifically for someone using the keyboard slowly and imprecisely — hands shaking, attention fragmented — checking whether focus order made sense, whether tab targets were forgiving enough, and whether any interaction required a fast or precise sequence of keystrokes. Several exercises that involved timed inputs got redesigned to remove the time pressure entirely once we looked at them this way.

Font size and motion, and why we went further than the spec

WCAG's motion and font-size requirements set a minimum. We went past it: every animation in the app respects reduced-motion settings by default rather than requiring an opt-out, and our maximum font-scaling support goes beyond what most component libraries ship with, because we heard directly from users that standard scaling limits still left text too small during states where reading clearly is already harder than usual.

Where we still fall short

We don't have this solved. Our voice-input support is thinner than we'd like, our onboarding flow is still longer than it should be for someone with limited working memory in the moment, and we know from support tickets that some assistive technology combinations still surface bugs our internal testing doesn't catch. We publish an accessibility statement that names these gaps directly rather than claiming a compliance level we haven't fully earned.

Testing as an ongoing practice, not a launch gate

We now run structured accessibility testing with real assistive-technology users on a recurring basis, not just before major releases. It's slower than relying on automated audits alone, and it's caught real problems automated tooling didn't — including, this year, a focus-trap bug in the safety plan builder that would have been genuinely serious for someone relying on a screen reader to complete it.

Accessibility work in most products is about not excluding people. In a mental health app, it's closer to the whole point — the people who most need a feature to work reliably are often the same people for whom stress, fatigue, or a compromised sense degrades usability the fastest. Getting this right isn't a nice-to-have layered on top of the product. For a meaningful share of our users, it's the difference between the product working at all.