Introduction

Ce rapport accompagne le relevé d’audit effectué sur l’application «LLO.lu».

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 : 17.1.1

Échantillon

L’audit a été réalisé sur la version de l’application suivante :

iOS : 1.42.3

L’audit a porté sur les écrans et parcours suivants :

Échantillon de l’audit
Nº écran Titre de l’écran
E01 Authentification
E02 Accueil
E03 Mentions légales
E04 Contact
E05 Parcours 1: Évaluation
E06 Parcours 2: Apprentissage
E07 Parcours 3: Toutes les leçons
E08 Parcours 4: Paramètres et profil

Accessibilité des parcours audités

L’application présente un niveau général faible d’accessibilité.

Le niveau de conformité au RAAM relevé atteint 26,42 % de conformité sur l’ensemble des écrans audités, avec 24,39 % de conformité au niveau simple A (A) et 33,33 % de conformité au niveau double A (AA).

L’application est non conforme.

Conformité RAAM de l’application

Conformité RAAM
Conforme Non conforme
A 24,39% 75,61%
AA (légal) 26,42% 73,58%

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

Conformité pour chaque niveau
Conforme Non conforme
A 24,39% 75,61%
AA 33,33% 66,67%

Moyenne par écrans

Nº écran Titre d’écran %C
E01 Authentification 46,67%
E02 Accueil 54,55%
E03 Mentions légales 52,17%
E04 Contact 64,29%
E05 Parcours 1: Évaluation 30,43%
E06 Parcours 2: Apprentissage 63,33%
E07 Parcours 3: Toutes les leçons 63,33%
E08 Parcours 4: Paramètres et profil 70,37%

Moyenne par thématiques

Thématiques C
Éléments graphiques 0,00%
Couleurs 25,00%
Multimédia 50,00%
Tableaux 0,00%
Composants interactifs 20,00%
Éléments obligatoires 0,00%
Structuration 0,00%
Présentation 28,57%
Formulaires 10,00%
Navigation 66,67%
Consultation 40,00%
Documentation et fonctionnalités d’accessibilité 50,00%

Impacts utilisateurs

Les principales personnes impactées sont les personnes aveugles et celles qui naviguent au clavier. Les problèmes liés aux boutons et aux formulaires rendent parfois difficile l’utilisation de l’application par ces utilisateurs.

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 les problèmes de contraste, le relevé mentionne quelques occurrences, mais ne les cite pas toutes.

Avis

les fonctionnalités centrales de l’application, en particulier les leçons et exercices sont entièrement inaccessibles ou difficiles à utiliser pour les personnes qui naviguent avec un lecteur d’écran ou avec un clavier. De nombreux textes et éléments d’interface ont un contraste insuffisant ce qui peut rendre l’utilisation de l’application très compliquée pour les personnes ayant une déficience visuelle.

Les non-conformités les plus bloquantes pour les utilisateurs concernent :

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 de décoration

Un élément graphique de décoration ne contient aucune information indispensable à la compréhension du contenu auquel il est associé. Il est important que ces éléments graphiques ne soient pas restitués aux utilisateurs de technologies d’assistance, par exemple les aveugles avec un lecteur d’écran.

Constats dans l’application

Sur le formulaire d’authentification, les images « @ » et « cadenas » ne sont pas ignorées des technologies d'assistance.

Sur la page d’accueil, dans la liste de leçons, l’image « flèche » n’est pas ignorée et est restituée par les technologies d'assistance.

Sur les webviews des mentions légales, l’image qui accompagne le titre principal de la page n’est pas ignorée des technologies d'assistance.

É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

Sur la page d’accueil, dans la liste des leçons, l’image « sablier » ayant pour alternative « In progress » qui est en anglais.

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 l’écran d’accueil, le texte d’aide à la saisie « Le mot de passe doit contenir au moins 8 caractères » ainsi que le texte de l’élément actif dans le système d’onglet présent en bas de l’écran de couleur grise #8C8F9A n’est pas assez contrasté avec la couleur de fond blanche #FFF (ratio : 3,2)

Sur l’écran des mentions légales, les liens en environnement de texte de couleur rose #E33B7A sur fond blanc #FFF (ratio : 4,1)

