- Sommaire
- À qui s'adresse ce guide ?
- Introduction
- I. Présentation des outils d’accessibilité
- II. Introduction au lecteur d’écran
- III. Outils de test pour l’auditeur
- IV. Thèmes
- Ressources et références
- Guides connexes
- Licence
Ce guide présente les étapes à effectuer pour auditer l'accessibilité d'une application mobile. Il s'adresse :
- Aux développeurs
- Aux testeurs ou auditeurs
Pré-requis :
- Être familiarisé avec les principes, les règles et les critères de RGAA 3
- Connaître les principes de navigation clavier sous PC
- Être familiarisé avec l'OS mobile à tester
Les applications natives mobiles introduisent une nouvelle façon de réaliser les tests. Il n'est pas possible d'inspecter le code depuis le mobile, ou de naviguer au clavier à la manière d'un PC du fait que le système de navigation soit simplifié sur mobile (commutateurs, geste de navigation…). Ce nouvel environnement impose au développeur de tester l'application avec les technologies d'assistance. L'environnement d'une application native diffère complètement d'une application web où l'on peut appliquer les normes WCAG. La prise en compte de l'accessibilité doit être adaptée pour répondre à ce nouveau support tactile. De plus, l'accessibilité peut être traitée de façon très différente, d'un OS à un autre, par le développeur. Le lecteur d'écran étant natif à l'OS, le développeur peut introduire des comportements différents suivant le statut du lecteur d'écran, rendant de fait les tests au lecteur d'écran nécessaires.
Ce guide est destiné aux auditeurs voulant vérifier l'accessibilité d'une application mobile native. Il n'est pas nécessaire d'avoir accès au code source, il suffit qu'elle soit installée sur le support cible suivant la version de l'OS à auditer. Le développeur peut aussi utiliser ce guide pour vérifier l'accessibilité de son code.
Le guide a pour but de couvrir les points importants et erreurs récurrentes dans les applications mobiles. Il n'est pas exhaustif, car l'accessibilité sur les supports tactiles est en perpétuelle évolution et n'est pas assez mature. Par défaut, la majeur partie des critères du RGAA 3 s'appliquent, il est nécessaire d'adapter les spécifications techniques (Html/CSS/Js) pour les transposer au natif.
Les personnes en situation de handicap rencontrent des difficultés dans l'accès à l'information (applications, sites Web, etc.). Pour y pallier, elles utilisent des "technologies d'assistance". On peut distinguer deux grandes catégories de technologies d'assistance : logicielles et matérielles.
Des logiciels permettent de rendre accessibles les applications mobiles aux personnes en situation de handicap, notamment aux déficients visuels (non et mal-voyants). Ceux-ci sont soit disponibles "par défaut" dans le système d'exploitation et peuvent souvent être activés simplement via les paramètres d'accessibilité, soit installables séparément.
On trouve :
-
Les outils d'agrandissement et de modification de l'apparence des caractères : ils permettent à l'utilisateur malvoyant d'agrandir le contenu de l'écran afin d'en prendre connaissance plus facilement.
-
Sous Android, un certain nombre de paramètres sont disponibles (menu Paramètres > Accessibilité) :
- Gestes d'agrandissement : permet de définir de nouveaux gestes permettant à l'utilisateur de modifier la taille des éléments d'interface
- Grands caractères
- Texte en contraste élevé
- Inversion des couleurs
- Correction des couleurs
-
Pour IOS, les paramètres d'accessibilité permettent de :
- Activer le zoom
- Inverser les couleurs
- Obtenir un affichage en niveaux de gris
- Afficher des polices plus grandes par défaut
- Augmenter le contraste
-
-
Les lecteurs d'écran : ces applications permettent aux utilisateurs non et malvoyants d'accéder au contenu affiché à l'écran. Le lecteur d'écran pilote une synthèse vocale et/ou un périphérique externe tel qu'un afficheur braille (voir Le matériel). Ces logiciels remplissent plusieurs fonctions :
- Ils permettent à l'utilisateur de parcourir l'écran tactile afin d'en connaître le contenu
- Ils redéfinissent un certain nombre de gestes pour adapter la navigation dans les interfaces aux utilisateurs déficients visuels
- Ils vocalisent le contenu : ils sont en mesure de piloter des programmes de synthèse vocale (intégrés au système ou ajoutés par l'utilisateur)
- Ils pilotent un afficheur braille, un dispositif externe qui sert à restituer le contenu affiché à l'écran et qui peut aussi jouer le rôle d'un périphérique de saisie si l'appareil braille dispose d'un clavier
- Ils ajoutent un certain nombre de "métaphores sonores" qui sont des sons spécifiques émis pour permettre à l'utilisateur d'identifier plus facilement le contexte dans lequel il se trouve (zone de saisie, début ou fin de liste d'éléments, etc.)
- Ils proposent des assistances à la saisie
Pour Android, le logiciel TalkBack est un lecteur d'écran livré par défaut (depuis la version 4.0 du système) activable dans les paramètres d'accessibilité. Le système Android intègre un logiciel de synthèse vocale supportant plusieurs langues qui peut être piloté par TalkBack. Les utilisateurs d'afficheurs braille doivent activer le logiciel BrailleBack pour piloter leur appareil.
Les utilisateurs d'iOS peuvent activer le logiciel VoiceOver dans les paramètres d'accessibilité. Il s'agit d'un lecteur d'écran capable de piloter une synthèse vocale (également disponible par défaut avec iOS) et un afficheur braille.
- Les outils de reconnaissance vocale (comme Siri pour iOS) permettent aux utilisateurs qui ont des difficultés à utiliser les interfaces tactiles d'effectuer plus rapidement certaines actions simples (appeler un contact, entrer du texte dans une zone de saisie, etc.).
L'utilisation des interfaces tactiles peut être facilitée grâce à certains périphériques, souvent connectés via Bluetooth.
On peut citer :
- Clavier : permet aux utilisateurs de naviguer à l'intérieur des interfaces sans utiliser la gestuelle définie par le système ; facilite les opérations de saisie.
- Afficheur braille : ce dispositif est utilisé par les personnes aveugles, souvent en complément de la synthèse vocale. Un afficheur braille est constitué d'un ensemble de "picots" qui montent et descendent afin de permettre de produire du braille de manière dynamique. Selon, les modèles, il peut afficher entre 12 et 80 caractères. Il dispose de touches de navigation, et pour certains, d'un clavier braille ou "ordinaire" qui permet de saisir du texte.
- Smartphones adaptés aux personnes en situation de handicap : des fabricants ont créé des modèles adaptés aux personnes en situation de handicap (écran de taille plus importante, présence de touches pour faciliter la navigation, etc.).
TalkBack et VoiceOver sont des lecteurs d'écran qui restituent vocalement l'application mobile et vos actions sur celle-ci. Un lecteur d'écran pour mobile permet de naviguer dans l'application de deux façons :
- En explorant au toucher, le lecteur d'écran restitue vocalement les éléments sous le doigt.
- En utilisant les gestes de navigation, en balayant vers la droite ou vers la gauche, le focus va se déplacer vers l'élément suivant ou précédent.
Avant d'utiliser TalkBack, il nécessaire d'activer plusieurs options dans le menu Paramètres > Accessibilité > Talkback > Paramètres :
- Activez l'option Explorer au toucher
- Cochez l'option Faire défiler les listes automatiquement
Pour activer TalkBack, procédez comme suit :
- Sélectionnez Paramètres > Accessibilité.
- Suivez les étapes ci-dessous selon votre version d'Android. Découvrez comment vérifier la version de votre appareil Android.
- Android 4.1 ou version ultérieure : sélectionnez TalkBack, puis déplacez le curseur de TalkBack en position activée.
- Android 4.0 : sélectionnez TalkBack, puis déplacez le curseur de TalkBack en position activée. Revenez ensuite à l'écran précédent, puis activez l'option Explorer au toucher.
- Android 3.2 ou version antérieure : cochez les cases Accessibilité et TalkBack.
- L'écran de confirmation vous présente une liste d'autorisations concernant l'exécution d'actions précises, qui vous permettront d'obtenir des commentaires audio utiles. Appuyez sur OK pour confirmer que vous autorisez ces actions et pour commencer à utiliser TalkBack.
Source :
- Sélectionnez Réglages > Général > Accessibilité > Raccourci d’accessibilité
- Sélectionnez VoiceOver
- Vous pouvez maintenant, à tout moment, activer et désactiver VoiceOver en triple cliquant sur le bouton Home.
Les gestes de base permettent de naviguer dans l'application. Le lecteur d'écran lit les éléments en surbrillance. Les gestes permettent de déplacer le focus et d'interagir avec les éléments, un peu à la manière de la navigation clavier sur ordinateur.
Pour déplacer le focus sur l'élément suivant, il faut balayer l'écran vers la droite, c'est l'équivalent de la touche TAB sur PC.
Pour déplacer le focus sur l'élément précédent, il faut balayer l'écran vers la gauche, c'est l'équivalent de la touche SHIFT+TAB sur PC.
Pour sélectionner l'élément mis en surbrillance, il faut appuyer deux fois, c'est l'équivalent de la touche Entrée sur PC.
Pour scroller dans le contenu de l'application, il existe deux mouvements suivant l'utilisation d'Android ou iOS.
Pour scroller avec Android, il faut utiliser deux doigts et glisser dans la direction désirée.
Pour scroller avec iOS, il faut utiliser trois doigts et glisser dans la direction désirée.
Gestes avancés sous iPhone (en anglais)
Lors de l'audit, il est nécessaire de prendre des captures d'écrans pour pouvoir tester les contrastes. Ces captures pourront alimenter le rapport de l'audit.
Pour prendre une capture d'écran sous iOS :
- Appuyer en même temps, sur les boutons Home et Power.
Pour prendre une capture d'écran sous Android > 4.0 :
- Maintenir appuyé en même temps pendant quelques secondes, les boutons Volume bas et Power.
Pour vérifier l'accessibilité de l'application mobile, il est nécessaire de modifier la taille de police lors des test. Voici la procédure selon l'OS.
Pour modifier la taille des caractères sous Android :
- Dans Paramètres > Affichage cliquez sur Taille de police.
- Sélectionnez la taille de police Très grande.
Pour modifier la taille de la police sous iOS :
- Sous iOS 8, rendez-vous dans Réglages > Affichage et luminosité > Taille du texte.
- Sous iOS 7, rendez-vous dans Réglages > Général > Taille du texte.
- Faites glisser le curseur afin d’augmenter ou de réduire la taille de la police.
Source : Modification de la taille de la police
L'auditeur peut faciliter les tests avec le lecteur d'écran en affichant le texte prononcé par la synthèse vocale sous forme de bulle. Elle simplifie aussi les rapports d'audit pour alimenter les impressions d'écran en montrant le focus et la sortie vocale associés à l'écran.
Pour activer l'option, il faut aller dans Paramètres > Accessibilité > Talkback > Paramètres, puis dans la section paramètres du développeur, cliquez sur Activer la sortie vocale.
Pour les utilisateurs d'Android 4.2 et supérieur, il faut débloquer le mode développeur en allant dans Paramètres > À propos du téléphone et taper 7 fois sur l'item Numéro de build, puis revenir à l'écran précédent.
Ensuite, aller dans Paramètres > Options pour les développeurs et dans la section Tracé, cliquez sur l'option Afficher les contours.
Cette option peut se révéler utile pour auditer les problématiques de dimensions sous Android. Notamment pour le critère 14.1 du RGAA.
L'inspecteur est activable seulement en ayant accès au code source de l'application.
Pour activer cette option :
- Importer le projet dans xCode
- Lancer l'application dans un simulateur iOS
- Dans l'environnement simulé, cliquez sur le bouton Home
- Allez dans Paramètres > Général > Accessibilité
- Puis activez l'inspecteur d'accessibilité
Utilisation de l'inspecteur d'accessibilité
- Il est possible d'activer et désactiver l'inspecteur en cliquant sur le bouton de fermeture de la modale se situant en haut à gauche.
- Lorsque l'inspecteur est activé, il est possible de connaître les propriétés d'accessibilité d'un élément en cliquant dessus.
De cette manière, il est possible de faire des captures d'écran plus détaillées sur les éléments de l'application.
Dans l'exemple ci-dessous, on peut mettre en évidence le label (General) et le rôle (Button) d'un élément lors d'une capture d'écran donnant ainsi plus d'informations au développeur pour la correction.
Source : Debug Accessibility in iOS Simulator with the Accessibility Inspector (en anglais)
S'assurer que les zones sensibles ont une taille suffisante pour les lire correctement et être activées facilement avec un doigt. La taille est importante pour les non-voyants explorant au toucher, mais surtout pour les personnes ayant des troubles des mouvements ou de tremblements. Il est recommandé d'utiliser une hauteur et largeur supérieur à 9mm dans les critères RGAA 3 pour le mobile.
Android dispose d'une option permettant d'afficher les contours des éléments. Il vous sera nécessaire de déterminer parmis ces éléments lesquel sont des zones sensible au clique. L'affichage des contours permet de mesurer précisément la taille de la surface sensible qui ne sont parfois pas correctement délimitée dans l'application.
- [Android] Activer l'affichage des contours
- Ouvrir l'application
- Identifier les zones sensibles
- Mesurer leurs tailles avec une règle
- Résultat : Pour chaque zone, la largeur et la hauteur font 9mm au moins.
NB : Sous iOS, il n'y a pas d'option pour afficher les contours. L'utilisation du lecteur d'écran permet de signaler la prise de focus est ainsi mesurer plus facilement la taille de la zone sensible.
L'exemple ci-dessous comporte plusieurs erreurs en surbrillance, ces zones sensibles ont une taille inféreure à 9mm. L'affichage des contours permet ici de se rendre compte de la taille effective des boutons "ABONNEMENTS" et "ABONNÉS" qui ne comporte pas de délimitation dans l'application.
Critère 14.1 Chaque zone sensible a-t-elle une taille suffisante ?
S'assurer que les zones sensibles ont une marge extérieure suffisante pour activer correctement la bonne zone avec un doigt.
Les tests de marge peuvent se révéler difficiles à réaliser, spécialement sous iOS qui ne permet pas d'afficher clairement ce détail.
- [Android] Activer l'affichage des contours
- Ouvrir l'application
- Identifier les zones sensibles
- Vérifier qu'il y a une séparation visuelle entre deux éléments ou qu'il y a un espace inactif entre chaque zone sensible.
- Résultat : Toutes les zones sensibles vérifient l'une des deux conditions.
L'exemple ci-dessous ne comporte pas d'erreur. Il y a bien une marge visible dans la liste des éléments. Sur la version avec les contours, on peut aussi vérifier qu'il y a une marge de 1 pixel entre chaque élément.
Critère 14.1 Chaque zone sensible a-t-elle une taille suffisante ?
Pour faciliter la lecture, la taille du texte peut être augmentée via les options d'accessibilité. La taille du texte ne doit pas être codée en taille fixe mais en taille relative.
- Ouvrir l'application.
- Faire une impression d'écran.
- Activer l'option Grands caractères.
- Vérifier la taille du texte après activation de l'option.
- Résultat : Pour chaque contenu la taille de texte a augmenté, et la lecture n'est pas altérée (i.e. le texte n'est pas tronqué sauf si c'est le comportement attendu et il ne déborde pas).
Une alternative doit être disponible pour chaque image porteuse d'information. Lors de la navigation, un non-voyant aura une information sur le contenu de l'image.
- Activer le lecteur d'écran
- Ouvrir l'application
- Identifier les images porteuses d'information et prendre le focus
- Résultat : Pour chaque image porteuse d'information, une alternative est énoncée par le lecteur d'écran.
Une alternative doit être disponible pour les boutons icônes ou les boutons images.
- Activer le lecteur d'écran
- Ouvrir l'application
- Identifier les boutons image et prendre le focus
- Résultat : Pour chaque bouton images une description permet d'en comprendre la fonction et la destination.
Dans l'exemple de l'application de démonstration Android, le bouton image comporte une erreur, en effet le bouton de suppression n'a pas d'alternative permettant de comprendre sa fonction. Le lecteur restitue Bouton "67" sans libellé.
Il est important de vérifier que le contraste sur mobile est supérieur à 4,5. Il n'existe pas d'application mobile pour vérifier directement ce critère sur le mobile. Il est nécessaire de faire une impression d'écran et de l'envoyer sur un ordinateur pour vérifier les contrastes.
- Ouvrir l'application
- Prendre une capture d'écran
- Envoyer la capture par courriel vers un PC.
- Ouvrir l'image et utiliser la pipette de Colour Contrast Analyser (en anglais).
- Résultat : Vérifier que le contraste est de 4,5:1 au moins pour tout les textes.
Vérifier que l'information n'est pas donnée uniquement par la couleur.
- Ouvrir l'application.
- Identifier tous les éléments utilisant de la couleur.
- Pour chaque élément, l'information ne doit pas être donnée uniquement par la couleur
- Résultat : Une information textuelle équivalente à celle donnée par la couleur est présente dans l'interface.
Vérifier la présence d'un bouton ou d'un lien proche du média temporel pré-enregistré permettant l'affichage d'une alternative textuelle pertinente.
- Ouvrir l'application.
- Identifier chaque média temporel pré-enregistré véhiculant une information.
- Résultat : Pour chaque média restant, il existe un lien adjacente clairement identifiable vers une transcription textuelle pertinente.
Les sous-titres permettent au sourd ou malentendant d'obtenir un équivalent du contenu audio.
- Ouvrir l'application.
- Identifier chaque média temporel pré-enregistré ayant des paroles, commentaires, ou dialogue.
- Résultat : Pour chaque média restant, il est possible de visualiser une version avec sous-titres pertinents.
La lecture automatique de son peut dans certains cas perturber la perception auditive du contenu par l'utilisateur. En effet les non-voyants utilisant un lecteur d'écran, auront alors deux sons en cours de lecture (la synthèse vocale et la lecture automatique) provoquant des confusions sur le contenu de l'application.
- Activer le lecteur d'écran.
- Ouvrir l'application.
- Identifier chaque contenu joué automatiquement durant plus de 3 secondes.
- Pour chaque contenu joué automatiquement, il existe un bouton pour contrôler la lecture.
Critère 4.18 [A] Chaque son déclenché automatiquement est-il contrôlable par l'utilisateur ?
Dans une application mobile, il est courant d'utiliser des notifications sonores pour avertir l'utilisateur. Toute notification sonore doit avoir un système secondaire d'avertissement pour les utilisateurs sourds ou malentendants.
- Activer le lecteur d'écran.
- Ouvrir l'application.
- Pour chaque notification sonore, il existe une alternative visuelle de l'alerte.
No audio-only feedback (en anglais)
Vérifier que le lien ou button est explicite. L'intitulé ou le contexte permet de comprendre la fonction et la destination.
- Activer le lecteur d'écran.
- Naviguer sur les boutons et les liens.
- Résultat : Chaque lien et chaque bouton sont explicites.
Critère 6.1 [A] Chaque lien est-il explicite (hors cas particuliers)
Descriptive links (en anglais)
Pour chaque lien de téléchargement, des informations relatives à sa consultation doivent être présentes.
- Ouvrir l'application.
- Repérer les fichiers en téléchargement non produits de manière dynamique.
- Résultat : Chaque fichier en téléchargement a des informations relatives à son format, à son poids, et si nécessaire, à sa langue.
Pour faciliter la navigation et ne pas perdre l'utilisateur dans l'application, il est nécessaire de placer le menu de navigation au même endroit.
- Ouvrir l'application.
- Naviguer sur l'ensemble des écrans de l'application.
- Résultat : Le menu est toujours à la même place et dans le même ordre relatif des éléments.
Chaque zone de saisie doit avoir un label pertinent. Il est important pour l'utilisateur de comprendre le contenu qu'il doit saisir
- Activer le lecteur d'écran.
- Naviguer sur l'ensemble des zones de saisie de l'application.
- Résultat : Pour chaque champ de saisie :
- le label reste affiché à la prise de focus et après saisie.
- le label est correctement énoncé par le lecteur d'écran et est pertinent.
Critère 11.1 [A] Chaque champ de formulaire a-t-il une étiquette ?
Critère 11.2 [A] Chaque étiquette associée à un champ de formulaire est-elle pertinente ?
Vérifier que chaque champ de saisie est associé à un type de saisie pertinent.
- Activer le lecteur d'écran.
- Naviguer sur l'ensemble des zones de saisie de l'application et ouvrir le clavier.
- Résultat : Pour chaque champ de saisie, le format de saisie est associé à un type de saisie pertinent et le lecteur d'écran annonce le type de clavier.
Keyboard input types (en anglais)
Vérifier que l'intégralité de l'application est correctement restituée par les lecteurs d'écran dans un ordre logique.
- Activer le lecteur d'écran.
- Ouvrir l'application.
- Naviguer sur l'ensemble des éléments de l'application en balayant vers la droite.
- Puis retester en naviguant avec un clavier Bluetooth.
- Résultat : Chaque élément est correctement focusable dans un ordre logique.
Critère 12.13 [A] Dans chaque page Web, l'ordre de tabulation est-il cohérent ?
Vérifier que la prise de focus est correctement signalée.
- Activer le lecteur d'écran.
- Ouvrir l'application.
- Naviguer sur l'ensemble des éléments de l'application en utilisant les gestes de base ou un clavier Bluetooth.
- Résultat : Pour chaque élément la prise de focus est visible.
Éviter les pièges au clavier, empêchant la navigation correcte dans l'application.
- Activer le lecteur d'écran.
- Ouvrir l'application.
- Naviguer sur les éléments de l'application en utilisant les touches Tab, Shift+Tab, Flèches et Entrée.
- Résultat : Pour chaque élément de l'application, il est possible d'atteindre l'élément précédent et suivant.
Sous mobile l'écran doit être rafraîchie uniquement sous l'action de l'utilisateur. Le rafraîchissement d'écran automatique peut empêcher l'utilisateur de terminer une tâche en cours ou créer de la confusion pour l'utilisateur.
- Ouvrir l'application.
- Naviguer sur les éléments de l'application.
- Résultat : L'application n'est pas rafraîchie automatiquement.
Il faut éviter d'afficher des contenus qui changent brusquement de luminosité ou d'utiliser un effet de flash pour éviter de provoquer des crises.
- Ouvrir l'application.
- Naviguer dans l'application.
- Résultat : L'application n'utilise pas de flash plus de trois fois dans l'intervalle d'une seconde.
Le développeur ne doit pas imposer l'orientation du mobile pour accéder au contenu. Le contenu doit être disponible quelle que soit l'orientation.
- Ouvrir l'application.
- Naviguer sur l'écran en mode portrait.
- Naviguer sur l'écran' en mode paysage.
- Résultat : L'application permet d'accéder au même contenu.
Dans cette exemple en erreur le contenu n'est pas consultable en mode portrait.
Source : WTF Mobile (en anglais)
- Référentiel Technique RGAA 3
- Référentiel spécifique aux plateformes mobiles/tactiles
- Mobile Accessibility : How WCAG 2.0 and Other W3C/WAI Guidelines Apply to Mobile
- BBC Standards and Guidelines for Mobile Accessibility
- Verifying App Accessibility on iOS (en anglais)
- Accessibility Testing Checklist on Android (en anglais)
Les guides suivants peuvent être consultés en complément :
- Guide de conception d'applications mobiles accessibles
- Guide de développement d'applications mobiles accessibles avec les API Android et iOS
- Guide de développement d'applications mobiles hybrides accessibles avec Ionic et OnsenUI
Ce document est la propriété du Secrétariat général à la modernisation de l'action publique français (SGMAP). Il est placé sous la licence ouverte 1.0 ou ultérieure, équivalente à une licence Creative Commons BY. Pour indiquer la paternité, ajouter un lien vers la version originale du document disponible sur le compte Github de la DInSIC.
