Quelles différences entre l'audit d’accessibilité d'une application mobile et celui d'un site web ?

Les sanctions sont multiples pour les entreprises concernées. 

• On parle d’une sanction de 25 000 € par application mobile, renouvelable tous les six mois, pour défaut d’affichage du taux d’accessibilité.
• Les entreprises non conformes risquent des amendes pouvant aller de 7 500 euros à une astreinte de 3 000 euros par jour, ne pouvant dépasser 300 000 euros, pour une mise en conformité de leurs obligations.

Les autres risques financiers sont aussi liés aux frais juridiques qui peuvent découler de plaintes des utilisateurs. À titre d’exemple, les procès pour défaut d’accessibilité aux États-Unis se multiplient, et on parle parfois de plusieurs millions de dollars de frais engendrés à cause de ces situations pour les entreprises. En France, le recours à la justice vient à peine de commencer, mais  on peut déjà voir des grands noms de l’industrie agro-alimentaire passer devant les tribunaux, notamment Carrefour, Picard, Auchan et Leclerc. Les frais d’avocats, de relations presse, de communication vont grossir à mesure que ces procès s’étalent dans le temps. Bref, se conformer à l’accessibilité, c’est avant tout prendre des dispositions pour éviter des dépenses inutiles en frais juridiques.

Pour structurer un audit d’accessibilité, différents référentiels existent et s’adaptent en fonction du cadre juridique et technique imposé. Si le site internet dispose du RGAA (Référentiel Général d’Amélioration de l’Accessibilité) ou bien du RAWeb, les applications mobiles, elles, s’appuient sur le référentiel RAAM 1.1 (Référentiel d’Évaluation de l’Accessibilité des Applications Mobiles). 

En effet, le RGAA n’était pas complètement adapté aux spécificités des applications mobiles.

Le RGAA pour le web s’appuie majoritairement sur l’inspection du code source HTML et la validité de sa structure (le DOM). Il traque la validité du code, la hiérarchie des balises de titres (<h1>, <h2>) ou encore la pertinence des attributs ARIA. À l’inverse, l’audit mobile via le RAAM 1.1 se concentre sur l’Arbre d’Accessibilité généré par le système d’exploitation (iOS ou Android).

L’auditeur ne vérifie pas des balises, mais s’assure que les composants de l’interface communiquent les bonnes informations aux API d’accessibilité de l’OS. Cela inclut :

• Les Rôles : Un élément est-il identifié comme un bouton, un en-tête ou un champ de saisie ?
• Les États : L’API reçoit-elle l’information qu’une case est « cochée » ou qu’un élément est « désactivé » ?
• La Hiérarchie : La structure logique des informations est-elle préservée lors de la transmission aux lecteurs d’écran ?

Le RAAM 1.1 fait ainsi le pont entre le code de développement (Swift, Kotlin, React Native, etc.) et la restitution finale par le système, garantissant une couche d’abstraction robuste quel que soit le framework utilisé.

Le RAAM 1.1 ne se contente pas de traduire les critères du Web pour le mobile. Il est conçu pour auditer la manière dont une application dialogue avec le système d’exploitation. Là où le RGAA analyse principalement la structure sémantique d’une page HTML, le RAAM analyse les interactions réelles que l’utilisateur a avec les éléments.

Cette approche est cruciale : elle permet de vérifier que chaque interaction (un balayage, un clic, un appui long) est correctement interprétée par les services d’accessibilité natifs. Le RAAM 1.1 devient ainsi le garant d’une expérience fluide, en s’assurant que les développeurs utilisent correctement les propriétés d’accessibilité (traits, rôles et états) fournies par Apple et Google, tout en traitant des problématiques purement mobiles comme la gestion des capteurs de mouvement ou l’adaptation aux changements d’orientation de l’écran.