Sur les écrans des exercices, les textes présents en haut d’écran comme « Test de niveau – Luxembourgeois » de couleur grise #AAADB7 sur fond gris clair #F6F6F6 (ratio : 2,1)

Les textes des énoncés des exercices sont de couleur grise #988C96 sur fond blanc #FFFFFF (ratio : 3,4)

Les textes dans les champs de saisie du formulaire de contact sont de couleur #BBAFA8 sur fond #F5F5F5 (ratio 2,1)

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 icônes inactives du système d’onglet de couleur rose #DD9597 sur fond blanc #FFFFFF (ratio : 2,4)

Les champs de saisie du formulaire de contact sont de couleur #F5F5F5 sur fond blanc #FFFFF (ratio 1,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 page d’authentification, l’indication de champ en erreur n’est donnée que par la couleur.

Multimédia

Recommandation

Donner si nécessaire à chaque média temporel une transcription textuelle, des sous-titres synchronisés et une audiodescription synchronisée pertinents. Rendre possible le contrôle de la consultation de chaque média temporel et non temporel au clavier et s’assurer de leur compatibilité avec les technologies d’assistance.

Identifier les vidéos

Il est nécessaire d’identifier la vidéo et permettre ainsi aux utilisateurs de comprendre quelle est l’information présentée dans ce contenu.

Vous disposez de deux méthodes pour le faire :

Constats dans l’application

Dans les exercices de compréhension de vidéo, les lecteurs vidéo ne sont pas clairement identifiés avec un titre précédent ou un texte adjacent.

Sous-titres

Chaque vidéo doit disposer de sous-titres synchronisés pertinents, pour permettre aux utilisateurs sourds ou malentendants d’accéder au contenu oralisé de la vidéo.

L’utilisateur doit pouvoir activer ou désactiver les sous-titres depuis le lecteur vidéo. Si ce n’est pas possible, une solution consiste à fournir deux versions de la même vidéo : une version sans sous-titres et une version sous-titrée (On fera ensuite un lien réciproque de l’une vers l’autre).

Constats dans l’application

Dans les exercices de type compréhension orale présentant des vidéos, des sous-titres sont bien présents, mais il n’est pas possible de personnaliser leur affichage.

Tableaux

Recommandation :

Donner un résumé à chaque tableau de données complexe, s’assurer que pour chaque tableau de données dispose d’un titre pertinent, s’assurer que les en-têtes de chaque cellule de données sont correctement reliés.

Tableaux de données

Un tableau de données doit répondre à certains enjeux pour être exploité correctement par les lecteurs d’écrans. Les enjeux sont les suivants :

Constats dans l’application

Sur la page de mentions / politique de confidentialité, on trouve des tableaux dont le titre n’est pas associé correctement au tableau et dont les en-têtes de ligne ne sont pas déclarés correctement.

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

Sur la page d’authentification, le composant permettant d'afficher ou de masquer le mot de passe saisie n'a pas de rôle présenté aux technologies d'assistance.

Dans les conditions générales, le composant « menu » n’est pas restitué correctement par les technologies d'assistance. Il n’a pas de rôle, ni de nom accessible.

Sur l’écran d’accueil et les exercices :

Intitulé absent ou non pertinent

Pour chaque composant interactif, deux éléments sont à prendre en compte :

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 les écrans contenant des vidéos accompagnées de sous-titres, on trouve un bouton pour passer du luxembourgeois à la langue principale définie. Mais ce bouton n’a pas un intitulé pertinent permettant de comprendre son action.

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

Les listes de réponses des exercices ne peuvent être atteintes avec le clavier.

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

Certains exercices ont des intitulés qui peuvent être traduits au tap sur un mot qui fait apparaitre une fenêtre modale. Il n’est pas possible d’utiliser cette fonctionnalité au 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

Dans le profil, la vue des activités est présentée sous forme de graphique. Ce graphique est accompagné de boutons « Mois/Année » dont l’état actif n’est pas restitué par les technologies d'assistance.

Fenêtres modales

Les fenêtres modales doivent être signalées et correctement restituées aux technologies d'assistance.

Constats dans l’application

Certains exercices ont des intitulés qui peuvent être traduits au tap sur un mot qui fait apparaitre une fenêtre modale. Cette fenêtre modale n’est pas restituée correctement par les technologies d'assistance.

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

