As part of Europe’s ongoing commitment to digital inclusion, the European Accessibility Act (EAA) officially entered into application across the EU on June 28. One of the key measures introduced by the EAA is the Web Accessibility Directive, aimed at making digital content and services more accessible to everyone—regardless of ability or circumstance.

Web accessibility ensures that all users, including people with disabilities, can perceive, understand, navigate, and interact with websites and mobile applications equitably and independently.

Understanding that people with disabilities should be able to fully interact with our clients’ digital and physical environment, Sopra Steria Bulgaria’s testing team was prepared and ready to make web and mobile apps more accessible to all.

In this article, we highlight the work of Dilyana Traikova, one of our QA specialists, who led an accessibility testing project focused on enhancing a mobile application for both Android and iOS platforms.

“I will address some aspects of what I have learned over the past 8 months. Here I intend to cover how one mobile banking app (used by millions of people) went from completely inaccessible to accessible by the AA standard.”

Testing specifics learned the hard but proven method by trial and error.

At Sopra Steria Bulgaria, we were tasked with transforming a mobile banking app. It has critical components, and we had no other choice but to produce an error-free, barrier-free application that can be relied upon by millions of end users.

Native and web elements

The mobile banking app that we took to transform is a hybrid app composed of both native and web elements. When we started testing, this hybrid setup proved to be a problem for screen readers. When switching from native to web component, focus was lost or focus was not going to the top of the web component as expected. In the case of accessibility for Android app screens, the situation was slightly better, especially after the recent changes made by Google regarding accessibility.

German language word length

Even at maximum font size, Android native elements could match on the screen without losing content, but web elements could not. This affected especially the longer words in the top bar/header, which were cut off in some places and on a smaller phone screen. It was partly due to the operating system itself, partly to the words in German, which can be long and cannot be replaced by synonyms. When reversing the language on the mobile Banking app from German to English, the same elements would come out completely fine even when the font was maximized. As a solution, we made the English version fully accessible and the German version well understood. We addressed the specifics of the long German words by making them read by the screen reader, whereas for the non-screen reader users the text displayed was enough to be understood.

Because of accessibility, we had to make changes. These changes led, in fact, to brand-new functions

The layout was changed

When we started working, the application worked only in portrait layout. Even if the automatic orientation was enabled on the phone, the app remained in vertical format. For these reasons, we had to undertake a layout change to enable both portrait and horizontal layouts. Because of this change, we had to test the behaviour of all parts of the app when changing formats, and we also tested on various physical Android and iOS devices.

During the testing, we also used the Webmate tool. This tool was made to test for accessibility a few months ago, and I was impressed by its adequacy. There are limitations, but it gives an overall good idea of the test metrics. Given all means for testing, we still prefer to use actual physical phones and tablets in our tests. Merely for the possibility to combine cross-testing for accessibility and other tests, such as low battery, internet disconnection, screen lock, dropping the phone with screen readers on, etc.

The security function was extended

The app would close automatically after 5 minutes of no activity on the screen for security reasons. During testing with a screen reader (set to read at medium speed) on a page with longer text, even though I navigated with my fingers on the page to move from item to item, the app closed automatically. On iOS, after closing, the screen reader stopped reading mid-sentence, and on Android, it continued to read the text that was in focus before closing. The problem was that with the screen reader turned on, finger movements on the screen were not recognized as movements, i.e., with the screen reader turned on, the code did not work as expected. After raising an accessibility bug, we did two things, and I think this had a major impact on how it used to be before. This function also led to an accessible UI design that enhances the experience of all users.

1. Firstly, the code was changed to recognize screen activity when the screen reader is turned on. This prevented the app from closing. Now, the users have enough time to go through all the items on the page and are not limited to 5 minutes anymore.
2. Secondly, we had to develop a new message screen that appears one minute before the automatic closing and warns the users. This window gets focus as soon as it appears on the screen and is read by the screen reader with priority. People have the option via an active button to confirm staying in the app and extend the session, or not. We did this because of the requirement for people to get information about what's coming up, as well as being able to confirm or decline.

Extended description on elements

In the app, there are two types of menu items: to call up and to expand. This information was not communicated. It must have been clear to screen reader users what was happening while they used the menu. For example, for some interactive elements of the menu (menu options to be selected), only the label and the note “double tap to activate” were read aloud. The users of screen readers were not told which role (link, button, drop-down list, etc.) was involved. After raising a bug again, now the screen reader has more items to recognize and to read, and makes the menu entries much clearer, for example:

Before: Bank transfer- button

Current: Bank transfer – button- not selected / selected - list available

In Android (Kotlin), for example, the current status can be set by using semantic modifiers:

And last, how critical elements are made barrier-free for all users

During the transformation of the app into an accessible app, our accessibility testing efforts were primarily focused on optimizing screen reader compatibility. Special attention was also given to key accessibility features such as zoom functionality and external keyboard support—critical elements in ensuring a barrier-free interaction for all users. As a result:

The tests on Android with the external keyboard + screen reader on: passed.

The tests on iOS with the external keyboard + screen reader on: partially passed.

Quality testing on Android devices, with both screen readers and external keyboards enabled, yielded successful results. On iOS, however, while tests with the screen reader and external keyboard combination were partially successful, a lot of elements lost their focus, and even the color contrast was lost when testing only with the external keyboard - indicating gaps in accessible design implementation. Interestingly, Android outperformed accessibility for iOS apps in maintaining navigability and focus on native screens under these conditions.

As the Sopra Steria Bulgaria’s testing team, we applied creativity and deep technical expertise to transform a mobile app used by millions from completely inaccessible to fully compliant with the WCAG AA accessibility standard. With our input and experience, we not only improved the app’s usability for all users but also opened the door to future innovations in mobile accessibility.

As awareness and expectations for accessibility-first development continue to grow, we at Sopra Steria Bulgaria anticipate future projects that will lead to further advancements in inclusive mobile design and testing practices.

Technology and Software Development    Career