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.


AgnieszkaLead Designer
MagdaUI Designer
RafałSenior Software Engineer


Sign in and expect sharp insights, recommendations, ebooks and fascinating project stories delivered to your inbox

The controller of the personal data that you are about to provide in the above form will be Polidea sp. z o.o. with its registered office in Warsaw at ul. Przeskok 2, 00-032 Warsaw, KRS number: 0000330954, tel.: 0048 795 536 436, email: (“Polidea”). We will process your personal data based on our legitimate interest and/or your consent. Providing your personal data is not obligatory, but necessary for Polidea to respond to you in relation to your question and/or request. If you gave us consent to call you on the telephone, you may revoke the consent at any time by contacting Polidea via telephone or email. You can find detailed information about the processing of your personal data in relation to the above contact form, including your rights relating to the processing, HERE.

Data controller:

The controller of your personal data is Polidea sp. z o.o. with its registered office in Warsaw at ul. Przeskok 2, 00-032 Warsaw, KRS number: 0000330954, tel.: [0048795536436], email: [] (“Polidea”)

Purpose and legal bases for processing:


Used abbreviations:

GDPR – Regulation (EU) 2016/679 of the European Parliament and of the Council of 27 April 2016
on the protection of natural persons with regard to the processing of personal data and on the free movement
of such data, and repealing Directive 95/46/EC (General Data Protection Regulation)

ARES – Polish Act on Rendering Electronic Services dated 18 July 2002

TL – Polish Telecommunications Law dated 16 July 2004

1)        sending to the given email address a newsletter including information on Polidea’s new projects, products, services, organised events and/or general insights from the mobile app business world |art. 6.1 a) GDPR, art. 10.2 ARES and art. 172.1 TL (upon your consent)

Personal data:name, email address

2)       statistical, analytical and reporting purposes |art. 6. 1 f) GDPR (based on legitimate interests pursued by Polidea, consisting in analysing the way our services are used and adjusting them to our clients’ needs, as well as developing new services)

Personal data:name, email address

Withdrawal of consent:

You may withdraw your consent to process your personal data at any time.

Withdrawal of the consent is possible solely in the scope of processing performed based on the consent. Polidea is authorised to process your personal data after you withdraw your consent if it has another legal basis for the processing, for the purposes covered by that legal basis.

Categories of recipients:

Your personal data may be shared with:

1)       authorised employees and/or contractors of Polidea

2)       persons or entities providing particular services to Polidea (accounting, legal, IT, marketing and advertising services) – in the scope required for those persons or entities to provide those services to Polidea


Retention period:

1)       For the purpose of sending newsletter to the given email address – for as long as the relevant consent is not withdrawn

2)       For statistical, analytical and reporting purposes – for as long as the relevant consent is not withdrawn

Your rights:


Used abbreviation:

GDPR – Regulation (EU) 2016/679 of the European Parliament and of the Council of 27 April 2016
on the protection of natural persons with regard to the processing of personal data and on the free movement
of such data, and repealing Directive 95/46/EC (General Data Protection Regulation)

According to GDPR, you have the following rights relating to the processing of your personal data, exercised by contacting Polidea via [e-mail, phone].

1)       to access to your personal data (art. 15 GDPR) by requesting sharing and/or sending a copy of all your personal data processed by Polidea

2)       to request rectification of inaccurate personal data
(art. 16 GDPR) by indicating the data requiring rectification

3)       to request erasure of your persona data (art. 17 GDPR); Polidea has the rights to refuse erasing the personal data in specific circumstances provided by law

4)       to request restriction of processing of your personal data (art. 18 GDPR) by indicating the data which should be restricted

5)       to move your personal data (art. 20 GDPR) by requesting preparation and transfer by Polidea of the personal data that you provided to Polidea to you or another controller in a structured, commonly used machine-readable format

6)       to object to processing your personal data conducted based on art. 6.1 e) or f) GDPR, on grounds relating to your particular situation (art. 21 GDPR)

7)       to lodge a complaint with a supervisory authority,
in particular in the EU member state of your habitual residence, place of work or place of the alleged infringement if you consider that the processing
of personal data relating to you infringes the GDPR
(art. 77.1 GDPR)

No obligation to provide data:

Providing your personal data is not obligatory, but necessary for Polidea to provide you the newsletter service

Refusal to provide the above data will result in inability to receive the newsletter service.


In the process of providing the newsletter service, we make decisions in an automated way, including profiling, based on the data you provide.


“Profiling” means automated processing of personal data consisting of the use of your personal data to evaluate certain personal aspects relating to you, in particular to analyze or predict aspects concerning your personal preferences and interests.


The automated decisions are taken based on the analysis of clicked and viewed content. They affect the targeting of specific newsletter content to selected users registered to receive the newsletter service, based on the anticipated interests of the recipient.