November 03, 2016   |   9min read

How Polidea Makes Magic For All

Polidea has magic. And our Magic should be accessible to everyone!

From visual impairments to hearing problems, many users will suffer the incapacity to experience in full our mobile apps. But there are many solutions to remedy the problem. And today we would like to present to you some of the main points to instigate a discussion within your teams, as well as with your clients. Because the biggest obstacle to reach a tech-for-all is the lack awareness…Awareness of how easy it is to make magic, available to everyone.

But first, let’s spend two minutes to reflect a little about the topic. Accessibility should always be one of the crucial consideration points among tech builders and thinkers. However, in our extensive experience of building hundreds mobile apps, only a very low percentage of projects included accessibility features. The main reason remained the lack of concrete tools to develop very accessible apps. But for the past two years things changed and the hard truth is, neither the clients or us, were fully aware of the new generation accessibility capabilities. Nor how easy it is to implement.

So finally, when we started a few months ago to re-design our own app store (Shuttle), and had the great freedom of working on our own internal project, apart from deciding on new features and rebranding, our top goal was to build the most user-friendly and accessible app! For most of us this was the first time we could fully dive into the topic of accessibility and merge it into our design process. This is where a great discussion between the members of the project team (made of designers and engineers) started. We have soon realised how much there could be done, and how big was the topic. Of course, our process still requires some improvement, but we are not turning back.

We would like to share with you our magic formula: from brainstorming to testing, from designing to engineering, step after step on how to create a fully accessible mobile app, for all. Easy to be reproduced, important to be always remembered.

What to consider while delivering an accessible application

First of all, we have to recognise that accessibility should be a standard practice, not just a feature. According to iOS guidelines caring for accessibility means providing an extraordinary opportunity to deliver a superior mobile experience to every customer, including those with special needs. Well-designed applications are both more usable and more accessible, so designing for accessibility should be an inherent part of the design process. So let’s treat accessibility as “just the way we do things”. It’s not easy from the beginning, but it becomes addictive because of the great results it brings.

Talked to your clients about it

The first challenge might seem obvious. How to convince our clients that in the process we need some time for including accessibility?

One simple solution: don’t ask your client for opinion if they want to have an accessible app or not, treat it just like the right thing to do, a base rule to follow, and consider it in estimating the timeline and budget of the project. Of course, it’s important to bring up the topic during the client meetings.

Then, if it’s really necessary to convince them, show your clients what is it like to navigate their app with the accessibility mode on. It’s difficult to wear other people shoes and companies often don’t realize what they’re putting their users through by not making products accessible. A quick demo can be very eye-opening

If your clients are STILL reluctant after this discussion, pull the pool-of-users joker from up your sleeve. Clients are usually very sensitive to numbers and how many users they can reach with their app. And here, the statistics speak for themselves, so don’t hesitate to include them in your budget presentation:

It’s important to remember that “we’re all ‘temporarily disabled’ because we’re busy, distracted, tired, or using our hands or eyes for something else. Designing a product to work for every user means it will work better for any user, in every—or at least more—circumstance.

Robin Christopherson

Talk to your team

The next challenge is to educate our teams (designers and engineers!) about accessibility. Sounds a bit patronizing, but that’s the hard truth. Accessibility needs to be built into the core process of the development. Within the very initial phase of your design and development framework. It is also at this moment that you can start planning your team schedule to fit your accessibility efforts.

Implementation itself does not take too much time as it is not really a tedious and difficult task, and does not usually affect general application logic and used design patterns. In most cases it is a matter of setting up some additional parameters used by accessibility mechanisms (like VoiceOver).

We will not say it often but: plan it from the beginning. It’s much easier to implement accessibility labels in the first phase of the development process. For example working on iOS, the designers need to decide whether they’ll use a custom or system fonts. System fonts automatically react to accessibility features. Apps using custom fonts should implement the same behavior. Pay attention to how does the text behave after enlarging the text size in settings. When it’s interrupting the interface you should make some space for it and make the elements responsive.

Estimate the cost

