Impact Over Perfection: How We Pragmatically Integrate Accessibility into Software Development

In theory, it always seems so straightforward: software that’s accessible from the very start. But as soon as you take a look at the WCAG (Web Content Accessibility Guidelines), it turns out to be more complicated than expected, and you quickly feel overwhelmed.

When time and budget are already tight during a sprint, accessibility often gets pushed to the roadmap as an afterthought for “sometime after the release,” where it then gathers dust. And because the bar for flawless implementation is set so high, the first step gets completely left behind.

At Bitforge, we work every day within precisely this reality, shaped by tight constraints. We build real projects—often as MVPs (Minimum Viable Products)—of varying sizes and under tight deadlines, usually entirely in-house. Drawing from this experience, we’ve developed a philosophy that we carry with us like a mantra: “Impact over Perfection.” Pragmatism trumps perfectionism. Every small, well-thought-out improvement immediately provides tangible benefits for real people. Continuous progress is infinitely more valuable than waiting in vain for flawless, 100% compliance.

A common misconception is that accessibility is a niche topic for a vanishingly small minority. As long as accessibility is viewed as a burdensome, after-the-fact addition or merely a legal formality, it will continue to be neglected.

We need to move away from a rigid checklist mentality and toward a genuine shift in mindset: Accessibility is not an optional feature, but an integral part of product and core quality. It improves the everyday experience for everyone. After all, each and every one of us benefits from accessible design in everyday situations:

Direct sunlight: When you’re standing by the lake at noon trying to buy a ticket on your smartphone, you absolutely rely on strong contrasts.

On the bus: Anyone trying to read content on a bumpy commuter train suddenly appreciates the ability to zoom in on the screen easily and smoothly.

One-handed operation: Whether you’re carrying a shopping bag in one hand or holding a child—an app that’s consistently designed for intuitive one-thumb operation will save your day in that moment.

What does this pragmatic approach look like when dealing with an existing, mature system? A prime example of this is our ETH Tours project.

The Starting Point

The app was already live and functioning well in everyday use. The problem: During the initial development, digital accessibility simply wasn’t consistently taken into account. We quickly realized that accessibility is not an isolated UI issue, but rather one that deeply affects the entire system—from navigation and editorial content to audio elements.

To break down this complex system in a structured and tangible way, we used the four core pillars of the WCAG as our guide and implemented them pragmatically:

Perceivable (Perceivable)

Content must not be presented in just one way, but must be accessible to users’ senses. That’s why we’ve integrated complete text transcripts into the audio tours for ETH Tours. So anyone who can’t hear or has forgotten their headphones in a noisy environment can simply follow along with the tour in another format.

We’ve also ensured that the invisible labels for screen readers (such as Apple’s VoiceOver) make real sense. Instead of cryptic fragments, the system now reads aloud exactly what the eye sees: “Science is female. ETH Hönggerberg. Button.” At the same time, the color schemes have been adjusted so that they are visible in every

Operable

Users must be physically able to interact with the user interface without difficulty. After all, people walking around campus are looking at the buildings, not staring at a screen the whole time. To make interaction extremely easy, we designed the central control elements—such as “Back” and “Next”—as large, unambiguous interactive areas.

Understandable

The product must be understandable and must not create any unnecessary cognitive load. The focus here was on reducing complexity and significantly increasing clarity. A key component of this was the inclusion of directly accessible accessibility features in the app settings. There, users can enable specific options—such as “Route Without Stairs,” “Audio Transcript,” or “Video Captions”—with just one click.

Robust (Robust)

An app is only truly robust from a technical standpoint when it works seamlessly with assistive technologies. We have refined the code semantics so thoroughly that the native OS accessibility settings of iOS and Android function seamlessly and without errors.

While the ETH project was a classic retrofit, the app for the Caritas Market offered the opportunity to firmly embed accessibility from the very beginning.

The Challenge

The project came with maximum constraints: an extremely small team, a tight budget, and an uncompromising timeline of just 3 months for development. At the same time, the Caritas Market serves people living in poverty, among whom there is a statistically disproportionately high number of individuals with health, cognitive, or age-related limitations. Accessibility here was not an option, but an absolute necessity.

The Pragmatic Approach

How do you achieve this with such minimal resources? By taking a strategic approach from the very beginning and closely integrating design, development, and implementation. Our most important strategy: From day one, we consistently designed the entire product for a 200% text zoom level.

The Result

This radical approach paid off completely. No matter how large the font is set in the smartphone’s global system settings, the layout never breaks. No overlapping text, no disappearing buttons—on the recipe and “Weekly Highlights” screens, everything remains fully usable and visually clean.

The Seal of Approval

This focused, highly efficient approach did not go unnoticed by the expert jury of the Swiss app community. The project, commissioned by the Caritas-Markt cooperative and developed by us, was awarded the gold medal in the special “Accessibility” category at the prestigious Best of Swiss Apps (BOSA) Awards. This is crystal-clear proof that award-winning accessibility doesn’t require huge budgets—just the right focus.

Through our projects, we’ve learned a lot about the dynamics of teams when it comes to accessibility. Here are our unfiltered insights from real-world experience:

What Really Works

Don’t guess—test: We stopped speculating about whether a design was accessible and instead consistently activated screen readers and used the apps ourselves in a “blind” manner.
Focus on visual structure: A clear, logical arrangement of elements already eliminates a huge portion of all potential cognitive barriers.
Experience over nitpicking the rules: The most important thing was to focus on the actual user experience, rather than getting lost in abstract sections of the guidelines.
Collaboration with affected experts: You can’t talk about accessibility without involving the people directly affected in the project. Only those who rely on assistive technology every day can judge whether the user experience actually works in everyday life.

What held us back

Trying to solve everything at once: Attempting to immediately build the perfect 100-percent solution for every conceivable extreme case inevitably leads to a dead end.
Over-engineering: Developing overly complicated custom technical solutions consumes valuable resources. Often, clean, simple standard syntax is entirely sufficient.
Lack of ownership: If accessibility is simply treated as a general task, no one ultimately feels responsible for it. It requires

If you’re heading into your team meeting tomorrow and want to finally get the ball rolling on accessibility, forget about manuals, tools, or checklists. Instead, start right away with your projects using this compact framework:

Contrast: Check the color contrast of text and buttons to ensure optimal readability.
Structure: Establish a logical, visual hierarchy in your layouts.
Touch targets: Make interactive elements large enough (rule of thumb: at least 44 x 44 or ideally 48 x 48 pixels) so they can be easily tapped with one hand while walking.
Labels: Name buttons and icons in the background in a way that’s unambiguous for screen readers.
Test: Enable the assistive technologies yourself and test the app directly in real-world use.

The 5-Minute Self-Test for Your Team

Try a quick experiment at your next internal meeting: Set your smartphone’s text size to 200% zoom, close your eyes, activate the built-in screen reader (VoiceOver on iOS or TalkBack on Android), and work together to use a core feature of your own app for five minutes.

The insights gained from these five minutes will permanently change how you view your product.

Perfectionism is the greatest enemy of progress. Those who wait to implement perfect, error-free, and comprehensive accessibility ultimately ensure that people with disabilities continue to be shut out of the digital world.

Get started. Take action. Don’t try to do everything at once, but whatever you do, don’t do nothing. At the end of the day, accessibility isn’t a burdensome add-on—it’s simply the foundation for an outstanding user experience that benefits every single user, without exception. Even those who don’t rely on assistive technologies.

Would you like to run an accessibility check on your app or set up a new digital project to be smart and inclusive right from the start? Contact us and let’s work together to make accessibility a reality!