Accessibilité des applications : obligations, barrières courantes et par où commencer

Une icône en forme de panier, sans intitulé, suffit à bloquer un achat. Les personnes qui utilisent un lecteur d'écran entendent seulement « bouton ». Il en va de même pour le menu, la loupe de recherche et la touche de retour.

L'accessibilité des applications consiste à rendre chaque écran perceptible, utilisable et compréhensible, y compris avec VoiceOver, TalkBack, un clavier externe ou une taille de police système agrandie. Dans ce guide, vous trouverez ce que demande la réglementation, les barrières numériques qui ressortent le plus souvent des audits de nos spécialistes de l'accessibilité et les sept actions qui offrent le meilleur rapport entre impact et effort.

Ce que signifie l'accessibilité des applications

En Italie, la loi 4/2004 (loi Stanca) définit l'accessibilité comme la capacité des systèmes informatiques à fournir des services et des informations utilisables par les personnes qui ont recours aux technologies d'assistance. La charge de l'adaptation revient donc au système, pas à la personne.

Le principe vaut pour les applications natives iOS et Android, les applications web et les sites mobiles. Les Web Content Accessibility Guidelines (WCAG) ont été conçues pour le web, mais leurs critères s'appliquent aussi aux écrans d'une application native, et la norme européenne EN 301 549 couvre aussi le mobile.

Les quatre principes des WCAG se traduisent concrètement sur l'écran d'un smartphone :

• Un écran est perceptible s'il comporte un texte alternatif, un contraste adéquat et un texte qui s'agrandit.

• Il est utilisable si chaque geste a une alternative et si les zones tactiles sont assez grandes.

• Il est compréhensible si les erreurs sont claires.

• Il est robuste si le nom, le rôle et l'état de chaque composant parviennent aux technologies d'assistance.

Les personnes qui utilisent une application autrement que vous l'avez imaginé

Une personne en situation de handicap visuel utilise VoiceOver sur iOS ou TalkBack sur Android et écoute l'écran au lieu de le regarder. Une personne qui vit avec un handicap moteur peut s'appuyer sur un clavier externe, un contacteur ou des commandes vocales. Une personne en situation de basse vision agrandit la police système et s'attend à ce que l'application la respecte.

Les mêmes solutions aident aussi dans des situations temporaires : soleil direct sur l'écran, une main occupée, un bras plâtré. Ce qui sert chaque jour à un groupe de personnes sert à beaucoup d'autres, de temps en temps.

Quand l'accessibilité des applications est obligatoire

Pour les administrations publiques, l'obligation existe depuis longtemps : la directive (UE) 2016/2102 exige que les sites et les applications mobiles du secteur public soient accessibles. En France, l'article 47 de la loi 2005-102 l'impose aux services publics et aux entreprises dont le chiffre d'affaires dépasse 250 millions d'euros, avec le RGAA comme référentiel.

Depuis le 28 juin 2025, la transposition française de la directive européenne sur l'accessibilité (EAA) étend les obligations aux opérateurs économiques pour les produits et services relevant de son champ d'application. Sont concernés le commerce en ligne, les services bancaires aux consommateurs et les services de transport de voyageurs, y compris lorsqu'ils passent par une application. Les microentreprises de services sont exclues.

La référence technique est la norme EN 301 549, qui renvoie aux WCAG de niveau AA. En France, le RGAA 4.1.2 sert de référentiel de vérification. Les organismes concernés par la loi 2005-102 publient une déclaration d'accessibilité et un schéma pluriannuel. Le contrôle est assuré par la DGCCRF pour la plupart des services aux consommateurs, et par l'Arcom pour le secteur public et les grandes entreprises relevant de la loi 2005-102.

Agir à temps laisse plus de marge : les corrections s'intègrent au cycle de publication habituel, sans avoir à courir après le temps.

Les barrières les plus fréquentes dans les applications

Les audits de nos spécialistes de l'accessibilité font apparaître des schémas qui se répètent. Il s'agit de quatre familles de barrières numériques, dont chacune correspond à des critères WCAG précis.

Composants sans nom, rôle ni état

Les icônes, les boutons uniquement graphiques et les composants personnalisés n'exposent souvent ni nom, ni rôle, ni état aux technologies d'assistance (critère 4.1.2). Le lecteur d'écran dit « bouton » et rien d'autre, ou n'annonce pas si un interrupteur est activé. Le composant devient inutilisable.

Il en va de même pour les images. Les images informatives sans alternative textuelle et les images décoratives non masquées (critère 1.1.1) font perdre des informations et ajoutent du bruit à la lecture.

Une structure et des champs difficiles à comprendre

