I still remember the first time I saw someone using VoiceOver on an iPhone. It was years ago, not long after Apple’s touch-screen revolution took hold. I was riding the subway in New York City when I noticed a fellow passenger tapping on their phone in a way that felt almost rhythmic, with a screen reader rattling off text at speeds I could barely follow. At first, I didn’t fully realize what was happening. But once it clicked that this person was visually impaired and adeptly navigating their phone using Apple’s built-in accessibility features, I was floored. It was a reminder that the technology we build doesn’t serve just a subset of people—it has the power to connect, enable, and empower all of us, regardless of physical or cognitive abilities.

That moment stuck with me, and over my years working at MartianCraft, I’ve returned to it as a guidepost whenever I start planning a new product. Because, if I’m being honest, it’s all too easy as developers and designers to zero in on “standard users”—who are typically abled, sighted, hearing, and operating in fairly typical environments—and forget that our apps can reach a much wider audience. And that audience deserves a first-rate experience too. Accessibility, for me, isn’t about ticking a compliance box or avoiding a lawsuit. It’s about genuinely wanting my software to be welcoming and intuitive for anyone who might benefit from it.

Now, Apple’s done a lot of heavy lifting in the accessibility arena, from VoiceOver to Dynamic Type and beyond. The frameworks and guidelines are there, waiting for developers to implement them. The question is whether we’ll go beyond the minimum requirements. Are we content with “it technically works with VoiceOver,” or do we push further, optimizing every interaction so that those using assistive technologies feel like first-class citizens of our apps? If you’re looking to answer that question with a resounding yes, then I’d like to share a few ways we’ve found at MartianCraft to go beyond compliance and make iOS apps that genuinely shine for everyone.

I want to start with a simple premise that’s become almost a mantra around here: Accessibility improvements make your app better for all users. The truth is, an accessible design is inherently more legible, more logically organized, and more considerate of varied usage conditions. Take Dynamic Type, for instance. Sure, enabling it means that users with visual impairments can crank up their font size without the text running off the screen or overlapping other elements. But it also benefits someone rushing to check their phone in bright sunlight, or that parent with bleary eyes late at night who hasn’t put on their reading glasses. By supporting Dynamic Type, you ensure your UI flexes for any scenario. We often see that once we integrate accessibility properly, we get fewer design- and layout-related bug reports from the entire user base. It’s a testament to how robust apps become when we aren’t coding purely for a single narrow set of device and user constraints.

VoiceOver, too, yields hidden advantages. When you properly label your UI elements, establish the correct reading order, and ensure that interactive components have descriptive hints, the app’s entire structural logic tends to become clearer. You begin naming elements in a more thoughtful, self-descriptive way. That means code is more maintainable because every button, toggle, and text view has a consistent naming convention—no more “button123” that no one recalls the purpose of. Plus, it’s not unusual for testers or developers to rely on VoiceOver checks for quick scanning of an interface. I’ve personally encountered minor issues—like incorrectly linked elements or mislabeled graphics—that would have slipped through if I hadn’t run a VoiceOver pass. If you let these best practices guide you, your code and design come into alignment around a shared principle: clarity.

Of course, the best technology in the world won’t save an app that’s conceptually hostile to accessibility. I’ve seen apps, for example, that show crucial data in a graph with no text alternative. If you happen to be blind or have a visual limitation, the app is functionally useless. It’s not enough to say, “Well, we have alt text in the code.” If the design approach relies purely on color or shape to convey critical information, you’re missing the point. Proper accessibility means you’re always asking, “How else can I represent this data?” Perhaps it’s textual summaries, or a table view of the underlying metrics. My rule of thumb is that if a user can’t glean the same essential insight from a text-based or spoken alternative, there’s an accessibility gap we need to close.

There’s a thread here I want to tug on: color and contrast. Apple provides guidance for color contrast ratios in iOS, ensuring that text is sufficiently distinguishable from its background. But you’d be surprised how often teams forget this, especially when brand guidelines come into play. Branding might call for a certain shade of pastel or a sleek gradient, but if it yields pale-gray text on a near-white background, many users will struggle to read it, including older adults or anyone trying to read on a screen angled toward a bright light. We frequently push back when brand colors fail contrast standards, suggesting either a secondary “accessible palette” for the app or slight tweaks to hue and brightness that preserve brand identity while hitting that sweet spot of readability. Users shouldn’t have to strain or adjust their phone’s brightness just to parse a single sentence on the screen.

And then there’s the matter of motion and animations. I love a snappy animation as much as anyone—it brings a sense of delight to your app’s transitions. But some animations can be disorienting or even nauseating for users with vestibular issues. iOS offers a setting called “Reduce Motion,” and it’s important that your app respects it. Sure, that swirl effect when a view loads might look cool, but if it causes a subset of your users to avoid your app, is it worth the style points? The same philosophy applies to parallax effects or heavy motion in gaming interfaces. When we incorporate animations, we should ensure those animations degrade gracefully when a user indicates they need less motion. Again, that’s a scenario where your design gets sharper for everyone: When you remove gratuitous motion or ensure alternatives, you’re giving power to the user to shape their own experience.

