Toutes les applications gouvernementales doivent dès aujourd’hui comporter une déclaration d'accessibilité. Elle indique dans quelle mesure l'application est accessible aux citoyens en situation de handicap. Dans cet article, je vous explique ce que signifie l'accessibilité des applications. Vous apprendrez également comment l'application de votre organisation peut bientôt être conforme.
En 2016, la Commission européenne a demandé à tous les États membres de rendre obligatoire l'accessibilité de leurs canaux numériques (semi-)gouvernementaux. Tous les États membres - y compris la Belgique et les Pays-Bas - ont depuis transposé cette directive dans des lois et décrets locaux. Elle s'applique à tous les niveaux de gouvernement. Les sites web sont déjà tenus d'avoir au moins une déclaration d'accessibilité depuis septembre 2020. À partir du 23 juin 2021, cela s'appliquera également aux applications mobiles nouvelles et existantes.
👉 Pour un aperçu plus large de l'accessibilité numérique dans l'administration, vous pouvez vous référer à l'article que j'ai écrit précédemment sur ce sujet : Nieuwe overheidssites verplicht toegankelijk vanaf 23 september: wat is de impact voor overheidsinstellingen en lokale besturen? ("Nouveaux sites gouvernementaux obligatoirement accessibles à partir du 23 septembre : quel est l'impact pour les agences gouvernementales et les collectivités locales ?")
Bien que les applications mobiles soient fonctionnellement (et sous le capot) très différentes des sites web, les deux sont souvent mentionnés ensemble (par exemple, dans le décret du Parlement wallon). Les applications et les sites sont également soumis à la même norme d'accessibilité technique : WCAG. Cela entraîne parfois des confusions et des différences d'interprétation. Examinons donc d'abord ces différences.
En outre, contrairement aux applications, les sites web sont construits avec des normes web ouvertes telles que HTML, CSS et JavaScript. Cela donne aux sites web un avantage lorsqu'il s'agit de garantir l'accessibilité. Pourtant, les applications — à condition que le développeur fasse quelques efforts — ne sont en aucun cas inférieures à cet égard.
Une différence notable dans l'utilisation des applications — hormis les commandes — réside dans les nombreux changements dynamiques visibles à l'écran.
Par exemple, si vous êtes aveugle ou malvoyant, il est essentiel qu'une application vous avertisse lorsque quelque chose sur l'écran requiert votre attention. En même temps, vous ne voulez pas bombarder l'utilisateur de messages parlés. L'accessibilité des applications est donc un sujet sur lequel doivent se pencher non seulement les développeurs, mais aussi les UX designers.
Comme vous pouvez le constater, une application offre parfois des fonctionnalités qu'un site web "ordinaire" ne peut vous offrir. Mais d'autres applications sont particulièrement utiles en déplacement. Enfin, les applications sont généralement plus faciles à utiliser. Cela permet de séduire les personnes moins à l’aise avec le numérique.
Ce sont autant de raisons pour lesquelles l'accessibilité des applications mérite autant d'attention que l'accessibilité du web.
Ainsi, malgré les différences, les mêmes directives s'appliquent aux applications : les Règles pour l’accessibilité des contenus Web (!) ou WCAG. L'application des WCAG aux applications mobiles est relativement récente et il existe encore quelques malentendus à ce sujet. Lorsque la deuxième version des WCAG a été élaborée, des lignes directrices indépendantes de la technologie ont été choisies. Pourtant, dans la pratique, il s'avère que les WCAG ne peuvent pas être appliqués directement aux applications. Dans l'article intitulé Voor apps gelden maar 44 succescriteria uit WCAG ("Pour les applications, seuls 44 critères de réussite WCAG s'appliquent"), la fondation néerlandaise Appt écrit ceci :
Premièrement, 6 critères ne s'appliquent pas aux applications. Deuxièmement, 13 critères de réussite présentent des modifications mineures par rapport aux notes ou aux définitions des WCAG 2.1. (...) Enfin, les 31 critères de réussite restants sont directement applicables, mais comportent parfois des notes comme explications supplémentaires.
Chez Eleven Ways, nous en avons également fait l'expérience lorsque nous avons participé, l'été dernier, à l'accessibilité de l'application belge CoronAlert et de l'application YouFlanders de Toerisme Vlaanderen. Ici et là, vous vous heurtez aux limites d'iOS et d'Android et vous devez trouver des solutions créatives pour ne pas exclure d'utilisateurs.
La préparation d'une déclaration d'accessibilité raisonnée est la première étape pour la plupart des organisations. Vous devez publier ces informations dans un format accessible. Les prestataires peuvent se baser sur ce modèle de déclaration d'accessibilité.
La loi fédérale sur l'accessibilité stipule que :
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.
Vous pouvez donc placer la déclaration d'accessibilité sur la page web qui fait référence aux applications de l'App Store (iOS) et du Play Store (Google). Malheureusement, il n'y a pas de place pour une déclaration d'accessibilité dans les Store eux-mêmes.
Une bonne pratique consiste à partager la déclaration dans l'application elle-même, mais les visiteurs ne pourront alors la lire qu'après avoir installé l'application.
À gauche : l'application YouFlanders de Toerisme Vlaanderen renvoie à une page web. À droite : l'application néerlandaise CoronaMelder a intégré la déclaration dans son application.
Pour vous prononcer en connaissance de cause sur l'accessibilité de votre application, vous devez évidemment la tester ou la faire tester. Vous pouvez effectuer les tests vous-même, mais il vous faudra alors connaître les lecteurs d'écran, les commandes vocales et les paramètres (spécifiques à la plate-forme). Ce dont vous avez besoin, au moins pour un test, c'est de deux smartphones (un iPhone et un téléphone Android) et d'un clavier Bluetooth.
Quelques exemples de choses que vous pouvez tester vous-même :
Pour obtenir une vue d'ensemble, vous pouvez demander à un spécialiste d'effectuer un audit complet WCAG ou un QuickScan. L'avantage de travailler avec des experts est qu'ils peuvent également vous conseiller sur les questions qui doivent être traitées en priorité et celles que vous pouvez éventuellement exclure dans la déclaration d'accessibilité.
Faites équipe avec un développeur d'applications ayant une connaissance manifeste des WCAG (par exemple, vérifiez s'il a déjà une application avec une déclaration d'accessibilité dans son portfolio). Prenez également de bonnes dispositions. Ainsi, lorsque vous lancez l'application, vous pouvez immédiatement afficher une déclaration d'accessibilité positive.
Chez Eleven Ways, nous conseillons depuis des années aux pouvoirs adjudicateurs de faire explicitement référence à la loi et à la norme technique correspondante dans les marchés publics. Cela peut être fait en ajoutant une clause comme celle-ci :
Le pouvoir adjudicateur attache une grande importance à l'accessibilité, notamment à l'accessibilité des applications mobiles, y compris pour les personnes handicapées. L'application mobile qui fait l'objet du présent contrat doit être accessible au moins conformément à la norme EN 301 549.
Ce faisant, vous contribuez également à sensibiliser le marché. Vous trouverez plus de conseils sur le site Web Overheidsopdrachten en raamcontracten ("Marchés publics et contrats-cadres") du gouvernement flamand, mais ces conseils s'appliquent évidemment aussi aux marchés publics des autres niveaux de gouvernement.
Des organisations telles que DiAX (un réseau de professionnels expérimentés et certifiés en matière d'accessibilité) peuvent vous aider à tester vos applications et à créer une déclaration d'accessibilité raisonnée pour les applications existantes.
Pour les nouveaux projets, ils peuvent vous soutenir, vous et le développeur de vos applications, pendant les moments cruciaux du processus de développement. Cette option est utile lorsque votre développeur n'a pas encore beaucoup d'expérience dans la conception d'applications accessibles et/ou lorsque l'application doit s'adresser à un public très large et diversifié.
👉 En tant qu'autorité publique (flamande, locale ou fédérale), il y a de bonnes chances que vous puissiez utiliser les services des partenaires qui font partie de DiAX aujourd'hui sans procédure d'appel d'offres. Pour ce faire, jetez un coup d'œil à la page des contrats-cadres.
Lors du développement d'une nouvelle application, il est conseillé d'aller plus loin en testant l'application avec l'aide d'utilisateurs réels avec divers handicaps. Ces tests pratiques donnent toujours des résultats surprenants et permettent de s'assurer que l'application est non seulement techniquement conforme aux WCAG, mais qu'elle répond également aux besoins et aux attentes des personnes handicapées.
Chez Eleven Ways, par exemple, nous avons récemment testé la nouvelle application de De Lijn. Nous l'avons fait avec l'aide d'un panel de testeurs enthousiastes. Tous les commentaires recueillis ont été classés par ordre de priorité par notre équipe et traduits en actions concrètes. Les ajustements les plus urgents ont été mis en œuvre immédiatement, avant même le lancement. Aujourd'hui, l'application De Lijn est l'une des applications de transport public les plus accessibles dans notre pays.
L'utilisation des applications mobiles est (encore) en hausse. Lieven De Mare, professeur de nouvelles technologies de communication à l'UGent, utilise pour cela le terme "Appification" dans le dernier Digimeter :
Conséquence de l'accélération numérique : le temps moyen passé devant un écran mobile augmente d'une demi-heure, pour atteindre 3 heures et 5 minutes par jour.
Il va sans dire que l'accessibilité des applications est devenue une exigence indispensable, notamment pour les applications gouvernementales, pour lesquelles une obligation existe depuis le 23 juin 2021.
Depuis plus de 15 ans, les experts et les utilisateurs tirent la charrette pour rendre le gouvernement numérique plus accessible. Aujourd'hui, vous trouverez donc une déclaration d'accessibilité sur de plus en plus de sites gouvernementaux, en plus de la déclaration obligatoire de confidentialité. Cela tient à l'obligation légale, mais aussi à la prise de conscience croissante que la numérisation est inévitable et que nous ne devons exclure personne.
Espérons donc que bientôt, nous pourrons également télécharger des applications plus accessibles dans l'App Store et le Play Store.
Besoin d'aide ? Envoyez un courriel à info@elevenways.be, suivez-nous sur Twitter ou abonnez-vous à notre newsletter.
En avril 2024, 76 communes de Bruxelles et de Wallonie ont reçu le label Handycity®, gage d'inclusivité. Mais cela garantit-il l'accessibilité de leur site web?
En mars 2024, Eleven Ways a mené sa toute première étude visant à vérifier la présence de mentions d'accessibilité obligatoires sur les sites Internet du gouvernement belge. En voici les résultats.
Nous devons légalement nous conformer aux WCAG. Quelle est l'ampleur du chantier ?
Nous voulons former nos équipes à l'accessibilité. Qui devrait-on former ?
Nous avons besoin d'expertise externe. Un renfort temporaire, c'est possible ?
Nous voulons tester notre application avec des utilisateurs en situation de handicap. Comment l'organiser ?