Introduction
Ce rapport accompagne le relevé d’audit effectué sur l’application « Colis & Courrier POST.LU - Android ».
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 (TalkBack sur Android), ainsi que des tests d’adaptation des contenus en fonction des paramètres d’affichage utilisateurs.
- Version Android lors de l’audit : 13 (Talkback 15.1)
Échantillon
L’audit a été réalisé sur la version de l’application suivante :
- Android : v 3.3.0 - 563
L’audit a porté sur les écrans et parcours suivants :
| Nº écran | Titre de l’écran |
|---|---|
| E01 | Accueil (inclus le parcours d'accueil et les notifications) |
| E02 | Plus (Mon compte, paramètres) |
| E03 | Suivi |
| E04 | Recevoir - Configuration Pack Up |
| E05 | Recevoir - Configuration Pack Up Home |
| E06 | Recevoir - Inscription Courrier électronique |
L'application ne comporte pas de déclaration sur l'accessibilité. Celle-ci est obligatoire d'après l'article 5 de la loi du 28 mai 2019. Cette déclaration s'effectue après avoir réalisé un audit de conformité basé sur le RAAM. Pour créer une déclaration sur base des résultats d'un audit de conformité, le formulaire disponible à cet effet sur accessibilite.lu peut être utilisé. Une fois la déclaration d'accessibilité publiée, l'éditeur du site a 30 jours pour en informer le SIP par mail à l'adresse accessibilite@sip.etat.lu.
Accessibilité des parcours audités
L’application présente un niveau général d’accessibilité faible.
Le niveau de conformité au RAAM relevé atteint 40 % de conformité sur l’ensemble des écrans audités, avec 42,86 % de conformité au niveau simple A (A) et 28,57 % de conformité au niveau double A (AA).
L’application est non conforme.
Conformité RAAM de l’application
| Conforme | Non conforme | |
|---|---|---|
| AA (légal) | 40 % | 60 % |
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 | 42,86 % | 57,14 % |
| AA | 28,57 % | 71,43 % |
Moyenne par écrans
| Nº écran | Titre d’écran | %C |
|---|---|---|
| E01 | Accueil (inclus le parcours d'accueil et les notifications) | 60,87 % |
| E02 | Plus (Mon compte, paramètres) | 54,29 % |
| E03 | Suivi | 70,37 % |
| E04 | Recevoir - Configuration Pack Up | 50 % |
| E05 | Recevoir - Configuration Pack Up Home | 66,67 % |
| E06 | Recevoir - Inscription Courrier électronique | 64,86 % |
Moyenne par thématiques
| Thématiques | C |
|---|---|
| Éléments graphiques | 100 % |
| Couleurs | 33,33 % |
| Multimédia | NA |
| Tableaux | NA |
| Composants interactifs | 20 % |
| Éléments obligatoires | 100 % |
| Structuration | 0 % |
| Présentation | 33,33 % |
| Formulaires | 45,45 % |
| Navigation | 0 % |
| Consultation | 33,33 % |
| 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. Les problèmes liés aux éléments interactifs et aux formulaires rendent parfois difficile l’utilisation de l’application par ces utilisateurs.
Contenus dérogés
La dérogation est un moyen d’exclure du champ d’application du référentiel des contenus particuliers. Les cas de dérogations sont très encadrés, vous en trouverez le détail dans le guide des dérogations.
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 dérogés :
- Ecran d’authentification - LuxID (Service externe)
- Ecran de paiement - Saferpay (Service externe)
- Les documents PDFs sont gérés par les utilisateurs du service et non l'entité POST.LU (Contenus Tiers)
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
L'application est complexe à utiliser pour les personnes naviguant au clavier ou au lecteur d'écran.
Les non-conformités les plus bloquantes pour les utilisateurs concernent :
- La navigation au clavier qui n'est pas assez contrasté, permet de naviguer en arrière-plan et contient de nombreux pièges complexifiant ou empêchant l'accès à certains éléments interactifs.
- Les formulaires (noms accessibles, aides à la saisie manquants et messages d'erreurs notamment)
- Les composants interactifs complexes comme la carte qui n'a pas d'alternative accessible
Ce sont donc ces points qui devront nécessiter une attention toute particulière et qui demanderont le plus d’efforts.
Note: Il a été noté néanmoins que des corrections ont été apportées sur des non-conformités relevées lors de l'audit précédent. En particulier sur les problèmes de contrastes de couleurs des textes et éléments graphiques. Mais également sur la navigation au clavier qui a vu des améliorations non négligeables même si incomplètes ou encore problématiques.
Annexe technique
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.
Contrastes des textes
Plusieurs couleurs présentent un rapport de contraste insuffisant, ce qui peut poser problème aux grands malvoyants et aux déficients visuels qui ont des difficultés à percevoir les couleurs ou les contrastes.
La norme distingue plusieurs tailles de textes à évaluer, chaque taille relevant d’un seuil de contraste. Ces tailles sont évaluées en pixel ou en point. Plus un texte est grand (supérieur à 18,5px avec effet de graisse ou 24px sans effet de graisse) moins le rapport requis est élevé (3:1).
Compte tenu de la difficulté à évaluer les tailles de polices sur mobile, tous les textes devraient être considérés en taille normale sauf pour des textes significativement très grands.
Les textes des applications doivent tous avoir un rapport de contraste de 4.5:1.
Vous pouvez foncer les couleurs pour obtenir le rapport de contraste exigé.
Constats dans l’application
Sur les cartes interactives, on trouve des marqueurs dont le texte n'est pas assez contrasté pour être perceptible avec une couleur blanche #FFFFFF sur fond jaune #FBBD00 (ratio : 1,7)
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
Les puces indiquant les éléments actifs et inactifs dans les carrousels ne sont pas assez contrastées. Elles sont de couleur jaune #F9BD00 et grise #D7D7D7 sur fond blanc #FFFFFF avec respectivement un ratio de contraste de 1,7 et 1,4. De plus, ces couleurs ne sont pas assez contrastées entre elles pour que le changement d'état actif / inactif soit perceptible avec un ratio de contraste de 1,2.
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.
Rôle inapproprié ou non défini
Pour les aveugles et les grands malvoyants qui utilisent un lecteur d’écran, ce manque de distinction claire sur la nature des composants interactifs peut poser de graves problèmes.
En effet, le rôle du composant est annoncé par le lecteur d’écran, ce qui fournit une information contextuelle importante pour l’utilisateur qui peut déduire certaines actions possibles et s’attendre à certains événements.
Enfin, chaque composant interactif doit avoir un nom accessible défini par l’intermédiaire d’un texte (visible ou non) accessible aux technologies d’assistance).
Constats dans l’application
De nombreux éléments interactifs n'ont pas de rôle défini ou pertinent. Par exemple dans les formulaires, les listes déroulantes n'ont pas de rôle défini. Les personnes utilisant un lecteur d'écran ne peuvent savoir que ces éléments sont interactifs.
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
On trouve dans l'application de nombreux éléments interactifs qui n'ont pas de nom accessible. Par exemple les boutons de navigation entre les étapes des parcours de configuration des services PackUp. Les utilisateurs aveugles ici ne peuvent savoir la fonctionnalité de l'élément.
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
Dans les formulaires de nombreux éléments interactifs ne sont pas atteignables et activables au clavier. Notamment les listes déroulantes présentes dans les formulaires.
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
Dans les paramètres de l'application, le composant de sélection de langue n'est pas atteignable avec un lecteur d'écran.
État des composants interactifs
Certains composants peuvent avoir un état, visuellement perceptible, mais non accessible aux utilisateurs aveugles. Par exemple, un bouton sélectionné/non sélectionné, ou un accordéon déplié/replié.
Constats dans l’application
De nombreux composants interactifs comme des boutons à deux états ou bien encore des zones qui affichent et masquent du contenu ne restituent pas leur état courant aux technologies d'assistance. Ce qui va poser des problèmes pour les personnes utilisant un lecteur d'écran
Message de statut
Les messages de statut concernent les messages d’alerte, de confirmation ou d’historisation. Dans tous ces cas, certains utilisateurs, par exemple les personnes aveugles ou les utilisateurs de loupes d’écrans vocalisées, risquent de ne pas prendre connaissance de ces messages si leur restitution n’est pas contrôlée.
Constats dans l’application
À la validation des formulaire d'édition des informations de compte, on message apparait en bas d'écran pour confirmer l'enregistrement. Ce message n'est pas vocalisé. Ce qui constitue une perte d'information pour les personnes aveugles en particulier.
Structuration de l’information
Recommandation
Utiliser des titres, des listes.
Titres
Le titrage des contenus est une étape importante dans la structuration de ces contenus. Cela répond à deux besoins :
- identifier rapidement un contenu recherché ;
- naviguer rapidement dans le contenu en se déplaçant de titre en titre.
Un titrage correct fournit à l’utilisateur d’un lecteur d’écran un plan du document et lui permet de naviguer de titre en titre pour se déplacer plus rapidement dans le contenu.
Constats dans l’application
Sur l’écran d’accueil, les textes « Bonjour », « Suivre mes envois » et « Recevoir mes envois » sont visuellement traités comme étant des titres, de plus ils définissent des sections de contenus précis. Afin de permettre une bonne compréhension de la structure du contenu de l’écran ainsi que faciliter la navigation avec les technologies d'assistance, il est nécessaire de structurer ces textes comme des titres.
Listes
La structuration en listes permet aux utilisateurs de lecteurs d’écran de consulter plus rapidement le contenu, grâce à des raccourcis spécifiques. Elle permet également dans le cas d’une succession de liens de distinguer clairement chaque lien.
Constats dans l’application
Dans les sections "À propos", on trouve des zones de texte organisées visuellement en listes numérotées. Mais la structuration en liste n'est pas présente. Ce qui peut poser des problèmes de compréhension du contenu et de navigation.
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.
Indication de la prise de focus
Afin de permettre la navigation au clavier, il est nécessaire que l'indication d'élément actif soit perceptible par les utilisateurs voyants. Cette indication de focus, si elle est personnalisée doit avoir un ratio de contraste de 3.
Constats dans l’application
Tous les éléments interactifs de l'application ont une indication de focus grise sur fond blanc qui n'est pas assez contrastée
Contenus visibles non accessibles
Certains textes des écrans visibles ne sont pas accessibles aux technologies d’assistance.
Constats dans l’application
Dans les parcours de configuration de services "PackUp", on trouve une section "Horaires" dont la liste d'horaires de la semaine n'est pas atteignable par les lecteurs d'écran.
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
Dans les formulaires de l'application, les champs de saisie, listes déroulantes, cases à cocher ou boutons radio de l'application n'ont pas leur étiquette correctement reliée. Ce qui pose des soucis de compréhension pour l'utilisateur aveugle.
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
-
Certains champs comme "Adresse e-mail" attendent un format particulier. Tant que ce format n'est pas respecté, il n'est pas possible de soumettre le formulaire. Il est donc nécessaire de préciser le format attendu avant la saisie.
-
Les messages d'erreur ne sont pas reliés à leurs champs respectifs.
Regroupements de champs et légendes
Certains utilisateurs, comme les personnes aveugles vont accéder aux champs de formulaires sans avoir la possibilité de consulter les textes qui les entourent. Cela peut poser un problème d’identification de la saisie lorsque celle-ci est associée, visuellement, à une question.
Constats dans l’application
Les groupes de boutons radio comme "Personnel"/"Professionnel" qui sont présentés sous une légende commune "Statut". Cette légende
Saisie des données personnelles
La saisie d’un formulaire peut générer beaucoup d’erreurs plus particulièrement pour les personnes en situation de handicap. Si des saisies relatives aux données personnelles, financières ou juridiques sont désactivées en cours de saisies ces utilisateurs rencontreront beaucoup de difficultés.
Ces informations ne doivent donc pas être désactivées en cours de saisie, l’utilisateur doit pouvoir les récupérer, les modifier ou les supprimer avant l’envoi définitif du formulaire.
Si ce n’est pas possible, un récapitulatif des données saisies doit être proposé avant l’envoi définitif du formulaire avec la possibilité pour chacune d’elle d’être récupéré, modifié ou supprimé.
Constats dans l’application
Dans les formulaires de configuration des services « PackUp », les indications concernant les champs obligatoires se trouvent à la fin du formulaire. Celles-ci devraient se trouver en début de formulaire pour permettre leur bonne compréhension.
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
Les champs "Nom", "Prénom", "Adresse", "Adresse e-mail"… dans les formulaires concernent des données personnelles de l'utilisateur et devraient pouvoir être remplis de manière automatique.
Navigation
Recommandation :
S’assurer que l’ordre de tabulation est cohérent et que l’écran ne comporte pas de piège au clavier. S’assurer que les raccourcis clavier qui utilisent une seule touche sont contrôlables par l’utilisateur.
Ordre de tabulation
La navigation dans les contenus peut être considérablement compliquée pour les personnes aveugles ou les personnes handicapées motrices qui naviguent au clavier si l’ordre de tabulation n’est pas cohérent.
L’ordre de tabulation ne suit pas forcément l’ordre de lecture de l’écran, mais il doit être cohérent en fonction de la nature des contenus et des fonctionnalités.
Constats dans l’application
Il est possible de tabuler sur des éléments non visibles présents en arrière-plan notamment d'autres sections de l'application.
Ordre de restitution
L’ordre d’accès aux composants d’interface par le lecteur d’écran peut être différent de l’ordre de navigation à l’aide d’un clavier externe (sans utilisation d’un clavier), bien que parfois, les deux partagent les mêmes comportements.
Constats dans l’application
Certains éléments ne sont pas parcourus dans un ordre qui permette que l'information contenue soit compréhensible. Par exemple dans les sections "À propos", on trouve des informations qui sont présentées visuellement sous forme de tableau de données, avec les en-têtes sur la première ligne et les données sur la seconde. Lorsqu'on consulte ce contenu à l'aide d'un lecteur d'écran
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.
Gestes complexes
Certaines personnes handicapées motrices ne peuvent pas réaliser de gestes complexes, elles utilisent généralement des technologies d’assistance qui leur permettent d’interagir uniquement avec un geste simple comme cliquer sur un bouton par exemple.
Dans ces situations, il est indispensable que l’application propose pour chaque fonctionnalité basée sur un geste complexe une alternative au moyen d’un geste simple.
Le geste complexe nécessite l’utilisation d’un contact multipoint, comme utiliser deux doigts pour zoomer ou dézoomer, ou tracer une trajectoire.
Le geste simple peut être un contact sur un seul point ou toute variation multiple de ce contact (double clic, etc.).
Constats dans l’application
Dans les carrousels, il n'y a pas d'alternative à l'utilisation du geste complexe "swipe".
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
L'application ne peut être consultée qu'en affichage portrait.