A Letter to Developers

Hello friends in the software and hardware world,

Let’s have a little chat, the kind where we’re on the same team, sitting across from one another with coffee in hand, and I’m quietly sliding you a note that says: “Hey, maybe don’t move that menu again.”

This isn’t a rant. It’s not a complaint piece. Think of it as the friendly reminder you’d give a colleague before they walk into a meeting with spinach stuck in their teeth. Except in this case, the spinach is unnecessary UI changes, and the teeth are your product’s user experience.

I’m writing this both as someone who’s worked in development for many, many years and as someone who now relies heavily on accessibility tools as a blind traveler. I know what it’s like to be on your side of the table, making design decisions, and I know what it’s like to be on the user side, running face-first into those same design decisions when they go sideways.

The heart of this letter is simple: change for the sake of change isn’t just frustrating. It’s disruptive. It breaks trust. It slows people down. And here’s the kicker — it doesn’t just impact blind and low-vision users like me. It makes things harder for everyone.

The High Cost of “Freshening Up”

There’s a reason we humans like routines. Muscle memory, procedural memory,  whatever you want to call it, is faster than conscious thought. We repeat an action enough times, and our brains offload it from thinking to instinct. Whether it’s typing your password, finding the “Save” button, or navigating a menu, those ingrained actions make us efficient.

But when you move the furniture around for no reason? The efficiency evaporates.

Research confirms this. A 2020 study found that once interface habits are disrupted, users lose all the speed and accuracy they’d built up over time (arxiv.org study). Imagine spending months perfecting a shortcut, only for it to be taken away overnight. It’s like rearranging your kitchen drawers just to “freshen things up”, and now you’re standing in the dark, trying to find the forks.

Take Apple’s SOS slider change. For years, holding the iPhone’s side buttons brought up a Power Off slider, conveniently in the center of the screen. Then Apple moved it to the top and stuck an SOS slider in the middle. Suddenly, 911 call centers saw a spike in accidental emergency calls because users thought they were shutting off their phone. To this day, I still have to pause and carefully navigate to the right slider. That’s not innovation. That’s misplacing the forks.

Or look at Instagram. The option to unfollow someone? Buried. The alt text option? Hidden two or three menus deep in the “other” posting menu. Why? Who decided that accessibility should be the Easter egg hunt portion of the app?

Here’s the thing: a full menu redesign can be necessary. Maybe you’re adding significant new features or cleaning up a messy layout. But before you move or remove something, weigh the cost. For sighted users, productivity dips as they re-learn. For blind and low-vision users, it’s disorienting because we often rely on exact menu placement or consistent keystroke sequences.

And let’s talk about removing features. Often, features get cut not because they weren’t useful but because they weren’t visible. Users couldn’t find them. Clarity beats deletion almost every time.

Here’s another common pitfall: moving menu items around just to drive attention to new features. If your users aren’t finding a feature, the problem isn’t that your menu is “too familiar.” The problem is your UX design. Infuriating people by moving familiar tools to force discovery of new ones makes the change look arbitrary, even manipulative. If you have to reshuffle the whole kitchen just to get someone to notice the new blender, maybe it’s time to rethink the floor plan.

The Productivity Drain of Constant Relearning

If breaking muscle memory feels like wasted time, that’s because it is. Research shows that task switching and relearning can drain up to 40% of productivity (PMC study).

Think about it: every time you shuffle menus, users burn cognitive energy re-mapping the interface. For those of us using screen readers or magnifiers, that effort multiplies. Instead of flowing through a task, we’re stuck re-learning how to get to the task.

It’s like swapping your car’s windshield wiper controls with the turn signals. Sure, you’ll eventually adapt, but in the meantime? You’re signaling left every time it rains.

Accessibility isn’t a feature that slows people down, it’s the opposite. Predictability, consistency, and clear pathways save everyone time.

Testing Isn’t Just Closing Your Eyes

Here’s a myth that needs to die: developers testing accessibility by closing their eyes.

I get it. Budgets are tight. Deadlines are tighter. Someone on the team says, “I’ll try it with my eyes closed” and calls it a day. But here’s the truth: if you already know the system, your test is biased. You designed it. You know exactly where things live. That’s not accessibility testing, that’s role-playing.

Accessibility compliance officers aren’t the solution either. Having someone on staff who knows a little bit about every disability doesn’t replace lived experience. To truly understand the needs of blind or low-vision users, you need blind or low-vision people on your dev and QA teams.

And let’s not forget alt text. In apps like Twitter/X or Instagram, accessibility features shouldn’t be hidden several layers deep. Alt text should be visible, easy, and encouraged. It doesn’t need to be mandatory, but it should never be buried. Accessibility becomes easier to implement when companies stop hiding the tools.

Here’s a simple truth: if you want your product to serve everyone, you need the voices of everyone in the room. Hire blind coders. Partner with organizations like the American Council of the Blind (ACB) or National Federation of the Blind (NFB). These aren’t “nice-to-have” steps. They’re the difference between “good enough” and “excellent.”

