People often have the impression that the number of people who benefit from digital product accessibility is negligible. The reality is quite different.

Limited digital product accessibility features restrict a huge portion of popularity from using them to order food, use mobile banking, or get a cab.

Furthermore, not caring for digital product accessibility affects not only the permanently disabled but also those with temporary, i.e., situational disability.

Take a broken arm, for example. Those affected can use their phone with only one hand. Next, think about texting on the phone in direct sunlight. Good luck if the messaging app has poor contrast! Or imagine trying to read something without glasses if there is no option for text enlargement. These are all examples of situational disability.

Taking into the context that disability can be temporary or situational, it becomes clear how many people are affected by poor digital product accessibility. This is a lose-lose situation for both users and providers because the user misses out on services and experiences, while the providers lose revenue, reach, and conversion.

But even if companies were okay with losing revenue, digital product accessibility is not optional. Accessibility standards are regulated by law.

In the EU, all government websites and mobile apps have to demonstrate a certain level of digital accessibility. In the US, this applies to every website and mobile app – as a result, more than 2000 lawsuits for inaccessible products get filed every year.

The European Accessibility Act (EAA) that comes into force on June 28, 2025, will require most digital products to conform to Web Content Accessibility Guidelines, level AA.

For a digital product to become truly accessible, appropriate steps should be taken at every stage of the development process. No one person or one team can drive digital product accessibility alone.

For example, there’s no point in achieving good color contrast if a logical focus order is not implemented. Similarly, an app isn’t actually tested if nobody tested the screen-reader behavior.

The accessibility handbook contains our knowledge about digital process accessibility and describes the relevant steps in our development process. Each team provides its domain-specific knowledge in a separate chapter.

Now, let’s look at accessibility standards in a little more depth.

As the World Wide Web grew, standards had to be developed to ensure its long-term growth and the organization in charge of those standards is the World Wide Web Consortium (W3C). Because of its massive popularity, the Web is the first platform that had to incorporate accessibility standards. 

These standards are presented in the Web Content Accessibility Guidelines (WCAG), a part of a series published by the W3C. However, while the WCAG provides a definitive set of instructions for creating accessible websites, which includes mobile and responsive websites, mobile apps are still not covered in sufficient detail. 

If you look into Google and Apple’s design guidelines, you’ll find that they do cover mobile apps and take accessibility into account. However, they mostly include patterns specific to each platform. 

A neutral body like the W3C does not exist for mobile apps and there is no single gold standard like the WCAG, which is why we had to find our own path for making mobile products accessible.

We have been implementing the guidelines in projects that have some of the widest user bases, such as banking and telecom apps.

The digital accessibility principles we implement in our projects are organized in the same way as the WCAG principles. There are three conformance levels across four categories – level A being the minimum level of accessibility in a digital product.

Each of the levels is applied to the four main categories: perceivable, operable, understandable, and robust.

At Infinum, we started our digital product accessibility initiative by finding advocates from every production team. Their first task was to research accessibility principles and guidelines in their domain. However, individual work was not enough. It was crucial to put these advocates together and create comprehensive principles that cover all steps of the digital product development process.

After that, our advocates had workshops with the rest of their teams to incorporate accessibility into their processes. Each team laid out its process in its respective handbook.

Finally, we retrospectively applied accessibility principles to previous projects through accessibility audits.

We believe that digital product accessibility is not just a technical issue but also a social one, and as a socially aware company, we feel a responsibility toward the disabled. The difficulties they meet are often caused by barriers set by society, and it’s up to that same society to remove them.

We have set out on a journey to promote accessibility in the digital world. We will continue to share our approach, knowledge, and best practices about accessibility via Infinum handbooks, Infinum blog, Infinum talks, and other platforms. So should you!