Accessibilité des applications mobiles : les erreurs WCAG les plus fréquentes dans 50 applications auditées

Nous avons analysé les audits d'accessibilité de 50 applications iOS et Android réalisés au cours de l'année écoulée, pour comprendre ce qui manque encore aux applications accessibles.

La plupart des barrières numériques relevées viennent d'un petit nombre d'erreurs récurrentes, presque toutes au niveau le plus élémentaire des Web Content Accessibility Guidelines (WCAG).

Dans cet article, vous verrez ce qui ne fonctionne pas, à quelle fréquence, et quelles corrections règlent le plus de problèmes.

Quelles sont les erreurs d'accessibilité les plus fréquentes dans les applications mobiles ?

Ces quatre erreurs apparaissent dès qu'on utilise un lecteur d'écran.

Quels sont les critères WCAG les plus enfreints dans les applications mobiles ?

Trois critères représentent six problèmes sur dix : 4.1.2 Nom, rôle et valeur ; 1.3.1 Information et relations ; 2.4.3 Parcours du focus. Tous trois relèvent du niveau A. Tous trois déterminent si un lecteur d'écran peut restituer un écran de façon compréhensible.

Sur l'ensemble des données, 84 % des problèmes ne respectent pas des critères de niveau A et 16 % des critères de niveau AA. La gravité est élevée elle aussi : chaque application présentait au moins un problème classé critique.

4.1.2 Nom, rôle et valeur exige que chaque élément interactif indique ce qu'il est (son rôle), comment il s'appelle (son nom) et dans quel état il se trouve. Quand ce critère n'est pas respecté, la personne qui utilise un lecteur d'écran entend « bouton » sans libellé, ou un libellé sans savoir que l'élément peut être touché. L'exigence complète figure sur la page Understanding 4.1.2 du W3C (en anglais).

1.3.1 Information et relations n'est pas respecté quand la structure visible n'est pas transmise aux technologies d'assistance : des textes qui ressemblent à des titres sans être balisés comme tels, ou des libellés qui ne sont pas reliés à leurs champs. 2.4.3 Parcours du focus n'est pas respecté quand le lecteur d'écran parcourt l'écran dans un ordre qui ne correspond pas à ce qui est affiché.

Quels critères WCAG corriger en priorité dans une application ?

Commencez par 4.1.2, 1.3.1 et 2.4.3, qui concernent presque toutes les applications. Passez ensuite à ces critères :

• 1.1.1 Contenu non textuel : les images et icônes porteuses de sens ont besoin d'une alternative textuelle.

• 2.1.1 Clavier : tout doit fonctionner avec un clavier ou un autre périphérique externe, pas seulement au toucher.

• 1.4.3 Contraste (minimum) : le texte doit se distinguer nettement de l'arrière-plan.

• 1.4.4 Redimensionnement du texte : rien ne doit être coupé quand on agrandit le texte.

• 1.3.4 Orientation : l'application doit fonctionner en portrait et en paysage.

Inutile de tout corriger d'un coup. Une structure sémantique solide, avec des noms, des rôles, des états et un ordre de focus logique, permet d'utiliser l'application au clavier, au joystick, à la commande vocale et au lecteur d'écran.

Comment corriger les erreurs d'accessibilité les plus fréquentes dans les applications mobiles ?

Les corrections indiquées dans les audits correspondent aux erreurs les plus fréquentes. Voici comment corriger chacune d'elles.

1. Attribuer le bon rôle à chaque composant

   Corrige les composants annoncés sans rôle ou avec le mauvais rôle. Déclarez les rôles via l'API d'accessibilité de chaque plateforme : accessibilityTraits sur iOS, AccessibilityNodeInfoCompat.setClassName() sur Android, accessibilityRole en React Native et Semantics en Flutter.

2. Donner à chaque composant un nom accessible clair

   Corrige les composants sans nom accessible. Définissez un accessibilityLabel explicite sur iOS et une contentDescription sur Android, surtout pour les boutons composés uniquement d'une icône.

3. Respecter les seuils minimaux de contraste

   Utilisez un rapport de contraste d'au moins 4,5:1 pour le texte normal et de 3:1 pour le texte de grande taille ainsi que pour les icônes, bordures et indicateurs d'état porteurs d'information. Vérifiez le mode clair et le mode sombre. Notre guide sur le contraste des couleurs explique comment les tester.

4. Déplacer le focus vers le nouveau contenu

   Corrige la barre de navigation inférieure qui laisse les personnes utilisant un lecteur d'écran sur la barre d'onglets. Sur iOS, définissez accessibilityElements dans le bon ordre. Sur Android, fixez l'ordre du focus avec nextFocusDown/Up/Left/Right dans le XML, ou avec focusProperties dans Compose. En React Native, déplacez le focus avec AccessibilityInfo.setAccessibilityFocus.