One of my favorite ways to keep our team honest about accessibility is to incorporate automated checks during development. Apple’s Accessibility Inspector is a powerful tool that can quickly scan your interface for common pitfalls: missing labels, improper contrast, or invalid element hierarchies. While it’s not a substitute for real human usage, it can catch plenty of mechanical oversights. We build these checks into our QA processes so that they aren’t an afterthought but a routine part of verifying each release. Our testers also regularly use VoiceOver or other assistive technologies to navigate the app as though it were their primary method. This approach forces us to confront friction points we might otherwise never notice. If, for instance, a VoiceOver user has to swipe seven times to skip a decorative image and finally reach the main content, we realize we’ve forced them into a frustrating path. So we either make that image non-focusable or rework its reading order to better reflect its importance.

A concept that’s garnered momentum is designing for situational impairments, not just “permanent” disabilities. Imagine a user in a loud coffee shop who can’t hear your app’s audio cues or a user with an arm in a cast who’s temporarily operating their phone one-handed. It’s a fresh way of thinking about accessibility that acknowledges all of us can be “disabled” by our context. The same design considerations that help a Deaf user parse visual cues can help someone who simply can’t listen to audio at that moment. This principle of “design for one, extend to many” is how inclusive design becomes universal design, and that’s a gift to every user who picks up your app.

One question I’m often asked is: How do you convince clients or stakeholders that accessibility is worth the investment? The compliance argument, while valid, seldom inspires teams on a deeper level. We can talk about ADA regulations or the risk of legal action, but that usually results in the bare minimum. Instead, I like to frame it in terms of audience reach and brand perception. When you demonstrate that your app is a pleasure to use for everyone, including those with disabilities, you send a message of inclusivity and quality. It’s a strong brand differentiator. Users—disabled or not—tend to favor products that demonstrate care and attention to detail. By championing accessibility, you gain loyal customers, reduce churn, and often see positive word-of-mouth. Plus, you open doors to markets (including enterprise or government sectors) that mandate certain accessibility standards for the software they procure.

I also encourage a culture of empathy in the development process. If someone has never experienced trying to use a phone with limited sight, let them. Encourage them to turn on VoiceOver for a day or invert colors or enlarge the text to the maximum size and see how quickly the interface breaks if you haven’t planned for it. At MartianCraft, we’ve run internal mini-workshops where designers and developers role-play different impairments—such as color blindness or hearing loss—to see how the app’s experience shifts. The initial reaction is almost always, “I had no idea how hard it would be to do even simple tasks.” And that “aha!” moment usually triggers a wave of improvements, because once you feel the frustration firsthand, you can’t ignore the importance of addressing it.

From a purely technical perspective, iOS accessibility isn’t complicated to implement. Apple’s frameworks are straightforward, and the official Human Interface Guidelines provide step-by-step instructions for labeling UI elements, supporting larger text sizes, and respecting user preferences for reduced motion. The real friction happens when teams treat accessibility as a post-launch add-on. If your entire interface is locked in place, with no thought given to how text should reflow or how a user might navigate via VoiceOver, you’re setting yourself up for a scramble—and possibly half-hearted solutions that fix only the top-level issues. The better approach is to incorporate accessibility from day one: define color contrasts, test your wireframes in high-text-size modes, talk about VoiceOver labels when you’re naming icons, and confirm that animations can be toggled off or minimized if needed. These steps fit seamlessly into modern development workflows when you treat them as fundamental, not optional.

Ultimately, building accessible software is a moral and practical responsibility, but it’s also an opportunity for creative problem-solving. We get to re-examine the fundamentals of how we present data, how we structure user flows, and how we engage the senses. Instead of seeing that as extra work, I view it as a chance to sharpen our design and coding craft. If you’re pushing your product to be more inclusive, you end up with more robust solutions that handle edge cases gracefully. And you’ll likely see dividends in user satisfaction, brand loyalty, and plain old developer pride. Because let’s face it, shipping code that works for everyone is a powerful feeling.

In a perfect world, every new iOS app would go beyond compliance—transcending the “checklist” approach to accessibility and instead embracing a universal design ethic that fosters a sense of belonging for all users. It’s an ideal we’re still working toward as an industry, but each improvement, each incremental move toward inclusive design, builds momentum. Every time I hear that familiar VoiceOver chatter, or see large text scaling beautifully on an iPhone, I’m reminded of why I keep championing accessibility. Because creating software that includes everybody is not just a nice-to-have. It’s the right thing to do. And once you experience how that feels—once you witness the impact of your app on a user who otherwise would have been excluded—you’ll wonder why you ever considered it optional in the first place.