Beginning today, all apps by public authorities are required have an accessibility statement. This statement describes to what extent the app is accessible to people with disabilities. This article explains what app accessibility entails. You will also learn how your organisation's app can soon comply.
In 2016, the European Commission asked all member states to make accessibility mandatory for (semi-)government digital channels. All member states - including Belgium and the Netherlands - have since transposed this directive into local laws and decrees. These apply to all levels of government. Websites have already been required to have at least an accessibility statement since September 2020. From 23 June 2021, this will also apply to new and existing mobile apps.
👉 For a broader look at digital accessibility in government, please refer to the article I wrote earlier on this topic: Nieuwe overheidssites verplicht toegankelijk vanaf 23 september: wat is de impact voor overheidsinstellingen en lokale besturen? ("New government sites compulsorily accessible from 23 September: what's the impact for government agencies and local governments?")
Although mobile apps are quite different functionally (and under the bonnet) from websites, they are often mentioned in the same breath (e.g. in the Flemish government's Administrative Decree). Apps and sites are also subject to the same technical accessibility standard: WCAG. This sometimes causes confusion and differences in interpretation. So let's look at those differences first.
In addition, unlike apps, websites are built with open web standards such as HTML, CSS and JavaScript. This gives websites an edge when it comes to ensuring accessibility. Yet apps — provided some efforts are made by the builder — are by no means inferior in this respect.
A notable difference when using apps — apart from the controls — is in the many dynamic changes that can be seen on the screen.
For example, if you are blind or visually impaired, it is essential that an app alerts you when something on the screen demands your attention. At the same time, you don't want to bombard the user with spoken messages. This makes app accessibility a topic that not only builders, but also UX designers need to look into.
As you can see, sometimes an app offers functionality that a 'regular' website cannot give you. Then again, other apps are especially useful on the go. Finally, apps are generally easier to use. This in turn appeals to people with limited digital skills.
These are all reasons why app accessibility deserves just as much attention as web accessibility.
So, despite the differences, the same guidelines apply to apps: the Web (!) Content Accessibility Guidelines or WCAG. Applying WCAG in apps is relatively new and there are still some misunderstandings about it. When the second version of WCAG was developed, technology-independent guidelines were chosen, yet in practice it turns out that WCAG cannot be applied directly to apps. In the article Voor apps gelden maar 44 succescriteria uit WCAG ("Only 44 success criteria from WCAG apply to apps"), the Dutch Appt Foundation writes this:
First, 6 criteria do not apply to apps. Secondly, 13 success criteria have minor modifications to the WCAG 2.1 notes or definitions. (...) Finally, the remaining 31 success criteria are directly applicable, but sometimes have notes as additional explanations.
We at Eleven Ways also experienced this when we were involved in making the Belgian CoronAlert app and Toerisme Vlaanderen's YouFlanders app accessible last summer. Here and there, you bump into the limitations of iOS and Android and have to come up with creative solutions so as not to exclude any users.
Preparing a reasoned accessibility statement is the first step for most organisations. You need to publish this in an accessible format. Providers can base this on this model accessibility statement.
The federal law on digital accessibility states:
la déclaration sur l'accessibilité est fournie dans un format accessible, en utilisant le modèle de déclaration sur l'accessibilité visé dans la Directive (UE) 2016/2102, et est disponible sur le site internet de l'organisme du secteur public qui a développé l'application mobile concernée, ou apparaît avec d'autres informations disponibles lors du téléchargement de l'application.
Translation:
the accessibility statement is provided in an accessible format, using the accessibility statement template referred to in Directive (EU) 2016/2102, and is available on the website of the public sector body that developed the mobile application concerned, or appears with other information available when downloading the application.
So place the accessibility statement on the web page that refers to apps in the App Store (iOS) and the Play Store (Google). Unfortunately, there is no place for an accessibility statement in the stores themselves.
As a best practice, you can additionally share the statement in the app itself, but then visitors can only read it after installing the app.
Left: YouFlanders app by Toerisme Vlaanderen links to a web page. Right: the Dutch app CoronaMelder has integrated the statement into the app.
To make an informed statement about the accessibility of your app, you obviously need to test it or have it tested. You can do the testing yourself, but then knowledge of screen readers, voice controls and (platform-specific) settings is a must. What you need at least for a test are two smartphones (an iPhone and an Android phone) and a Bluetooth keyboard.
Some examples of things you can test yourself:
To get a full view, you can ask a specialist party to carry out a full WCAG evaluation or a QuickScan. The advantage of working with experts is that they can also advise on which issues need to be addressed as a priority and which, if any, you can exclude in the accessibility statement.
Partner with an app developer with demonstrable knowledge of WCAG (for example, see if they already have an app with an accessibility statement in their portfolio). Also make good agreements. That way, when you launch the app, you can immediately show off a positive accessibility statement.
At Eleven Ways, we have been advising contracting authorities for years to explicitly refer to the law and the corresponding technical standard in public contracts. This can be done by adding a clause like this one:
The contracting authority attaches great importance to accessibility, including the accessibility of mobile applications, including for people with disabilities. The mobile application that is the subject of this contract must be accessible at least in accordance with standard EN 301 549.
By doing so, you also help raise awareness in the market. You will find more tips on the Flemish government's website Overheidsopdrachten en raamcontracten ("Public procurement and framework contracts"), but the advice obviously also applies to public procurement within other levels of government.
Organisations like DiAX (a network of experienced certified accessibility professionals) can help you test apps and create a reasoned accessibility statement for existing apps.
For new projects, they can support you and your app builder during the crucial moments of the development process. This is useful when your app builder does not yet have much experience in designing accessible apps and/or when the app needs to appeal to a very wide and diverse audience.
👉 As a public authority (Flemish, local or federal), chances are good that you can use the services of the partners that are part of DiAX today without a tendering procedure. To do so, take a look at the framework agreements page.
During the development of a new app, it is advisable to go a step further by testing the app with the help of real users with various disabilities. Such practical testing always yields surprising insights and helps ensure that the app is not only technically WCAG compliant, but also meets the needs and expectations of people with disabilities.
At Eleven Ways, for instance, we recently tested De Lijn's new app. We did so with the help of an enthusiastic test panel. All collected feedback was prioritised by our team and translated into concrete actions. The most urgent adjustments were implemented immediately, even before the launch. Today, De Lijn's app is one of the most accessible public transport apps in our country.
The use of mobile apps is (still) on the rise. Lieven De Mare, professor of new communication technologies at UGent, uses the term "Appification" for this in the latest Digimeter:
The consequence of digital acceleration: average mobile screen time is rising by half an hour, to 3 hours and 5 minutes a day.
Needless to say, this has also made app accessibility an indispensable requirement — not least for government apps, where there has been an obligation since 23 June 2021.
For more than 15 years, experts and users have been pulling the cart to make digital government more accessible. Today, then, you will find an accessibility statement on more and more government sites — in addition to the mandatory privacy statement. This has to do with the legal obligation, but also with the growing awareness that digitisation is unstoppable and we should not exclude anyone.
Let us therefore hope that soon we will also be able to download more accessible apps in the App Store and Play Store.
🙋Need help? Send an email to info@elevenways.be, follow us on Twitter or subscribe to our newsletter.
In March 2024, Eleven Ways conducted its first ever study to check the presence of mandatory accessibility statements on Belgian government websites. Read the results here.
Lessons from the Workshop on Neurodiversity with Bjièn
We must legally comply with WCAG. What is the scope of the project?
We want to train our teams in accessibility. Who should be trained?
We need external expertise. A temporary reinforcement, is it possible?
We want to test our application with users with disabilities. How to organize it?