Des titres qui ne sont pas balisés comme tels, des étiquettes de champ non associées au champ, des listes et des groupes non déclarés : tout cela relève du critère 1.3.1. Sans titres balisés, impossible de naviguer par titres. Sans étiquettes associées, les personnes qui utilisent un lecteur d'écran ne comprennent pas ce qu'il faut remplir à l'inscription, à la connexion et au paiement.

Clavier, gestes et ordre du focus

Les fonctions qui exigent des gestes complexes ou des balayages (critère 2.1.1) bloquent les personnes qui utilisent un clavier externe ou un contacteur. L'ordre du focus compte aussi (critère 2.4.3) : s'il est illogique, ou si le focus n'est pas géré sur les fenêtres modales et lors des changements d'écran, des contenus sont ignorés ou atteints hors contexte.

Orientation verrouillée et texte qui ne s'agrandit pas

Une application verrouillée en mode portrait ou paysage (critère 1.3.4) est inutilisable pour les personnes qui maintiennent leur appareil dans une seule position, par exemple sur un support. Un texte qui ne grandit pas, ou qui est coupé quand la police système est agrandie (critère 1.4.4), exclut les personnes en situation de basse vision. La cause tient souvent à des hauteurs fixes dans les conteneurs.

Sept actions pour améliorer tout de suite l'accessibilité des applications

Il n'est pas nécessaire de refaire l'application de zéro. Quelques actions ciblées permettent de récupérer beaucoup, et nous avons classé les sept meilleures selon le rapport entre impact et effort.

Comment tester l'accessibilité d'une application

Les outils automatiques repèrent les problèmes les plus simples à détecter. Pour savoir si l'application est utilisable, trois niveaux de vérification sont nécessaires.

Le premier niveau est le test manuel.

Activez VoiceOver ou TalkBack et réalisez un scénario complet, par exemple connexion, recherche, achat. Branchez ensuite un clavier Bluetooth et déplacez-vous avec Tab et Entrée, agrandissez la police système et faites pivoter l'appareil.

Le deuxième niveau, ce sont les outils.

Sur Android, il y a Accessibility Scanner ; sur iOS, l'Accessibility Inspector de Xcode ; et Android propose aussi des tests automatiques pour les interfaces en Compose. Ils signalent les contrastes, les zones tactiles et les intitulés manquants, mais ils ne disent pas si un intitulé a du sens pour la personne qui l'écoute.

Le troisième niveau est le test avec des personnes en situation de handicap.

Une application peut être accessible et rester peu utilisable : seules les personnes qui s'en servent chaque jour avec des technologies d'assistance savent dire si un parcours est efficace et satisfaisant.

Comment nous vous accompagnons sur une application

Un audit d'accessibilité Accessiway sur une application suit les WCAG 2.2 de niveau AA et la norme EN 301 549, et s'appuie sur la contribution de personnes qui utilisent chaque jour les technologies d'assistance. Le résultat est une liste de barrières numériques classées par impact, avec des indications de remédiation pensées pour les équipes de développement.

Le travail se poursuit ensuite à chaque nouvelle version, car la conformité se maintient dans la durée.

Découvrez-le avec un audit Accessiway : une conversation de 15 minutes suffit pour savoir par où commencer avec votre application.

Questions fréquentes sur l'accessibilité des applications

Que signifie l'accessibilité des applications ?

L'accessibilité des applications est la capacité d'une application à être perçue, utilisée et comprise, y compris avec des technologies d'assistance comme VoiceOver et TalkBack, un clavier externe ou un texte agrandi. C'est l'application qui s'adapte à la personne.

Les WCAG s'appliquent-elles aussi aux applications ?

Oui, les critères des WCAG s'appliquent aussi aux écrans des applications natives. La norme européenne EN 301 549 couvre les logiciels mobiles et prend les WCAG de niveau AA comme référence pour les contenus.

Quand l'accessibilité est-elle obligatoire pour une application ?

Pour les administrations publiques, l'obligation existe depuis longtemps. Depuis le 28 juin 2025, la transposition française de l'European Accessibility Act l'étend aux opérateurs économiques concernés, microentreprises de services exclues.

Comment vérifier l'accessibilité d'une application ?

On associe des tests manuels avec VoiceOver ou TalkBack, un clavier externe et un texte agrandi, des outils comme Accessibility Scanner ou Accessibility Inspector, et des essais avec des personnes en situation de handicap.

Par quelles actions commencer ?

Par les intitulés accessibles sur les icônes et les boutons uniquement graphiques, puis par les titres d'écran, les étiquettes de champ toujours visibles et les erreurs annoncées. Elles demandent peu de temps et ont un impact élevé.

Contenu généré avec le soutien de l'intelligence artificielle et soumis à la supervision et à la révision humaines