This article was written in collaboration with the following people, who made themselves available for an expert interview: Diane Illi and Patrick Mukherjee (SwissSign), Marcel Belz (MeteoSwiss), Guido Riedweg and Christian Rudolf von Rohr (Well), Sandro Lüthi (Apfelschule).

Websites nowadays are universally made of HTML, JavaScript and CSS (enriched with ARIA if necessary). These languages are standardised and it is the responsibility of the browser manufacturers to implement them according to the specifications. This is something that is proving far more successful than it did in the past. Web standards are undergoing constant development and expansion. The professional web development environment has developed a sense of which functionalities and elements are supported by all browsers. Significant advances in standardisation and the reduction to two core platforms for web browsers – Apple’s WebKit and Google’s Chromium – have made web development much easier. Essentially, in the field of web development, we are close to the ideal of developing a single, unified ecosystem: the ‘web’. This standardisation also benefits assistive technologies such as screen readers, which rely on valid and semantically correct code in the browser.

In the world of mobile apps, the situation regarding a uniform ecosystem is different: there are two completely different platforms, iOS from Apple and Android from Google. Although the two platforms may look similar to the outside world in many respects, behind the scenes they differ fundamentally: different programming languages are used, and while the palettes of standard functionalities and user interface elements have clear similarities, they still have specific characteristics to produce the look and feel that is typical of each platform. In order to offer the same app on Android and iOS, app development must internalise two completely different ecosystems. This means that the same app has to be produced almost twice.

Various programming frameworks promise to minimise this duplication of effort by generating the app versions for iOS and Android from a single source of code. Some frameworks translate their code into the native programming languages of the respective platform; others generate HTML code that can be loaded by both platforms (so-called hybrid apps). The most well-known proponents of such frameworks (e.g. Flutter and React Native) seem to be aware of the importance of accessibility: the apps generated are advertised as being accessible! Either because they are translated into native apps whose accessibility is guaranteed by the operating system, or because a hybrid app is created that adheres to traditional HTML (and ARIA) guidelines. Flutter strikes a balance between the two: the apps are translated into the native code of the operating system, but the framework does not use the operating system’s palette, but ‘paints’ its own developed elements, which, according to the manufacturer, are also accessible. Despite these simplifications, it is still the responsibility of the development team to be aware of the relevant functionalities and to implement them consistently. Even if the translation algorithm of the aforementioned frameworks is said to be very clean and theoretically offers everything an accessibility expert could dream of, this is of little use if the blueprint from which the apps are generated is defective. The old principle applies here: garbage in, garbage out.

And even when designing and programming at the highest level, regular quality assurance is indispensable. Only once the screen reader is launched, the system-wide zoom activated and a physical keyboard connected does it become apparent whether all of the functionalities and elements in an app work together meaningfully. In this respect, accessibility should be firmly anchored in the development process. In order to have regulated responsibilities, positions with clear mandates should be defined within the team. This will ensure that the issue of accessibility is not overlooked during the development cycle.

About the author

Josua Muheim is an Accessibility Consultant at the ‘Access for All’ Foundation. Josua Muheim is a trained application developer. He joined the foundation in 2014 and learned all about accessibility there until 2018. After a few years of travelling and freelancing, he returned to the team in 2023 and is now responsible for training interns.