One of the testers described adding a parking space to the app as easy. Then they explained that afterwards, the only way they could get back to the main screen was to close the app and open it again.
They were right, and it was entirely my doing: three separate design decisions, each defensible on its own, stacked into a dead end. Nothing about that bug is specific to parking, or to disability. It's the ordinary fabric of mobile development.
I'm Ryan, and I built Close to the Door, a free app for finding accessible parking. I launched it two months ago to make a difference to Disabled people's access to work and to social life, and to start collecting data on what needs to change. I started this work because, as a Disabled software developer, it was a solution that I needed myself. But after conversations with dev friends and colleagues, I've realised that what I've learned in building this app is relevant and important to all developers, whatever they're working on.
Earlier this year I asked Tilting the Lens, a Disabled-led accessibility consultancy, to run a proper, paid study of the app. Twelve Disabled drivers and passengers took part, across the UK, Ireland and Spain: wheelchair and power-chair users, walking-aid and prosthetic users, people with chronic illness, neurodivergence and learning disabilities, and people who were Blind and low-vision. It ran in two phases, on iPhone and Android, in multiple languages, with a mid-point loop so that whatever Phase One found, I could fix and Phase Two could re-test.
Those twelve people are behind most of the best decisions I've made about this codebase since January, about how the app functions, and about a much broader definition of accessibility than I started with. It was a small sample, and it taught me quickly that no two Disabled people are the same, and neither are their access needs.
The testers were generous and precise. Every Phase One participant found the app useful and managed to set it up on their phone. Then they showed me, in detail, where it failed. Very little of what they taught me was about parking. It was about navigation, error handling, text scaling and what a data model claims to know. So what follows is a thank-you in the only currency engineers really have — taking feedback seriously enough to rebuild things — and, at the same time, the field notes I'd hand to any mobile team.
Five habits, if you're skimming:
- Every screen needs a way back out, not just a way in.
- No failure should be silent — instrument the error paths before you polish the happy path.
- Design for text at three times the size, and test on the way back down.
- Treat "I don't know" as a first-class value. A wrong "yes" is worse than a blank.
- Write down what your testing didn't cover as carefully as what it found.
One note on numbers before I use any. This was a small study, so where I quote figures, read them as direction within a group of twelve, not as statistics.
Every screen needs a way back
Testers liked how fast you could get into things. A Phase One participant put it like this:
"On my screen, I see a button titled 'Explore', where it shows nearby parking spaces. From a disabled point of view, this is fabulous. We need a really short user trajectory towards the desired functionality of the app."
— Phase One Participant
Getting back out was another story, as the tester who had to force-quit the app discovered.
They had run into three of my design choices stacked on top of each other. In pursuit of a clean, map-first look, the whole Explore section ran with native headers hidden, which quietly removed every back button. Search lived in its own navigation stack outside the tab bar, so opening it made the tabs vanish too. And the space detail wasn't a screen at all but a bottom sheet over the map, so no header there either. Each choice looked fine on its own; together they left no way out.
The accessibility scanning tools I ran against the app passed these screens without complaint.
What that tester changed: search now lives inside the Explore tab's own stack, so the tab bar never disappears. The back arrow sits inside the search pill itself, where your attention already is. The space detail became a proper full-screen page with a labelled back button. And on Android, the hardware back button now does what people mean by it — when search results are showing, it clears the search instead of leaving the screen. Returning Phase One testers welcomed the change in Phase Two.
No failure should be silent
An Android tester reported that the search bar sometimes disappeared, and asked for it to be fixed to the top or bottom of the screen so it stayed reachable. They were right about the cause before I was: the search entry point floated on top of the map in an absolutely positioned overlay, and other surfaces could sit over it.
It's now a persistent header rendered above the map as part of the layout, not an overlay — padded for the device safe area, present in every state including while GPS is still finding you, with a pill-shaped input that keeps a visible border and a comfortable minimum height. Anything people depend on to get around your app belongs in the layout, not floating over it. Phase Two found it easy to locate, and rated the microphone on its right-hand side genuinely useful.
That microphone taught me a bigger lesson. The study said two things at once: voice search was considered useful, and some participants couldn't get it to work. Both were true. When I dug in, the voice code showed a helpful message for exactly three kinds of error, and for every other kind it logged the failure internally and showed the user nothing at all.
The people most dependent on it are the least able to tell you why it broke. So the error paths now get the attention the happy path always got. Every speech-recognition error speaks: specific, translated messages, an "Open Settings" shortcut when it's a permissions problem, and unknown errors reported to error tracking so real-world failures become visible instead of vanishing.
Design for text at three times the size
Several testers use large text sizes, and they scaled the app up to where they actually read. The screenshots told the story. At roughly 2.4× scale — well within what iOS offers — a fourteen-character username rendered one letter per line. List rows squeezed their titles between a fixed-size icon and a chevron until only the first letter survived. The space detail screen clipped both of its columns at once, labels losing their endings on one side while values lost theirs on the other.
Every failure traced to the same two habits: fixed dimensions, and text assumed to fit on one line forever.
The rebuild those testers prompted touched 79 files, and its centre is a single question each screen now asks: is the font scale at least 1.2×, or the window narrower than 360px? If so, the layout stacks. Rows of icon-text-chevron become vertical. Icon tiles use minimum sizes rather than fixed ones, so they grow to hold a scaled glyph instead of clipping it. Decorative chevrons step aside; labels that would shrink to fit instead wrap to a second line; addresses get three lines instead of one; grids drop to a single column. And where a visual indicator is hidden in the stacked layout, its meaning moves into the screen-reader label, because hidden must never mean lost.
If you take one testing habit from this post, take this one: check every screen at roughly 1.4×, 2.4× and 3× font scale. Shrinking back down catches different bugs than starting large.
My favourite bug of the batch: iOS doesn't reliably tell a backgrounded app that the user changed their text size. A tester could change their text in Settings, come back, and find a stale layout. The fix I settled on isn't elegant, but it's honest: on return, if the text scale has moved more than 5%, the app quietly reloads itself behind the splash screen. I'd choose that over showing someone a broken layout every time.
There's more to do here, and it's worth saying plainly: what I've built so far is reflow layouts that hold their shape. Between the two phases, the "suggest an edit" task went from ten of the twelve testers rating it accessible to all twelve. I can't credit one commit for that, but the form's building blocks (its fieldset headers and picker controls) were exactly where the fixed-tile and one-line habits got fixed.
A wrong "yes" is worse than a blank
A tester in Spain pointed out something the app didn't know: in parts of the UK a Blue Badge holder is limited to around four hours in an accessible bay, but in Spain a Disabled driver can often stay far longer. My parking timer, with options capping at four hours, risked implying four hours was the rule everywhere. They were teaching the data model some humility. I added longer durations and a plain disclaimer that times are indicative and local rules vary; a properly region-aware rules engine is still ahead of me.
That humility now runs through the whole schema, and it's the single most transferable thing the research reinforced. A painted wheelchair symbol tells you almost nothing about whether a bay works for you. So contributors record what a person can actually observe. Bay width, whether there's an access aisle, whether it's generous or narrow; kerb side, slope, surface, lighting, dropped kerbs, rear access for tail-lifts. And every field defaults to "unsure", never to a plausible value, because an untouched form must not assert a fact.
Someone plans a journey around this data. "Unknown" lets them plan for uncertainty; a wrong "yes" strands them a long way from where they needed to be.
Whatever your app's domain, its data makes promises to somebody. Treat "I don't know" as a first-class value, and only collect certainty a real person can honestly supply.
Know what your testing can't tell you
The testers also left me a to-do list, and it's a good one.
They asked for a talking, audio-first way to find a space. Two participants were Blind or losing their sight, and while the app works with screen readers, finding a bay by ear rather than by map is a different and better ambition than anything I've built. They asked for photos of spaces. And they asked, loudest of all, to know whether a bay is free right now. I've since released a first version of occupancy, built on the signals of people parking through the app, but whether it earns trust in the real world is exactly what a desk-based study can't tell me, so real-world field testing is the next research I owe them.
There's a gap in the study itself I haven't solved either: nobody over 65 took part. That generation was also flagged as least familiar with some of the iconography the app leans on. That's not a finding, it's a weak spot, and closing it is on me. Every study has edges like these; the discipline worth keeping is writing down what your testing didn't cover with the same care as what it found.
How to run one of these yourself
If this post has done its job, the obvious next question is how. A few things I'd pass on from one project's experience.
Go to a Disabled-led organisation rather than recruiting testers yourself. Recruiting across that range of access needs is a skill in itself, and how the questions are framed matters as much as who answers them.
Ask for two phases with enough of a gap between them to actually ship the fixes. The most useful signal I got wasn't Phase One finding problems. It was Phase Two confirming that the fixes worked, for the same people who had reported them.
Plan for the fixes. A study that surfaces a 79-file rebuild is only worth commissioning if you have the time afterwards to do the rebuild.
Test on both platforms, and in more than one language. A good share of what I've described here was platform-specific — the Android hardware back button, iOS not announcing a text-size change. And the four-hour parking assumption only surfaced because someone outside the UK was in the room.
Pay people. Disabled testers bring expertise; they aren't doing you a favour. What a study costs scales with its scope, so it's worth writing a brief and asking for a quote against it rather than guessing at a figure and deciding it's out of reach.
The habits that stuck
Working with these twelve people permanently changed how I build. Stacked layouts are now a written house rule for every new screen, not an aspiration. Error paths get instrumented before happy paths get polished. Forms default to "unsure". And when I catch myself assuming I already understand an access need, I remember that twelve people examined this app, kindly, thoroughly, and correctly.
None of those habits came from an audit tool or a checklist, useful as both are. They came from twelve people using the app and saying what happened. If mobile development can learn one thing from Disabled testers, it's to work with some.
Close to the Door is free, on iOS and Android. To the twelve of you, thank you. The app is better because you showed me exactly what it needed.
Cheers, Ryan
Research conducted independently by Tilting the Lens. Quotations are drawn from participants across both research phases and reproduced with permission; participants are identified only by research phase to protect their anonymity. Participants were paid for their expertise and contribution.