Otherwise, you’re basically asking someone who doesn’t speak Spanish to proofread your Spanish menu.

Websites: Pop-Ups, Dark Patterns, and Missed Opportunities

Let’s talk about websites, the playground of both brilliant accessibility and some of the worst design sins imaginable.

I know monetization matters. Ads keep the lights on. But those full-screen pop-ups that block everything, forcing you to hunt for a tiny “X”? That’s not clever. That’s user abuse. And when the “X” is deliberately placed in a random spot, that’s not design, that’s a dark pattern.

Fake “X” buttons meant to trick people into clicking the ad? Dark pattern. Web pages that reload every few seconds so the ads shift the page, forcing users with magnifiers or screen readers to lose their place? Dark pattern. And if your site deliberately breaks screen readers, like Amazon’s Kindle app for Windows, congratulations, you’ve gone beyond inconvenience into hostility.

Here’s a radical idea: the close button should be in the same place. Always. Set a standard. If users know where to look, they won’t leave your page frustrated.

Now let’s talk images. “Image description not available” isn’t just annoying, it’s a missed opportunity. Adding alt text doesn’t only serve blind users; it boosts SEO, improves engagement, and builds loyalty. For photographers and visual artists, alt text is a chance to add depth and context to your image. For memes, alt text makes the joke accessible to everyone. Blind people like memes too, and no, our screen readers can’t always OCR your impact font.

Accessible websites don’t shrink your audience. They expand it. And here’s the kicker: they’re often easier to use for everyone.

Quick Checklist for Web Developers:

• Add descriptive alt text.
• Keep navigation consistent.
• Use logical headings.
• Test with a screen reader.

It’s not rocket science. It’s just good design.

Hardware: Accessibility Out of the Box

Accessibility shouldn’t stop at websites and apps. Hardware matters too.

Start with packaging. Some companies design their packaging to be “an experience.” Tabs, loops, layers of tape, flaps glued shut, it’s a circus. Great for YouTube unboxing videos, terrible for someone trying to open the product in real life.

Here’s my suggestion: corporate responsibility. Companies that make packaging accessible will see loyalty from blind and low-vision consumers. Want to know if your packaging works? Hand it to a blind person who’s never seen your product and ask them to open it. You’ll learn more in five minutes than in a week of brainstorming.

Now think about manuals. Put a QR code on the box that links to an accessible version online. Easy, inexpensive, and helpful for everyone.

Menus in devices? Add speech technology. It’s cheap, and it’s transformative. There’s no reason a microwave, thermostat, or washing machine should require sighted assistance to use.

And don’t forget readability. High-contrast colors and clean fonts benefit everyone. Those faint gray letters on a white background might look trendy, but they’re a nightmare for people with low vision  ,  and honestly, a strain for everyone else too.

Building Accessibility Muscle Memory on Dev Teams

Accessibility isn’t just about empathy, it’s about practice.

Want your team to build better accessible products? Make them live it. Have your engineers code with the monitor off while using a screen reader. Have your game designers play with audio cues only.

This isn’t punishment. It’s education. When developers work with accessibility tools every day, they understand the friction points firsthand. And here’s the best part: in trying to solve those friction points, they often discover innovations that improve the product for everyone.

Accessibility Included, Not Bolted On

Here’s the truth: accessibility doesn’t have to be first. But it must be included.

Too often, accessibility is treated like an afterthought, a box to tick in the final sprint before release. That’s how mistakes slip through. That’s how users get burned.

When accessibility is part of the design process from the start, it doesn’t derail deadlines. It doesn’t blow budgets. It simply becomes another part of building a good product.

And the payoff? Loyalty. Blind and low-vision users talk. We recommend the products that support us. We spend money with companies that value us. This isn’t charity. It’s good business.

The Knock-On Effect: Better UX for Everyone

Accessibility isn’t just about disabled users. It’s about universal usability.

Curb cuts were designed for wheelchairs, and now parents with strollers, travelers with rolling luggage, and delivery workers all benefit. Closed captions were for the deaf community, and now they’re indispensable for language learners and commuters watching videos in noisy environments.

The same applies in digital design. Consistent menus, descriptive alt text, predictable close buttons, these aren’t “extras.” They’re improvements that serve everyone.

Design for the margins, and you strengthen the middle.

A Friendly Challenge

So, here’s my ask: before you move that menu, bury that option, or redesign for the sake of “freshness,” pause. Ask yourself: Why?

If the answer is to make life easier for your users, fantastic. If the answer is just “because,” then maybe the forks don’t need moving after all. And if the reason is to push attention toward a shiny new feature? That’s not always justification either. If people can’t find the feature, that’s a design issue, not a user issue. Fix the design, don’t punish the user.

Unnecessary change is a productivity tax nobody asked for. Accessibility isn’t a luxury, it’s the foundation of good design.

So, let’s keep building products that work for everyone. Let’s stop treating accessibility like an afterthought. And maybe, just maybe, let’s keep the forks where we left them.

Until our next adventure, design boldly, and design for us all.