From Compliance to Commitment: Our Journey Toward Accessibility by Default
Our journey toward becoming an accessible by default product company began with pragmatism.
We started our road towards accessibility from a sales perspective — we had requests for proposals (RFPs) requiring accessible products. What initially looked like a box to tick for commercial reasons quickly became something more meaningful. What started with a financial goal in mind soon turned into ‘let’s do the right thing.’
Like many organisations, our early accessibility efforts focused on compliance. We achieved WCAG 2.0 certification for two products and began introducing features aimed at inclusivity. One example was within KINTO Ride, our ride-booking app, where users can specify additional needs — such as requesting a Wheelchair Accessible Vehicle — directly as part of the booking flow.
These steps towards progress were great, but they also exposed a limitation.
We realised that retrofitting accessibility after development was not enough for the future we wanted to build. Accessibility treated as a final checkpoint inevitably leads to compromises, rework, and missed opportunities. Certificates can be reassuring, but they can also be misleading — suggesting that a product is “done” when, in reality, accessibility is never truly finished.
Shifting the Mindset
Becoming accessible by default requires more than meeting checklists; it requires a fundamental shift in how teams think and work. Our goal evolved into embedding accessibility from the very start of product development — so inclusion is considered from day one, not discovered through testing weeks or months later.
This shift is not without challenges. Accessibility work rarely delivers immediate, visible results, which can make any upfront investment in time and effort feel hard to justify. To address this, we formed an accessibility council, with early support from our CEO, Patrizia Niehaus.
That leadership endorsement is helping to set expectations across the organisation and reinforce that accessibility is not optional or ‘nice to have,’ but part of how we build products. The council has a clear purpose: to explore how accessibility could be integrated into our processes from the outset, and to anticipate resistance and practical challenges before they became blockers.
Just as importantly, the council helps establish a more nuanced view of accessibility. We will be careful to avoid a rigid, one-size-fits-all interpretation of Web Content Accessibility Guidelines (WCAG). Not every checkpoint is relevant to every product. For example, in the KINTO Ride driver app, drivers use their phones mounted on dashboards — making landscape mode support unnecessary. Recognising these contextual realities can allow teams to focus on meaningful accessibility outcomes, rather than simply chasing compliance.
Learning Through Practice
For engineering and design teams, the learning curve was real.
Sasa, our Android Tech Lead, recalls confronting the first accessibility audit. “The results of our first application accessibility testing were not great,” he says. “The team was overwhelmed with the number of issues raised and didn’t always understand their importance.”
Get Polly Taylor’s stories in your inbox
Join Medium for free to get updates from this writer.
That initial shock, however, became a turning point. As the team became more familiar with accessibility principles — and, crucially, with how improvements directly help people with access needs — something changed. “The dev and design teams really stepped up and put a lot of effort into resolving what was reported,” Sasa explains. “The most important outcome was the change in mindset. Accessibility is now an integral part of our refinements and tickets.”
Some challenges were entirely new. “Navigating through the app using an external keyboard was a big one,” he notes. “We hadn’t used that at all before, so we had to adjust both design and code to resolve it properly.” What once felt like edge cases are now part of everyday development thinking.
On the iOS team, Filip experienced a similar evolution. “When you have no prior experience, accessibility can sound scary,” he admits. “But once you dig into it, it’s not that hard — though it can be time-consuming.”
He also highlights the complexity of accessibility standards in practice. “Sometimes our testing provider reported bugs that are actually how accessibility is designed to work,” he says. In those cases, he found himself demonstrating how Apple’s native apps behave or explaining how accessibility should be tested. “There are standards, but there’s also a lot of subjectivity. Understanding the platform conventions is just as important as following the rules.”
Designing for Real Use
Accessibility also reshaped how we think about design systems.
Daniele, UX lead for KINTO Zero, describes how colour accessibility moved away from abstract labels and toward real usage. “Colour accessibility is defined by the contrast ratio between a foreground and a background,” he explains, “so it only applies when those roles are clearly defined.”
Early attempts to mark individual colours as “accessible” or “not accessible” proved unreliable. Light tints will always fail on white backgrounds, and dark shades will fail on black. Instead, the team focused on how colours are actually used. Primary colours for text, brand, and core UI elements were tested against both white and black backgrounds in light and dark modes, with accessibility validated at the component level.
Clear rules emerged from this approach. Components with light backgrounds never use light tints for foreground elements; dark backgrounds never use dark shades. Buttons are a clear example — the fill acts as the background, the label as the foreground, and the contrast is tested accordingly.
At the same time, the team acknowledged nuance. “Not every state is required to be accessible,” Daniele notes. Disabled components are intentionally low contrast to signal non-interactivity, and hover states are transitional by nature. Accessibility, here, is about clarity and intent — not rigid perfection.
An Ongoing Journey
Today, accessibility is no longer an afterthought or a compliance exercise. It is an ongoing journey — one that requires continuous learning, thoughtful application of guidelines, and constant reflection.
We know that a certificate does not mean the work is done, and a clean statement does not tell the full story of effort behind it. What matters most is the mindset shift: building products that consider diverse needs from the very beginning.
We’re excited about the steps we’ve taken so far — and aware that there is still much to learn.
What challenges is your organisation facing on the road to accessibility by default, and how are you working to overcome them?