One common biased guess made by many app studios is that accessibility is costly. Well, of course it is not free (hopefully maybe one day). But a lot of your budget will depend on how many custom fonts you want to use and make dynamic in your app. There are generally two different approaches to tackle the problem. First one is definitely cheaper and more robust, but less flexible. It is based on asking the system of the size of the system font with a given style and then applying it to a custom font. Pay attention to the point size, leading and tracking, the weight may be defined according to your design. The sizes are provided in the documentation and shown in the table below.


By using it you can check how will a text labeled as a “Title 3” behave when user will reach for larger text size and this way you can prioritize the content. When someone chooses a larger size, they want to make the content they care about easier to read; they don’t always want every word on the screen to be larger so you can also decide what texts shouldn’t be dynamic.

Second approach is similar but differs from the first one by the fact that the size of the font for the given style and weight have to be defined by the programmer. This requires much more work but gives us more flexibility. However, it is also more likely to make errors using this approach, so the end result has to be tested for all possible font sizes.

Define types

Given the above it’s important to define types in design at the beginning of the process. Designers have to limit various text styles and be consistent in using them. This way they don’t have to take extra time for accessibility because in every project there is time to focus on types.

This is how the types behave in our Shuttle app for iOS.


Visual design – buttons, fonts, colours, contrasts

Accessibility often refers to the good practice of product design. According to material design guidelines for accessibility here we should simplify our app’s UI with:

  • Clearly visible elements
  • Sufficient contrast and size
  • A clear hierarchy of importance
  • Key information discernable at a glance

Develop Accessible (or how to prepare the application for system tools such as voice over)

Accessible development – preparing the application for system tools such as voice over While designing interaction and interface designers should remember that each of the features and elements should be accessible for everyone. Of course, considering the target group of the product it might be necessary to make some exceptions but still, they should be exceptions and not simply ignorance.

For the user’s sake pay attention to: complex screens—Screens that are complex are difficult to navigate with ZoomText, especially if it is hard to see the boundaries of each zone. autorefreshing information—Screens or pages with a lot of automatically refreshed data or updating sections—even if their coding conforms well to ARIA standards—can be difficult or impossible to use effectively with a screen reader. distracting elements—Cluttered screens often have distracting elements that make them harder to use for people with cognitive or learning disabilities.

All of the points mentioned above also significantly affect the general usability for people without disabilities, though not as severely. The more crowded or complex the screen is, the harder it is to understand it and learn to use it effectively. Just as making difficult decisions about priorities for a mobile user interface can pay off in a much better Web version of an application, designing for better accessibility can make a product more usable for everyone.

During development of Shuttle we decided to define accessibility labels from the very beginning of the development process. We created a Google spreadsheet with screens from the app and columns dedicated for: text, text ID, label, hint, trait (for iOS) and content description (for Android). It took some mistakes to make it work. At first it turned out we tried to label too much and the voice over was reading the same things couple of times like: “Authorize. Authorize button. Double tap to authorize.” We had to test it in the early stage of the project and evaluate it a couple of times to make the voice over work well. There were more things that needed a greater evaluation. For instance, we also started looking in a different way on features which are convenient only to power users. For sure those features make the app feel smart and modern but sometimes they are just not accessible to everyone. For example, we changed from „Swipe to delete” to „Long press to delete”. This way we used the same interaction as the users know from deleting an app on iOS and we added a hint “double tap and hold to see actions”. Those are just some examples, but once you immerse yourself in the process, you can see how much potential there is to improve your products following the accessability guidelines.

And the most important!

And the most important! Invite disabled end-users to test your app! Because that remains the first rule to build a super-app, and one which is accessible too. However, this was the hardest phase to put in place. Only now, and months deep in our Shuttle development process, we managed to gather a relevant focus group. And it is only because we started to talk about our efforts loudly at Polidea (and outside), and because we reached out directly to people affected by physical impairments, who were willing to help. So never feel defeated if you have to face many refusal, at some point you will find a charitable soul willing to help you.

So be loud about it! Because that’s magic which truly matters.

Rafał Tulwin

Senior Software Engineer

Agnieszka Czyżak

Creative Director

Magda Rydiger

UI Designer

Did you enjoy the read?

If you have any questions, don’t hesitate to ask!