Auditer une application mobile : quel référentiel, quelles différences
Les applications mobiles entrent dans le champ de l'obligation d'accessibilité au même titre que les
sites. Mais le RGAA 4.1.2 a été écrit pour le web : ses tests s'appuient sur le HTML, l'attribut
alt, le DOM. Auditer une application native demande donc une transposition, et c'est là
que commencent les difficultés.
La méthode générale reste celle décrite sur la page audit RGAA ; ce sont les tests eux-mêmes qui changent.
Quel référentiel appliquer
Les principes sous-jacents ne changent pas : ce sont ceux des WCAG, repris au niveau européen par la norme EN 301 549, laquelle comporte des exigences propres aux logiciels et aux applications mobiles. En pratique, un audit d'application s'appuie sur ces exigences, transposées aux composants natifs de chaque plateforme.
La version 5 du référentiel, attendue fin 2026, annonce l'intégration d'un cadre technique pour les applications mobiles — aujourd'hui traitées en marge. Voir le référentiel RGAA.
Conséquence pratique : un audit d'application mené aujourd'hui devra être repris après publication. Ce n'est pas une raison d'attendre — les corrections, elles, resteront valables.
Les équivalences à connaître
| Notion web | iOS | Android |
|---|---|---|
| Alternative textuelle | accessibilityLabel | contentDescription |
| Rôle d'un composant | accessibilityTraits | Classe de vue ou rôle déclaré |
| Lecteur d'écran | VoiceOver | TalkBack |
| Ordre de parcours | Ordre d'accessibilité | Ordre de focus déclaré |
| Taille de texte utilisateur | Dynamic Type | Échelle de police système |
| Élément décoratif | isAccessibilityElement à faux | importantForAccessibility à no |
Les points sensibles propres au mobile
- Le respect de la taille de police système. Une application qui ignore le réglage de l'utilisateur et impose ses tailles est inutilisable pour une grande partie du public concerné. C'est le défaut numéro un.
- L'orientation. Forcer le portrait ou le paysage bloque les personnes dont l'appareil est fixé sur un support.
- La taille des cibles tactiles. Un bouton trop petit ou collé à un autre rend l'action impossible en cas de tremblement ou de motricité fine réduite.
- Les gestes complexes. Tout geste à plusieurs doigts ou tracé doit disposer d'une alternative simple.
- Les composants web embarqués. Une vue web dans une application native se teste selon les critères web — deux référentiels cohabitent alors dans le même audit.
L'échantillon, version mobile
On ne raisonne plus en pages mais en écrans et en parcours. L'échantillon couvre l'écran d'accueil, l'authentification, les écrans de saisie, un parcours transactionnel complet, les écrans d'erreur et les réglages. Comme sur le web, un parcours se teste en entier — voir la constitution de l'échantillon.
Comment on teste
Chaque écran est parcouru au lecteur d'écran natif de la plateforme, puis avec la police système portée à son maximum, puis avec les réglages de contraste renforcé et de réduction des animations. Les outils d'inspection fournis par chaque environnement de développement complètent le relevé, sans jamais s'y substituer.
Poursuivre
Pour le cas voisin des documents diffusés dans l'application, voyez l'audit des PDF et documents bureautiques. Pour la validation après corrections, le contre-audit.