Le message d’alerte « Identifiant et/ou mot de passe incorrect(s), veuillez réessayer » n’est pas restitué par les technologies d'assistance.

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

Lors du passage d’une question à la suivante, lorsqu’on déclenche le bouton suivant au clavier, le focus n’est pas replacé en haut de l’écran mais reste sur le bouton activé. Ce qui pose des problèmes aux personnes qui utilisent un lecteur d’écran ou naviguer au clavier.

É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

Dans les paramètres de l’application, il est possible de choisir la langue de l’interface et celle-ci est bien mise à jour, le problème étant lorsque du texte en Luxembourgeois est prononcé avec une synthèse vocale correspondant à une autre langue. Ce qui pose un problème pour la compréhension des énoncés en Luxembourgeois.

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 :

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 des intitulés de mission comme « Mission - Iwwer seng Wunnsituatioun schwätzen » ou « Iwwer seng Famill schwätzen » doivent être des en-têtes afin de structurer correctement le contenu et faciliter leur accès au lecteur d'écran.

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

Les listes de leçons ne sont pas identifiées comme des listes.

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.

Contenus visibles non accessibles

Certains textes des écrans visibles ne sont pas accessibles aux technologies d’assistance.

Constats dans l’application

Dans la section "Compréhension orale", le texte "Encore X écoutes" ne peut jamais être atteint avec le lecteur d'écran

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 nombreux éléments à travers l’application ne voient pas leur taille augmenter lors de la modification de la taille de texte dans les options du système. De plus, pour les éléments qui sont bien agrandis, ceux-ci sont généralement tronqués.

Composant dans des environnements de texte

Lorsque des composants (liens, boutons) sont insérés dans un bloc de texte et qu'ils ne sont signalés que par la couleur, les personnes déficientes visuelles risquent de ne pas les identifier si la couleur des liens n'est pas suffisamment contrastée par rapport à la couleur du texte.

Constats dans l’application

Sur l’écran d’authentification, le lien « Se connecter » n’est pas assez contrasté avec le texte environnant : le lien est rouge #C03137 et a un rapport de contraste insuffisant par rapport à la couleur du texte environnant #353C4E (ratio : 2)

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 la page d’authentification, les champs de saisie « Adresse e-mail » et « Mot de passe » n’ont pas d’étiquettes toujours visibles correctement restituées par les technologies d'assistance.

Intitulés de bouton pertinents

Les boutons qui permettent d’interagir avec les formulaires doivent avoir des intitulés pertinents pour que l’utilisateur comprenne l’action du bouton.

Ces intitulés sont essentiels pour les personnes aveugles, afin qu’elles soient sûres de l’action qu’elles s’apprêtent à réaliser.

Constats dans l’application

Sur la page d’authentification, le bouton « Continuer » est trop générique et peut poser des soucis de compréhension aux personnes atteintes d’un handicap intellectuel.

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

Sur le formulaire de contact, le champ « Adresse e-mail » attend un format particulier qui n’est pas précisé et le message d’erreur associé ne propose pas d’exemple de saisie réelle.

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 la page d’authentification, les champs « identifiant » et « mot de passe » ne sont pas identifiés pour permettre un remplissage automatique des informations personnelles de l’utilisateur.

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

Sur la page d’accueil, la liste de leçons ne peut jamais être atteinte au clavier.

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.

Accessibilité des documents en téléchargement

Assurez-vous que chaque document soit accessible (cf. les Guides de créations de documents bureautiques accessibles et liste des critères Documents bureautiques en téléchargement (format Docx, 66 kilo-octets)), ou qu’il dispose d’une alternative accessible proposant le même contenu (par exemple, une version HTML correctement structurée).

Constats dans l’application

Dans la gestion du profil de l’utilisateur, il est possible de télécharger une attestation du niveau de langue atteint. Ce document généré au format PDF n’est pas balisé et ne peut être restitué par les technologies d'assistance.

Le contenu de l’application ne peut être considéré comme une alternative valable car on n’y retrouve pas l’intégralité du contenu de celui-ci.

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

Sur l’écran « Toutes les leçons », on trouve des carrousels que l’on peut faire défiler par un geste de glisser (swipe). Mais ces carrousels ne proposent pas de méthode alternative simple pour remplacer cette fonctionnalité.