5. Regrouper les éléments liés en un seul composant

   Corrige les cartes qui demandent plusieurs balayages pour être lues. Une carte produit composée d'une image, d'un titre et d'un prix doit former un seul point de focus, et non quatre. Sur iOS, définissez isAccessibilityElement sur l'élément parent et donnez un libellé au groupe. Sur Android, utilisez android:screenReaderFocusable sur le conteneur.

Les composants natifs prennent déjà en charge une grande partie de ces points. Quand une équipe crée ses propres composants, elle doit déclarer elle-même le rôle, le nom et l'état.

Ce que cela implique pour la conformité à l'EAA

Les applications destinées aux consommateurs dans l'Union européenne suivent les mêmes règles que les sites web. Depuis le 28 juin 2025, la directive européenne sur l'accessibilité (EAA) exige des applications accessibles pour les services qui entrent dans son champ, comme la banque, le commerce en ligne et le transport de voyageurs. En France, le RGAA sert de référentiel de vérification. Les exigences techniques reposent sur les WCAG.

Au regard des WCAG, la plupart des applications auditées n'atteignent pas encore la base sur laquelle repose tout standard plus avancé. Les outils automatiques en détectent une partie, comme un contraste insuffisant. Ils ne peuvent pas juger si un libellé a du sens ou si le focus arrive au bon endroit après un toucher. C'est pourquoi notre guide sur l'accessibilité des applications recommande de combiner outils, tests manuels et tests avec des personnes en situation de handicap.

Méthodologie : d'où viennent les données ?

Cette analyse repose sur les audits d'accessibilité de 50 applications, réalisés par l'équipe applications d'Accessiway pour des organisations dans toute l'Europe au cours de l'année écoulée. Au total, les audits ont relevé 6 652 problèmes.

L'accessibilité des applications mobiles consiste à rendre les écrans d'une application perceptibles, utilisables, compréhensibles et robustes pour tout le monde, y compris pour les personnes qui utilisent un lecteur d'écran, un clavier externe, un contacteur ou un texte système agrandi, ainsi que pour celles qui ne peuvent pas faire pivoter leur appareil.

Nos équipes d'audit évaluent chaque application selon les WCAG 2.2 niveau AA et attribuent à chaque problème une priorité : critique, haute, moyenne ou basse.

Comment nous avons compté les résultats :

• Pour les critères WCAG, chaque application est comptée une seule fois, quel que soit son nombre de problèmes.

• Les erreurs les plus fréquentes proviennent de l'analyse des rapports d'audit par l'équipe applications, qui regroupe les problèmes décrits de façon similaire. Les pourcentages sont des minimums : chaque erreur est apparue dans au moins la part d'applications indiquée.

• Le nombre de problèmes dépend du nombre d'écrans et de parcours couverts par chaque audit. Le classement repose donc sur le nombre d'applications concernées, et non sur le volume total.

• La colonne « Part de l'ensemble des problèmes » compte les occurrences. Une erreur très répandue qui n'apparaît qu'une fois par application y pèse peu.

• Nous ne citons le nom d'aucune application.

Questions fréquentes sur les erreurs d'accessibilité dans les applications mobiles

Les WCAG s'appliquent-elles aux applications mobiles ?

Oui. Les WCAG ont été écrites pour le web, mais la norme EN 301 549, la norme européenne d'accessibilité des produits et services TIC, applique leurs critères de succès aux logiciels mobiles. Certains critères doivent être interprétés en dehors du navigateur, ce que le W3C explique dans son guide d'application des WCAG aux logiciels hors web (en anglais).

Quelle est l'erreur d'accessibilité la plus fréquente dans les applications mobiles ?

Les erreurs liées au critère WCAG 4.1.2 Nom, rôle et valeur : des composants sans nom accessible, ou avec un rôle manquant ou erroné. Au moins 92 % des applications auditées en présentaient une.

Quel niveau WCAG les applications mobiles enfreignent-elles le plus ?

Le niveau A, le plus élémentaire des WCAG. Ses critères déterminent si les personnes peuvent identifier, atteindre et utiliser chaque élément.

Par où commencer ?

Les corrections sont connues et reproductibles sur les deux plateformes.

1. Demandez un audit d'accessibilité de votre application, qui rattache chaque problème aux WCAG 2.2 et inclut des tests avec des personnes en situation de handicap.

2. Corrigez d'abord les problèmes de niveau A sur les parcours les plus fréquentés.

3. Intégrez les rôles, noms et états dans vos composants partagés, pour que les nouveaux écrans en héritent.

4. Ajoutez un contrôle au lecteur d'écran avant chaque mise en production, pour que les nouvelles versions ne réintroduisent pas les barrières déjà corrigées.

Ressources complémentaires

• Découvrez comment Lavazza a rendu ses applications iOS et Android accessibles

• Découvrez ce que couvre un audit d'accessibilité

• Testez votre application avec des personnes qui utilisent des technologies d'assistance

Vous voulez savoir où en sont vos produits numériques ? Échangez avec notre équipe sur une plateforme de conformité en accessibilité qui vous donne une visibilité et des outils pour gérer l'accessibilité dans la durée.

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