Introduction
Ce rapport accompagne le relevé d’audit effectué sur l’application « Adapto ».
L’évaluation pour les applications mobiles consiste à vérifier l’ensemble des critères de la norme européenne d’accessibilité pour les produits et services EN 301 549 (v3.2.1). La méthodologie de test se base sur le Référentiel d’évaluation de l’accessibilité des applications mobiles (RAAM 1).
L’audit a été réalisé à l’aide des technologies d’assistance disponibles, des tests de restitution avec le lecteur d’écran du système d’exploitation (VoiceOver sur iOS, TalkBack sur Android), ainsi que des tests d’adaptation des contenus en fonction des paramètres d’affichage utilisateurs.
- Version iOS lors de l’audit : 15.6
Échantillon
L’audit a été réalisé sur la version de l’application suivante :
- iOS : 4.2
L’audit a porté sur les écrans et parcours suivants :
| Nº écran | Titre de l’écran |
|---|---|
| E01 | Connexion |
| E02 | Mot de passe oublié |
| E03 | Mon compte |
| E04 | Ajouter un voyage |
| E05 | Réservations |
| E06 | Prochains voyages |
| E07 | Favoris |
| E08 | Partager |
| E09 | Nous contacter |
Accessibilité des parcours audités
L’application présente un niveau général d’accessibilité moyen.
Le niveau moyen de conformité au RAAM relevé atteint 53,13 % de conformité sur l’ensemble des écrans audités, avec 57,69 % de conformité au niveau simple A (A) et 33,33 % de conformité au niveau double A (AA).
L’application est partiellement conforme.
Conformité RAAM de l’application
| Conforme | Non conforme | |
|---|---|---|
| A | 57,69% | 42,31% |
| AA (légal) | 53,13% | 46,87% |
Note sur le calcul de conformité
La conformité globale (Tableau « Conformité RAAM 1 ») est calculée de la manière suivante : C / (C+NC). C est le nombre de critères conformes et NC le nombre de critères non conformes.
C’est ce nombre qui constitue la référence légale. Il représente le taux de conformité de l’échantillon.
Il est normal que le taux de conformité global diffère sensiblement du taux de conformité par écran. En effet, un critère NC (non conforme) sur un écran rend le critère non conforme sur l’ensemble de l’échantillon.
Pour qu’une application soit conforme (100 % des critères applicables sont conformes au niveau AA), il est nécessaire que le taux de conformité par écran équivaille à 100 %.
Conformité pour chaque niveau
| Conforme | Non conforme | |
|---|---|---|
| A | 57,69% | 42,31% |
| AA | 33,33% | 66,67% |
Moyenne par écrans
| Nº écran | Titre d’écran | %C |
|---|---|---|
| E01 | Connexion | 84,62% |
| E02 | Mot de passe oublié | 85,71% |
| E03 | Mon compte | 95,00% |
| E04 | Ajouter un voyage | 68,42% |
| E05 | Réservation | 94,12% |
| E06 | Prochains voyages | 89,47% |
| E07 | Favoris | 95,83% |
| E08 | Partager | 100,00% |
| E09 | Nous contacter | 100,00% |
Moyenne par thématiques
| Thématiques | C |
|---|---|
| Éléments graphiques | 50,00% |
| Couleurs | 33,33% |
| Multimédia | NA |
| Tableaux | NA |
| Composants interactifs | 40,00% |
| Éléments obligatoires | 0,00 |
| Structuration | 100,00% |
| Présentation | 75,00% |
| Formulaires | 55,56% |
| Navigation | 66,67% |
| Consultation | 66,67% |
| Documentation et fonctionnalités d’accessibilité | NA |
| Services d’assistance | NA |
| Outils d'édition | NA |
| Communication en temps réel | NA |
Impacts utilisateurs
Les principales personnes impactées sont les personnes aveugles et celles qui naviguent au clavier. L’impossibilité d’atteindre certains composants au clavier ou aux technologies d'assistance et l'absence de restitution de certains composants rendent parfois l'utilisation de l'application difficile pour ces personnes-là.
Contenus exemptés
Les contenus suivants n’entrent pas dans le calcul de la conformité ni dans le périmètre des éléments à rendre accessible, ils sont exemptés :
- Service de cartographie
Droit à la compensation
Les dérogations émises notamment pour charge disproportionnée demandent en contrepartie la mise en place d’un moyen de compensation pour les utilisateurs. Pour les documents bureautiques par exemple, vous devez fournir un moyen à l’utilisateur de demander une version accessible d’un document s’il en a besoin. Cela peut être un mail ou un formulaire de contact.
Note sur le relevé des non-conformités
Ne sont cités dans ce rapport que quelques exemples issus du relevé des non-conformités.
De plus, toutes les occurrences d’une non-conformité ne sont pas listées dans le relevé. Par exemple : pour [donner un exemple issu du relevé], le relevé mentionne quelques occurrences, mais ne les cite pas toutes.
Avis
La structure de l'application est particulièrement robuste, notamment sur la navigation à l'aide de technologies d'assistance. Quelques points bloquants persistent, notamment en ce qui concerne les formulaires et la navigation au clavier.
Les non-conformités les plus bloquantes pour les utilisateurs concernent :
- L'impossibilité d'atteindre certains composants interactifs (au clavier et à l'aide de technologies d'assistance)
- L'absence d'intitulé pertinent sur certains composants
- Les erreurs du formulaire de connexion.
Ce sont donc ces points qui devront nécessiter une attention toute particulière et qui demanderont le plus d’efforts.
Annexe technique
Éléments graphiques
Recommandation
Identifier les éléments graphiques de décoration pour qu’ils soient ignorés par les technologies d’assistance. Donner à chaque élément graphique porteur d’information une alternative textuelle pertinente et une description détaillée si nécessaire. Remplacer les éléments graphiques textes par du texte stylé lorsque c’est possible.
Éléments graphiques porteurs d’information
Un élément graphique est considéré comme porteur d’information lorsqu’il contient une information indispensable à la compréhension du contenu auquel il est associé. Il est indispensable que ces informations soient restituées, par exemple aux utilisateurs aveugles qui se servent d'un lecteur d’écran.
Constats dans l’application
On note que sur l'écran "Prochains voyages" l'icône indiquant le nombre de personnes prévues est sans alternative. Seul le nombre est restitué, l’utilisateur ne sait donc pas à quelle information ce nombre se rapporte.
Couleurs
Recommandation
Ne pas donner l’information uniquement par la couleur et utiliser des contrastes de couleurs suffisamment élevés pour les textes et les composants d’interface et les éléments graphiques.
Contraste des composants d’interface
Les composants d’interface, les illustrations porteuses d’information ou encore les mises en couleurs porteuses d’information doivent être suffisamment contrastés pour être perçus par les utilisateurs ayant des troubles de perception des couleurs. Par exemple, une icône porteuse d’information devra avoir un rapport de contraste avec la couleur de fond de 3. De même, pour un champ de saisie de formulaire, dont la zone active est matérialisée par sa bordure, alors la couleur de cette bordure devra avoir un rapport de contraste de 3 avec la couleur de fond de l’écran.
Constats dans l’application
Sur l'étape 1 sur 4 du processus de réservation, les champs de saisie de la zone "Notes de transport" ne sont pas suffisamment perceptibles. Seule la couleur du texte des placeholder (#C4C1C5) permet de définir la zone de saisie par rapport à la couleur de fond (#FFFFFF) créant un rapport de contraste de seulement 1.8:1.
Information par la couleur
Lorsqu’une information est donnée par la couleur, il faut qu’elle soit également véhiculée par une autre méthode, par exemple par un texte qui donne la même information, pour être perçue par les utilisateurs aveugles.
Il faut également donner un indice visuel autre que la couleur, afin de répondre aux besoins des personnes déficientes visuelles (les daltoniens par exemple). Il peut s’agir d’un symbole, d’une texture, de chiffres.
Constats dans l’application
Sur la carte présentant un trajet, on note la différence entre le point de départ et le point d'arrivée uniquement par la couleur (couleur rouge et noire des marqueurs de carte).
Pour le cas des choix de "transports réguliers", les jours sélectionnés ne sont indiqués que par la couleur (fond et texte) du composant.
Composants interactifs
Recommandation :
Donner si nécessaire à chaque composant interactif une alternative pertinente. Rendre possible le contrôle de chaque composant interactif au moins par le clavier et la souris et s’assurer de leur compatibilité avec les technologies d’assistance. Identifier les messages de statut lorsque c’est nécessaire.
Intitulé absent ou non pertinent
Pour chaque composant interactif, deux éléments sont à prendre en compte :
- Le nom accessible doit être pertinent ;
- Le nom visible doit être contenu dans le nom accessible.
Le nom accessible est le nom effectivement restitué par les technologies d’assistance comme le lecteur d’écran. Ce nom accessible est différent du nom visible dans les cas où l’application emploie certaines propriétés (comme les propriétés de nommage d’accessibilité des plateformes, dont le contenu n’est pas visible, mais est restitué par les lecteurs d’écran).
Constats dans l’application
Sur le processus d'enregistrement d'une réservation, on note plusieurs erreurs, par exemple : les boutons + et - permettant de sélectionner le nombre de personnes à transporter sans un intitulé suffisamment pertinent ("ic minus" et "ic add") De plus, le moteur de recherche d'une adresse ne restitue pas qu'il s'agit d'une recherche avec autocomplétion.
Clavier et dispositifs de pointage
Tous les éléments interactifs doivent être utilisables (atteignables et activables) par différents systèmes de pointage, par exemple : au toucher, avec un clavier externe (raccordement d’un clavier externe bluetooth ou USB et navigation avec les touches tabulation et flèches de direction), à la voix (VoiceControl sur iOS, Voice Access sur Android).
Constats dans l’application
Sur les écrans de réservation, plusieurs composants ne sont pas atteignables au clavier :
- le composant "Adresse d'arrivée souhaitée"
- la liste d'élément en autocomplétion
- les boutons permettant de retourner à l'étape précédente.
Lecteur d’écran
Les composants interactifs doivent tous être accessibles au lecteur d’écran. Sous Android il s’agit de TalkBack et sous iOS, de VoiceOver.
Certains composants des interfaces de l’application ne sont pas atteignables avec le lecteur d’écran et d’autres sont atteignables, mais pas activables.
Constats dans l’application
On note de nombreux composants qui ne sont pas atteignables par les technologies d'assistance, notamment sur le processus de réservation (étape 3 sur 4) empêchant la sélection des dates et heures de départ et d'arrivée.
Changement de contexte
Un changement de contexte est une situation où un utilisateur ne peut pas anticiper le fonctionnement d’une fonctionnalité lorsque celle-ci ouvre une nouvelle application, valide un formulaire ou ajoute ou modifie du contenu dans l’écran par exemple.
Cela concerne plus spécifiquement les fonctionnalités qui se lancent sans que l’utilisateur puisse les anticiper comme, par exemple, la soumission automatique d’un champ de formulaire sur la sélection d’un item ou lorsque l’utilisateur quitte un champ de saisie.
Constats dans l’application
Sur l'écran initial de création d'une réservation, la saisie de l'adresse de destination déclenche un changement de contexte avec la redirection automatique vers l'écran suivant.
Éléments obligatoires
Recommandation
Vérifier que chaque écran a une indication de langue par défaut.
Indication de langue
Les lecteurs d’écran utilisent l’indication de langue principale pour vocaliser correctement le contenu. L’application doit avoir déclaré la langue de traitement principal afin qu’elle soit vocalisée correctement par les lecteurs d’écran.
Constats dans l’application
Les boutons permettant de fermer les fenêtres modales sont en langue anglaise : "Close"
Présentation de l’information
Recommandation
Vérifier la prise en charge des paramètres de taille de police et l’effet de l’agrandissement des tailles des caractères sur la lisibilité. S’assurer que les composants sont correctement identifiables. S’assurer que l’information n’est pas donnée uniquement par la forme ou la position d’un élément.
Ordre réel des contenus
Certains utilisateurs comme les personnes aveugles vont parcourir les contenus dans l’ordre dans lequel ils sont déclarés dans l’application, indépendamment de l’ordre visuel dans la présentation à l’écran. Il est important que cet ordre soit logique et cohérent pour éviter les pertes d’informations et les incompréhensions.
On teste l’ordre réel des contenus en naviguant avec un lecteur d’écran.
Constats dans l’application
Sur l'écran de création d'une réservation, on note plusieurs problèmes de cohérence dans l'ordre d'accès aux éléments. Par exemple, un composant non présent visuellement est atteignable par les technologies d'assistance, des repositionnements de focus nécessaires (perte de focus) et surtout, des composants non atteignables par les technologies d'assistance bloquant la possibilité de créer une réservation.
Agrandissement des textes
Certaines personnes déficientes visuelles, également des personnes ayant des difficultés de lecture comme les personnes dyslexiques, ont besoin d’adapter la taille du texte à l’écran.
L’agrandissement des caractères ne doit pas provoquer de perte d’informations. À 200%, le contenu doit rester lisible et compréhensible, toutes les informations doivent rester présentes.
L’utilisateur spécifie la taille des caractères au niveau de la plateforme, en utilisant les paramètres de présentation système.
Constats dans l’application
De manière générale, sur toute l'application, les textes ne sont pas impactés par le paramétrage d'agrandissement de texte.
Formulaires
Recommandation :
Associer pour chaque formulaire chacun de ses champs à son étiquette, grouper les champs dans des blocs d’informations de même nature, donner à chaque bouton un intitulé explicite. Vérifier la présence d’aide à la saisie, s’assurer que le contrôle de saisie est accessible et que l’utilisateur peut contrôler les données à caractère financier, juridique ou personnel.
Étiquettes et champs
Les champs de formulaires doivent tous posséder des étiquettes correctement reliées.
Une étiquette de champ est un texte situé à proximité du champ de formulaire qui permet de connaître la nature, le type ou le format des informations attendues.
De cette manière, lorsqu’un utilisateur entre dans le champ de saisie avec un lecteur d’écran, le lecteur d’écran lit le contenu de l’étiquette. L’utilisateur comprend alors ce qu’il doit saisir.
Sans cela, même si une étiquette est présente visuellement, l’utilisateur entendra « champ de saisie vide » en entrant dans le champ et ne saura donc pas quoi saisir.
Constats dans l’application
Sur l'écran d'ajout aux favoris, les étiquettes visibles "Domicile" et "Travail" ne sont pas identiques aux noms accessibles restitués aux technologies d'assistance : "Favoris".
Contrôle de saisie et aide à la saisie
Tous les champs obligatoires doivent être identifiés préalablement à toute validation de l’utilisateur.
Pour les champs qui attendent un format de saisie particulier pour être validés, ce format doit être spécifié à l’utilisateur par un passage de texte visible à proximité du champ. De plus, si l’utilisateur commet une erreur sur ce champ, alors le message d’erreur doit présenter un exemple réel de saisie.
Enfin, les messages d’erreur de saisie des champs de formulaire doivent être liés correctement aux champs en erreur.
Constats dans l’application
On note sur le formulaire de connexion l'absence d'indication des champs obligatoires.
Indication de la nature des saisies
La saisie d’un formulaire peut être particulièrement laborieuse et nécessiter des charges de travail considérables pour certains utilisateurs qui vont utiliser des technologies d’assistance très complexes ou qui ne sont pas capables de comprendre les types de données attendues.
Identifier les champs de saisie pour permettre leur remplissage automatique est bénéfique pour certains utilisateurs.
Ces indications peuvent être utilisées par la plateforme pour proposer des fonctionnalités de remplissage automatique des champs ainsi identifiés et également pour disposer des contrôles adéquats pour remplir les champs (clavier numérique par exemple). Ce dispositif peut être d’une aide considérable pour les utilisateurs. Cela concerne plus spécifiquement les données à caractère personnel.
Constats dans l’application
Sur les écrans de connexion, le champ "E-mail" attend une donnée personnelle sans proposer une fonctionnalité de remplissage automatique.
Consultation
Recommandation
Vérifier que l’utilisateur a le contrôle des procédés de rafraîchissement, des changements brusques de luminosité et des contenus en mouvement ou clignotants. Ne pas faire dépendre l’accomplissement d’une tâche d’une limite de temps sauf si elle est essentielle et s’assurer que les données saisies sont récupérées après une interruption de session authentifiée. Proposer des versions accessibles ou rendre accessibles les documents en téléchargement. S’assurer que la consultation n’est pas dépendante de l’orientation de l’écran. Toujours proposer un geste simple en alternative d’un geste complexe permettant de réaliser une action.
Consultation des contenus indépendante de l’orientation
Certaines personnes handicapées motrices peuvent utiliser des périphériques dont elles ne peuvent pas contrôler l’orientation. Par exemple les personnes qui utilisent des contacteurs pour interagir avec le périphérique de consultation. D’autres, comme les personnes déficientes visuelles peuvent avoir besoin de forcer un mode d’affichage (paysage par exemple) pour pouvoir bénéficier des fonctionnalités d’agrandissement des caractères.
Il est donc nécessaire que les applications :
- Ne bloquent pas l’orientation sur un mode portrait ou paysage ;
- S’assurent que les contenus sont consultables dans les deux modes d’affichage.
Constats dans l’application
De manière générale, sur toute l'application, le contenu n'est pas consultable en mode paysage