RAAM 1 : Critères et tests

Avertissement : Pour chaque critère du référentiel, une méthodologie d’évaluation est proposée. Néanmoins, cette méthodologie n’a pas de valeur normative, c’est-à-dire qu’elle n’est fournie qu’à titre d’aide à la prise en main du référentiel, en donnant un exemple d’une méthode possible d’évaluation mais il peut exister d’autres méthodes d’évaluation. De plus, le contenu de cette méthodologie ainsi que ces étapes ne peuvent pas constituer une base opposable en cas de contestation. Enfin, il est possible que des erreurs ne soient pas détectées sur la seule base de cette méthodologie. Seul le contenu du critère et des tests ont une valeur normative.

Note concernant les vues web : dans les applications, certains écrans (ou tous les écrans) sont des pages web embarquées, appelées aussi vues web ou web views. Si le contenu de ces vues web est sous la responsabilité de l’éditeur de l’application, alors elles devront se conformer au présent référentiel au même titre que les autres écrans de l’application développés dans un langage propre aux applications mobiles. Si ces vues web ne sont pas sous la responsabilité de l’éditeur, leur contenu pourra être dérogé. Néanmoins, en fonction de l’importance pour les utilisateurs du contenu, il pourra être exigé une alternative ou un moyen de compensation.

Thématique 1 : Éléments graphiques

Critère 1.1 [A] Chaque élément graphique de décoration est-il ignoré par les technologies d’assistance ?

Méthodologie d’évaluation
iOS et Android
  1. Activer le lecteur d’écran.
  2. Repérer dans l’écran les éléments graphiques décoratifs (voir la note de glossaire concernant les particularités de restitution).
  3. Vérifier :
    • qu’ils ne peuvent pas être atteints avec le lecteur d’écran ;
    • que leur contenu n’est pas restitué par ailleurs depuis un autre élément dans l’écran.
  4. Si c’est le cas, le critère est validé.
Correspondances

Critère 1.2 [A] Chaque élément graphique porteur d’information possède-t-il une alternative accessible aux technologies d’assistance ?

Méthodologie d’évaluation
iOS et Android
  1. Activer le lecteur d’écran.
  2. Repérer dans l’écran les éléments graphiques porteurs d’informations (voir la note de glossaire concernant les particularités de restitution), par exemple, une image ou une icône.
  3. Vérifier :
    • qu’ils peuvent être atteints avec le lecteur d’écran ;
    • ou que l’information qu’ils véhiculent est restituée depuis un autre élément dans l’écran.
  4. Si c’est le cas, le critère est validé.
Correspondances

Critère 1.3 [A] Pour chaque élément graphique porteur d’information, l’alternative accessible aux technologies d’assistance est-elle pertinente (hors cas particuliers) ?

Cas particuliers

Le critère est non applicable lorsque l’élément graphique est utilisé comme CAPTCHA ou comme élément graphique de test. Dans cette situation, où il n’est pas possible de donner une alternative pertinente sans détruire l’objet du CAPTCHA ou du test, le critère est non applicable.

Note : le cas des CAPTCHAs et des éléments graphiques tests est traité de manière spécifique par le critère 1.4.

Méthodologie d’évaluation
iOS et Android
  1. Activer le lecteur d’écran.
  2. Repérer dans l’écran les éléments graphiques porteurs d’information (voir la note de glossaire concernant les particularités de restitution).
  3. Vérifier :
    • que l’alternative restituée par le lecteur d’écran est pertinente ;
    • ou que l’information restituée depuis un autre élément dans l’écran est pertinente.
  4. Si c’est le cas, le critère est validé.
Correspondances

Critère 1.4 [A] Pour chaque élément graphique utilisé comme CAPTCHA ou comme élément graphique de test, l’alternative restituée par les technologies d’assistance permet-elle d’identifier la nature et la fonction de l’élément graphique ?

Méthodologie d’évaluation
iOS et Android
  1. Activer le lecteur d’écran.
  2. Repérer dans l’écran les éléments graphiques utilisés comme CAPTCHA (voir la note de glossaire concernant les particularités de restitution).
  3. Vérifier que l’alternative restituée par le lecteur d’écran permet de comprendre la fonction de l’élément graphique (par exemple « Code secret à saisir », « Code de sécurité »).
  4. Si c’est le cas, le critère est validé.
Correspondances

Critère 1.5 [A] Chaque élément graphique utilisé comme CAPTCHA possède-t-il une alternative ?

Test 1.5.1 Chaque élément graphique utilisé comme CAPTCHA respecte-t-il une de ces conditions ?

  • Il existe une autre forme de CAPTCHA non graphique, au moins ;
  • Il existe une autre solution d’accès à la fonctionnalité sécurisée par le CAPTCHA.
Méthodologie d’évaluation
iOS et Android
  1. Repérer dans l’écran les éléments graphiques utilisés comme CAPTCHA (voir la note de glossaire concernant les particularités de restitution).
  2. Vérifier :
    • la présence d’une alternative non graphique (CAPTCHA sonore ou logique) ;
    • ou la présence d’une autre solution d’accès à la fonctionnalité sécurisée par le CAPTCHA (envoi d’un code sms, envoi d’un email de confirmation, etc.).
  3. Si c’est le cas, le critère est validé.
Correspondances

Critère 1.6 [A] Chaque élément graphique porteur d’information a-t-il, si nécessaire, une description détaillée ?

Test 1.6.1 : Chaque élément graphique porteur d’information qui nécessite une description détaillée vérifie-t-il une de ces conditions ?

  • Depuis l’élément graphique, les technologies d’assistance restituent ou donnent accès à une description détaillée ;
  • Il existe une description détaillée clairement identifiable adjacente à l’élément graphique ;
  • Il existe une fonctionnalité qui permet d’accéder à une description détaillée.
Méthodologie d’évaluation
iOS et Android
  1. Repérer dans l’écran les éléments graphiques porteurs d’information qui nécessitent une description détaillée (voir la note de glossaire concernant les particularités de restitution). Par exemple :
    • éléments graphiques pour lesquels l’alternative à fournir est trop longue (plus d’une phrase par exemple) ou nécessite une structuration (titres, listes ou tableau) ;
    • éléments graphiques qui cumulent plusieurs problématiques (information par la couleur, élément graphique texte, contrastes, etc.) comme les graphiques ou les cartes.
  2. Vérifier :
    • la présence d’une description détaillée clairement identifiable adjacente à l’élément graphique ;
    • ou la présence d’une fonctionnalité (un bouton, un lien) permettant d’accéder à une description détaillée.
  3. Sinon, activer le lecteur d’écran et naviguer jusqu’à l’élément graphique.
  4. Vérifier que le lecteur d’écran restitue une description détaillée.
  5. Si c’est le cas, le critère est validé.
Correspondances

Critère 1.7 [A] Pour chaque élément graphique porteur d’information ayant une description détaillée, celle-ci est-elle pertinente ?

Méthodologie d’évaluation
iOS et Android
  1. Repérer dans l’écran les éléments graphiques qui possèdent une description détaillée.
  2. Vérifier que chaque description détaillée est pertinente. On doit y trouver toutes les informations présentes dans l’élément graphique et nécessaires à la compréhension du contenu.
  3. Si c’est le cas, le critère est validé.
Correspondances

Critère 1.8 [AA] Chaque élément graphique texte porteur d’information, en l’absence d’un mécanisme de remplacement, doit, si possible être remplacé par du texte stylé. Cette règle est-elle respectée (hors cas particuliers) ?

Cas particuliers

Le critère est non applicable pour les éléments suivants :

  • Lorsque le texte fait partie d’un logo ou d’un élément associé à l’identité graphique d’un organisme ou d’une société (un slogan, par exemple).
  • Lorsque le texte contenu dans l’élément graphique est utilisé comme CAPTCHA ou comme élément graphique de test.
  • Lorsque le texte fait partie d’un élément dont l’exactitude graphique est considérée comme essentielle à la bonne transmission de l’information véhiculée par l’élément graphique.
Méthodologie d’évaluation
iOS et Android
  1. Repérer dans l’écran les éléments graphiques texte porteurs d’information (voir la note de glossaire concernant les particularités de restitution) :
    • Activer le lecteur d’écran, parcourir le contenu et repérer si les éléments restitués « élément graphique » ou « image » contiennent du texte porteur d’information.
  2. Vérifier :
    • qu’il existe un mécanisme de remplacement des éléments graphiques texte par du texte modifiable selon les préférences d’affichage de l’utilisateur (taille, couleur, graisse…) ;
    • ou que les styles et effets ne peuvent pas être reproduits via du texte stylé.
  3. Si c’est le cas, le critère est validé.
Correspondances

Critère 1.9 [AA] Chaque élément graphique légendé est-il correctement restitué par les technologies d’assistance ?

Méthodologie d’évaluation
iOS et Android
  1. Activer le lecteur d’écran.
  2. Naviguer jusqu’aux éléments graphiques légendés.
  3. Vérifier que la légende de l’élément graphique est restituée lorsque le focus atteint l’élément graphique (l’élément graphique et la légende sont contenus dans un seul élément atteignable par le lecteur d’écran).
  4. Si c’est le cas, le critère est validé.
Correspondances

Thématique 2 : Couleurs

Critère 2.1 [A] Dans chaque écran, l’information ne doit pas être donnée uniquement par la couleur. Cette règle est-elle respectée ?

Test 2.1.1 : Dans chaque écran, chaque élément dont la mise en couleur est porteuse d’information respecte-t-il au moins une de ces conditions ?

  • L’information n’est pas donnée uniquement par la couleur ;
  • Un mécanisme de remplacement permet à l’utilisateur d’afficher une alternative à la couleur.
Méthodologie d’évaluation
iOS
  1. Activer l’option Différencier sans couleur (Réglages > Accessibilité > Affichage et taille du texte > Différencier sans couleur).
  2. Repérer dans l’écran les mots ou ensemble de mots, les textes, les éléments graphiques porteurs d’information et les médias temporels dont la mise en couleur est porteuse d’information.
  3. Vérifier qu’il existe un autre moyen visuel de récupérer cette information : présence d’une icône ou d’un effet graphique de forme ou de position, un effet typographique, etc.
  4. Avec le lecteur d’écran, accéder à l’information donnée par la couleur.
  5. Vérifier qu’une information équivalente est restituée par le lecteur d’écran (par exemple l’état « sélectionné » d’un bouton vert).
  6. Si c’est le cas, le critère est validé.
Android
  1. Repérer dans l’écran les mots ou ensemble de mots, les textes, les éléments graphiques porteurs d’information et les médias temporels dont la mise en couleur est porteuse d’information.
  2. Vérifier qu’il existe un autre moyen visuel de récupérer cette information : présence d’une icône ou d’un effet graphique de forme ou de position, un effet typographique, etc.).
  3. Avec le lecteur d’écran, accéder à l’information donnée par la couleur.
  4. Vérifier qu’une information équivalente est restituée par le lecteur d’écran (par exemple l’état « sélectionné » d’un bouton vert).
  5. Si c’est le cas, le critère est validé.
Correspondances

Critère 2.2 [AA] Dans chaque écran, le contraste entre la couleur du texte et la couleur de son arrière-plan est-il suffisamment élevé (hors cas particuliers) ?

Test 2.2.1 : Pour chaque texte, le contraste entre la couleur du texte et la couleur de son arrière-plan respecte-t-il une de ces conditions ?

Cas particuliers

Le critère est non applicable pour les éléments suivants :

  • Le texte fait partie d’un logo ou d’un nom de marque d’un organisme ou d’une société.
  • Le texte ou le texte contenu dans l’élément graphique est purement décoratif.
  • Le texte fait partie d’un élément graphique porteur d’information, mais le texte lui-même n’apporte aucune information essentielle.
  • Le texte ou le texte contenu dans l’élément graphique fait partie d’un élément d’interface sur lequel aucune action n’est possible (par exemple, un bouton désactivé).
Méthodologie d’évaluation
iOS
  1. Activer l’option Augmenter le contraste (Réglages > Accessibilité > Affichage et taille du texte > Augmenter le contraste) ou s’il est présent dans l’application, activer le mécanisme de remplacement permettant d’afficher l’application avec un rapport de contraste suffisant.
  2. Repérer dans l’écran les textes, les textes contenus dans des éléments graphiques et les textes incrustés dans les vidéos qui pourraient poser des problèmes de contraste.
  3. Activer le logiciel Colour Contrast Analyser sur l’ordinateur et capturer les couleurs d’avant-plan et d’arrière-plan sur le terminal mobile soit :
  4. Vérifier :
    • Pour les textes en taille normale, que la valeur de contraste est de 4.5:1, au moins ;
    • Pour les textes de grande taille, que la valeur de contraste est de 3:1 au moins.
  5. Si c’est le cas, le critère est validé.

Note : Il est possible d’utiliser l’application Accessibility Inspector disponible sur macOS pour réaliser une évaluation rapide des contrastes des écrans. Le logiciel dispose d’une fonctionnalité « Audit » qui permet de faire des tests automatiques de certains éléments textes et graphiques des écrans. Cette fonctionnalité ne détecte pas l’ensemble des défauts de contraste, des tests complémentaires suivant la méthodologie décrite ci-avant seront nécessaires.

Android
  1. S’il existe dans l’application, activer le mécanisme de remplacement permettant d’afficher l’application avec un rapport de contraste suffisant.
  2. Repérer dans l’écran les textes, les textes contenus dans des éléments graphiques et les textes incrustés dans les vidéos qui pourraient poser des problèmes de contraste.
  3. Activer le logiciel Colour Contrast Analyser sur l’ordinateur et capturer les couleurs d’avant-plan et d’arrière-plan sur le terminal mobile soit :
  4. Vérifier :
    • Pour les textes en taille normale, que la valeur de contraste est de 4.5:1, au moins ;
    • Pour les textes de grande taille, que la valeur de contraste est de 3:1 au moins.
  5. Si c’est le cas, le critère est validé.

Note : Il est possible d’utiliser l’application Accessibility Scanner pour réaliser une évaluation rapide des contrastes des écrans. L’application ne détecte pas l’ensemble des défauts de contrastes, des tests complémentaires suivant la méthodologie décrite ci-avant seront nécessaires.

Correspondances

Critère 2.3 [AA] Dans chaque écran, les couleurs utilisées dans les composants d’interface et les éléments graphiques porteurs d’informations sont-elles suffisamment contrastées (hors cas particuliers) ?

  • Test 2.3.1 : Dans chaque écran, le rapport de contraste entre les couleurs d’un composant d’interface dans ses différents états et les couleurs adjacentes vérifie-t-il une de ces conditions (hors cas particuliers) ?
    • Le rapport de contraste est de 3:1, au moins ;
    • Un mécanisme de remplacement permet d’afficher le composant d’interface avec un rapport de contraste de 3:1, au moins.
  • Test 2.3.2 : Dans chaque écran, le rapport de contraste de chaque couleur nécessaire à la compréhension d’un élément graphique et les couleurs adjacentes, vérifie-t-il une de ces conditions (hors cas particuliers) ?
Cas particuliers

Le critère est non applicable pour les éléments suivants :

  • Composant d’interface inactif (par exemple, un bouton désactivé) sur lequel aucune action n’est possible.
  • Composant d’interface géré par la plateforme et pour lequel il n’existe pas de méthode simple de développement pour le modifier.
  • Composant d’interface dont la couleur n’est pas nécessaire pour identifier le composant ou son état (par exemple, le soulignement des liens qui aurait un rapport de contraste inférieur à 3:1 mais dont le texte a un rapport de contraste de 4.5:1).
  • Élément graphique ou parties d’élément graphique non porteur d’information ou ayant une alternative, une description détaillée, une information identique visible dans l’écran).
  • Élément graphique ou parties d’élément graphique faisant partie d’un logo ou du nom de marque d’un organisme ou d’une société.
  • Élément graphique ou parties d’élément graphique dont la présentation est essentielle à l’information véhiculée (par exemple, drapeaux, logotypes, photos de personnes ou de scènes, captures d’écran, diagrammes médicaux, carte de chaleurs).
  • Élément graphique ou parties d’élément graphique dynamique dont le contraste peut varier si d’autres éléments sont survolés (ou reçoivent le focus), mais dont le survol ou focus permet de le rendre suffisamment contrasté (par exemple, un diagramme en camembert composé de plusieurs sections suffisamment contrastées, mais lorsque la souris survole une section du camembert, les autres sections ne sont plus suffisamment contrastées, leur opacité est réduite pour mettre en avant la section survolée).
Méthodologie d’évaluation
iOS
  1. Activer l’option Augmenter le contraste (Réglages > Accessibilité > Affichage et taille du texte > Augmenter le contraste) ou s’il est présent dans l’application, activer le mécanisme de remplacement permettant d’afficher les éléments graphiques avec un rapport de contraste suffisant.
  2. Repérer dans l’écran les éléments graphiques porteurs d’information et pour chacun :
    • Identifier quelle(s) couleur(s) du composant sont nécessaires à l’identification de la localisation et/ou de l’information véhiculée (cela peut être la bordure, la couleur d’une icône, la couleur de fond) ;
    • Identifier les couleurs adjacentes qui ont un impact sur la visibilité de la ou les couleurs du composant.
  3. Repérer dans l’écran les composants interactifs qui peuvent avoir plusieurs états (survolés, focus, activé, coché) et pour chacun :
    • Identifier quelle(s) couleur(s) du composant sont nécessaires à l’identification de la localisation et/ou de l’information véhiculée et de l’état (cela peut être la bordure, la couleur d’une icône, la couleur de fond) pour chacun des états ;
    • Identifier les couleurs adjacentes qui ont un impact sur la visibilité de la ou les couleurs du composant.
  4. Activer le logiciel Colour Contrast Analyser sur l’ordinateur et capturer les couleurs d’avant-plan et d’arrière-plan sur le terminal mobile soit :
  5. Vérifier que le rapport de contraste entre les couleurs identifiées est de 3:1 au moins.
  6. Si c’est le cas, le critère est validé.

Note : Il est possible d’utiliser l’application Accessibility Inspector disponible sur macOS pour réaliser une évaluation rapide des contrastes des écrans. Le logiciel dispose d’une fonctionnalité « Audit » qui permet de faire des tests automatiques de certains éléments textes et graphiques des écrans. Cette fonctionnalité ne détecte pas l’ensemble des défauts de contraste, des tests complémentaires suivant la méthodologie décrite ci-avant seront nécessaires.

Android
  1. S’il existe dans l’application, activer le mécanisme de remplacement de l’application permettant d’afficher les éléments graphiques avec un rapport de contraste suffisant.
  2. Repérer dans l’écran les éléments graphiques porteurs d’information et pour chacun :
    • Identifier quelle(s) couleur(s) du composant sont nécessaires à l’identification de la localisation et/ou de l’information véhiculée (cela peut être la bordure, la couleur d’une icône, la couleur de fond) ;
    • Identifier les couleurs adjacentes qui ont un impact sur la visibilité de la ou les couleurs du composant.
  3. Repérer dans l’écran les composants interactifs qui peuvent avoir plusieurs états (survolés, focus, activé, coché) et pour chacun :
    • Identifier quelle(s) couleur(s) du composant sont nécessaires à l’identification de la localisation et/ou de l’information véhiculée et de l’état (cela peut être la bordure, la couleur d’une icône, la couleur de fond) pour chacun des états ;
    • Identifier les couleurs adjacentes qui ont un impact sur la visibilité de la ou les couleurs du composant.
  4. Activer le logiciel Colour Contrast Analyser sur l’ordinateur et capturer les couleurs d’avant-plan et d’arrière-plan sur le terminal mobile soit :
  5. Vérifier que le rapport de contraste entre les couleurs identifiées est de 3:1 au moins.
  6. Si c’est le cas, le critère est validé.

Note : Il est possible d’utiliser l’application Accessibility Scanner pour réaliser une évaluation rapide des contrastes des écrans. L’application ne détecte pas l’ensemble des défauts de contrastes, des tests complémentaires suivant la méthodologie décrite ci-avant seront nécessaires.

Correspondances

Critère 2.4 [AA] Le rapport de contraste de chaque mécanisme de remplacement qui permet d’afficher l’écran avec un rapport de contraste conforme est-il suffisamment élevé ?

Méthodologie d’évaluation
iOS
  1. Vérifier que l’option Augmenter le contraste (Réglages > Accessibilité > Affichage et taille du texte > Augmenter le contraste) est désactivée.
  2. Repérer la présence d’un mécanisme de remplacement permettant d’afficher l’application avec un rapport de contraste suffisant.
  3. Vérifier qu’il n’est pas activé (c’est-à-dire que l’écran est diffusé avec les contrastes par défaut).
  4. Activer le logiciel Colour Contrast Analyser sur l’ordinateur et capturer les couleurs d’avant-plan et d’arrière-plan sur le terminal mobile soit :
  5. Si le mécanisme de remplacement est identifié par un texte, capturer les couleurs d’avant-plan et d’arrière-plan et vérifier :
    • Pour les textes en taille normale, que la valeur de contraste est de 4.5:1, au moins ;
    • Pour les textes en taille agrandie, que la valeur de contraste est de 3:1 au moins.
  6. Si le mécanisme de remplacement est identifié par un élément non textuel uniquement (une icône par exemple) :
    1. Identifier quelle(s) couleur(s) du composant sont nécessaires à l’identification de la localisation et/ou de l’information (cela peut être la bordure, la couleur d’une icône, la couleur de fond) ;
    2. Identifier les couleurs adjacentes qui ont un impact sur la visibilité de la couleur ;
    3. Vérifier que le rapport de contraste entre les couleurs identifiées est de 3:1 au moins.
  7. Si c’est le cas, le critère est validé.
Android
  1. Repérer la présence d’un mécanisme de remplacement permettant d’afficher l’application avec un rapport de contraste suffisant.
  2. Vérifier qu’il n’est pas activé (c’est-à-dire que l’écran est diffusé avec les contrastes par défaut).
  3. Activer le logiciel Colour Contrast Analyser sur l’ordinateur et capturer les couleurs d’avant-plan et d’arrière-plan sur le terminal mobile soit :
  4. Si le mécanisme de remplacement est identifié par un texte, capturer les couleurs d’avant-plan et d’arrière-plan et vérifier :
    • Pour les textes en taille normale, que la valeur de contraste est de 4.5:1, au moins ;
    • Pour les textes en taille agrandie, que la valeur de contraste est de 3:1 au moins.
  5. Si le mécanisme de remplacement est identifié par un élément non textuel uniquement (une icône par exemple) :
    1. Identifier quelle(s) couleur(s) du composant sont nécessaires à l’identification de la localisation et/ou de l’information (cela peut être la bordure, la couleur d’une icône, la couleur de fond) ;
    2. Identifier les couleurs adjacentes qui ont un impact sur la visibilité de la couleur ;
    3. Vérifier que le rapport de contraste entre les couleurs identifiées est de 3:1 au moins.
  6. Si c’est le cas, le critère est validé.
Correspondances

Thématique 3 : Multimédia

Critère 3.1 [A] Chaque média temporel pré-enregistré seulement audio a-t-il, si nécessaire, une transcription textuelle adjacente clairement identifiable (hors cas particuliers) ?

Cas particuliers

Le critère est non applicable pour les éléments suivants :

  • Le média temporel est utilisé à des fins décoratives (c’est-à-dire qu’il n’apporte aucune information).
  • Le média temporel est lui-même une alternative à un contenu de l’écran (une vidéo en langue des signes ou la vocalisation d’un texte, par exemple).
  • Le média temporel est utilisé pour accéder à une version agrandie.
  • Le média temporel est utilisé comme un CAPTCHA.
  • Le média temporel fait partie d’un test qui deviendrait inutile si la transcription textuelle, les sous-titres synchronisés ou l’audiodescription étaient communiqués.
  • Le média temporel a été publié avant le 23 septembre 2020 (d’après la loi du 28 mai 2019).
Méthodologie d’évaluation
iOS et Android
  1. Repérer dans l’écran les médias temporels seulement audio qui nécessitent une transcription textuelle.
  2. Vérifier :
    • La présence d’une transcription textuelle accessible via un composant adjacent (un bouton ou un lien) ;
    • Ou la présence d’une transcription textuelle adjacente clairement identifiable.
  3. Si c’est le cas, le critère est validé.
Correspondances

Critère 3.2 [A] Pour chaque média temporel pré-enregistré seulement audio ayant une transcription textuelle, celle-ci est-elle pertinente (hors cas particuliers) ?

Cas particuliers

Voir les cas particuliers du critère 3.1

Méthodologie d’évaluation
iOS et Android
  1. Repérer dans l’écran les transcriptions textuelles des médias temporels seulement audio.
  2. Vérifier que chaque transcription textuelle est pertinente (toutes les informations sonores ou visuelles importantes sont présentes, les dialogues et les textes incrustés notamment).
  3. Si c’est le cas, le critère est validé.
Correspondances

Critère 3.3 [A] Chaque média temporel pré-enregistré seulement vidéo a-t-il, si nécessaire, une alternative (hors cas particuliers) ?

Test 3.3.1 : Chaque média temporel pré-enregistré seulement vidéo vérifie-t-il, si nécessaire, l’une de ces conditions (hors cas particuliers) ?

Cas particuliers

Voir les cas particuliers du critère 3.1

Méthodologie d’évaluation
iOS et Android
  1. Repérer dans l’écran les médias temporels seulement vidéo qui nécessitent une transcription textuelle.
  2. Vérifier :
    • la présence d’une version alternative audio seulement accessible via un composant adjacent (un bouton ou un lien) ;
    • ou la présence d’une version alternative audio seulement adjacente ;
    • ou la présence d’une transcription textuelle adjacente (un bouton ou un lien) ;
    • ou la présence d’une transcription textuelle adjacente clairement identifiable ;
    • ou la présence d’une audiodescription synchronisée ;
    • ou la présence d’une version alternative avec une audiodescription synchronisée accessible via un composant adjacent (un bouton ou un lien).
  3. Si c’est le cas, le critère est validé.
Correspondances

Critère 3.4 [A] Pour chaque média temporel pré-enregistré seulement vidéo ayant une alternative, celle-ci est-elle pertinente (hors cas particuliers) ?

Test 3.4.1 : Chaque média temporel pré-enregistré seulement vidéo respecte-t-il une de ces conditions ?

Cas particuliers

Voir les cas particuliers du critère 3.1

Méthodologie d’évaluation
iOS et Android
  1. Repérer dans l’écran les médias temporels seulement vidéo avec une alternative (transcription textuelle ou une version audio seulement).
  2. Si la transcription textuelle est présente, vérifier :
    • que celle-ci est pertinente (toutes les informations sonores ou visuelles importantes sont présentes, les dialogues et les textes incrustés notamment).
  3. Si une audiodescription est présente, vérifier :
    • que celle-ci est pertinente (toutes les informations visuelles importantes sont présentes) ;
    • et que celle-ci est correctement synchronisée (la bande-son de l’audiodescription coïncide correctement avec la bande vidéo).
  4. Si une version « audio seulement » est présente, vérifier :
    • que celle-ci est pertinente (toutes les informations sonores ou visuelles importantes sont présentes, les dialogues et les textes incrustés notamment).
  5. Si c’est le cas, le critère est validé.
Correspondances

Critère 3.5 [A] Chaque média temporel synchronisé pré-enregistré a-t-il, si nécessaire, une alternative (hors cas particuliers) ?

Test 3.5.1 : Chaque média temporel synchronisé pré-enregistré vérifie-t-il, si nécessaire, l’une de ces conditions (hors cas particuliers) ?

Cas particuliers

Voir les cas particuliers du critère 3.1

Méthodologie d’évaluation
iOS et Android
  1. Repérer dans l’écran les médias temporels synchronisés qui nécessitent une transcription textuelle.
  2. Vérifier :
    • la présence d’une transcription textuelle adjacente clairement identifiable ;
    • ou la présence d’une transcription textuelle accessible via un composant adjacent (un bouton ou un lien) ;
    • ou la présence d’une audiodescription synchronisée ;
    • ou la présence d’une version alternative avec une audiodescription synchronisée accessible via un composant adjacent (un bouton ou un lien).
  3. Si c’est le cas, le critère est validé.
Correspondances

Critère 3.6 [A] Pour chaque média temporel synchronisé pré-enregistré ayant une alternative, celle-ci est-elle pertinente (hors cas particuliers) ?

Test 3.6.1 : Chaque média temporel pré-enregistré synchronisé respecte-t-il une de ces conditions ?

  • L’audiodescription est pertinente et correctement synchronisée ;
  • La transcription textuelle est pertinente.
Cas particuliers

Voir les cas particuliers du critère 3.1

Méthodologie d’évaluation
iOS et Android
  1. Repérer dans l’écran les médias temporels synchronisés avec une audiodescription ou une transcription textuelle.
  2. Si une audiodescription est présente, vérifier :
    • que celle-ci est pertinente (toutes les informations visuelles importantes sont présentes) ;
    • et que celle-ci est correctement synchronisée (la bande-son de l’audiodescription coïncide correctement avec la bande vidéo).
  3. Si une transcription textuelle est présente, vérifier :
    • que celle-ci est pertinente (toutes les informations sonores ou visuelles importantes sont présentes, les dialogues et les textes incrustés notamment).
  4. Si c’est le cas, le critère est validé.
Correspondances

Critère 3.7 [A] Chaque média temporel synchronisé pré-enregistré a-t-il, si nécessaire, des sous-titres synchronisés (hors cas particuliers) ?

Cas particuliers

Voir les cas particuliers du critère 3.1

Méthodologie d’évaluation
iOS et Android
  1. Repérer dans l’écran les médias temporels synchronisés qui nécessitent des sous-titres (c’est-à-dire dont la bande son apporte de l’information, comme le discours d’une personne).
  2. Vérifier :
    • qu’il existe des sous-titres synchronisés ;
    • ou qu’il existe une version alternative possédant des sous-titres synchronisés accessible via un composant adjacent (un bouton ou un lien).
  3. Si c’est le cas, le critère est validé.
Correspondances

Critère 3.8 [A] Pour chaque média temporel synchronisé pré-enregistré ayant des sous-titres synchronisés, ceux-ci sont-ils pertinents ?

Test 3.8.1 : Pour chaque média temporel synchronisé pré-enregistré ayant des sous-titres synchronisés, les sous-titres respectent-ils ces conditions ?

  • Les sous-titres sont pertinents ;
  • Les sous-titres sont correctement synchronisés.
Méthodologie d’évaluation
iOS et Android
  1. Repérer dans l’écran les médias temporels synchronisés possédant des sous-titres.
  2. Vérifier que les sous-titres sont :
    • pertinents (toutes les informations sonores importantes sont présentes, les dialogues notamment) ;
    • et correctement synchronisés. Si vous n’observez pas de décalage entre le discours oralisé et l’apparition des sous-titres, les sous-titres sont correctement synchronisés. La norme de référence spécifie que les sous-titres doivent apparaître dans les 100 ms suivant l’horodatage du sous-titre.
  3. Si c’est le cas, le critère est validé.
Correspondances

Critère 3.9 [AA] Chaque média temporel pré-enregistré (seulement vidéo ou synchronisé) a-t-il, si nécessaire, une audiodescription synchronisée (hors cas particuliers) ?

Cas particuliers

Voir les cas particuliers du critère 3.1

Méthodologie d’évaluation
iOS et Android
  1. Repérer dans l’écran les médias temporels pré-enregistrés seulement vidéo et synchronisés qui nécessitent une audiodescription.
  2. Vérifier :
    • la présence d’une audiodescription synchronisée ;
    • ou la présence d’une version alternative avec une audiodescription synchronisée adjacente ou accessible via un composant adjacent (un bouton ou un lien).
  3. Si c’est le cas, le critère est validé.
Correspondances

Critère 3.10 [AA] Pour chaque média temporel pré-enregistré (seulement vidéo ou synchronisé) ayant une audiodescription synchronisée, celle-ci est-elle pertinente ?

Test 3.10.1 : Pour chaque média temporel pré-enregistré seulement vidéo ou synchronisé ayant une audiodescription, celle-ci respecte-t-elle ces conditions ?

  • L’audiodescription est pertinente ;
  • L’audiodescription est correctement synchronisée (la bande-son de l’audiodescription coïncide correctement avec la bande vidéo).
Méthodologie d’évaluation
iOS et Android
  1. Repérer dans l’écran les médias temporels seulement vidéo ou synchronisé avec une audiodescription.
  2. Vérifier que l’audiodescription est :
    • pertinente (toutes les informations visuelles importantes sont présentes) ;
    • correctement synchronisée :
      • les sons et paroles de l’audiodescription ne chevauchent pas ceux de la bande-son originale pour provoquer des problèmes de perception et de compréhension ;
      • les informations véhiculées dans l’audiodescription sont données au moment où apparaissent les informations visuelles équivalentes.
  3. Si c’est le cas, le critère est validé.
Correspondances

Critère 3.11 [A] Pour chaque média temporel pré-enregistré, le contenu textuel adjacent permet-il d’identifier clairement le média temporel (hors cas particuliers) ?

Cas particuliers

Le critère est non applicable lorsque le média temporel est utilisé à des fins décoratives (c’est-à-dire qu’il n’apporte aucune information).

Méthodologie d’évaluation
iOS et Android
  1. Repérer dans l’écran les médias temporels seulement vidéo, audio ou synchronisés pré-enregistrés.
  2. Vérifier :
    • qu’un passage de texte (un titre ou un paragraphe par exemple), permettant d’identifier le média temporel, le précède ou le suit immédiatement ;
    • que le passage de texte est situé à l’extérieur du lecteur de contenu multimédia.
  3. Si c’est le cas, le critère est validé.
Correspondances

Critère 3.12 [A] Chaque séquence sonore déclenchée automatiquement est-elle contrôlable par l’utilisateur ?

Test 3.12.1 : Chaque séquence sonore déclenchée automatiquement vérifie-t-elle une de ces conditions ?

  • La séquence sonore a une durée inférieure ou égale à 3 secondes ;
  • La séquence sonore peut être stoppée sur action de l’utilisateur ;
  • Le volume de la séquence sonore peut être contrôlé par l’utilisateur indépendamment du contrôle de volume du système.
Méthodologie d’évaluation
iOS et Android
  1. Au chargement de l’écran, si un son se déclenche automatiquement, vérifier :
    • que la séquence sonore a une durée inférieure ou égale à 3 secondes ;
    • ou qu’un dispositif (un bouton par exemple), sur l’élément ayant déclenché le son, ou dans l’écran, permet de le stopper ;
    • ou que le volume de la séquence peut être contrôlé par l’utilisateur, indépendamment du contrôle de volume du système.
  2. Si c’est le cas, le critère est validé.
Correspondances

Critère 3.13 [A] Chaque média temporel a-t-il, si nécessaire, les fonctionnalités de contrôle de sa consultation ?

Méthodologie d’évaluation
iOS et Android
  1. Repérer dans l’écran les médias temporels pré-enregistrés.
  2. Vérifier que les fonctionnalités suivantes au moins sont présentes :
    • une fonctionnalité de lecture ;
    • une fonctionnalité de mise en pause ou d’arrêt ;
    • si le média possède une piste sonore, une fonctionnalité qui permet d’activer et désactiver le son ;
  3. Si le média possède une audiodescription, vérifier qu’il existe une fonctionnalité qui permet d’activer et désactiver l’audiodescription.
  4. Si le média possède des sous-titres synchronisés :
    • s’il s’agit de sous-titres incrustés (open captions) en tant qu’image, vérifier qu’ils sont affichés au lancement de la lecture de la vidéo ;
    • s’il s’agit de sous-titres non incrustés (closed captions) , vérifier qu’il existe une fonctionnalité qui permet d’activer et désactiver ces sous-titres.
  5. Si c’est le cas, le critère est validé.
Correspondances
  • WCAG 2.1 : 2.1.1 Clavier (A)
  • EN 301 549 V3.2.1 (2021-03) : 7.1.1 Captioning playback, 7.2.1 Audio description playback, 11.2.1.1.1 Keyboard (open functionality).

Critère 3.14 [AA] Pour chaque média temporel, les fonctionnalités de contrôle des alternatives sont-elles présentées au même niveau que les autres fonctionnalités de contrôle primaires ?

Test 3.14.1 : Pour chaque média temporel, les fonctionnalités de contrôle des alternatives respectent-elles ces conditions ?

  • Pour chaque média temporel, la fonctionnalité qui permet d’activer et désactiver les sous-titres est présentée au même niveau que les autres fonctionnalités de contrôle primaires ;
  • Pour chaque média temporel, la fonctionnalité qui permet d’activer et désactiver l’audiodescription est présentée au même niveau que les autres fonctionnalités de contrôle primaires.
Méthodologie d’évaluation
iOS et Android
  1. Repérer dans l’écran les médias temporels pré-enregistrés ayant une alternative (sous-titres synchronisés ou audiodescription).
  2. Si des sous-titres sont présents, vérifier que la fonctionnalité qui permet d’activer et désactiver les sous-titres est présentée au même niveau que les autres fonctionnalités (comme la fonctionnalité de lecture par exemple), c’est-à-dire qu’il n’est pas nécessaire de réaliser plus d’actions pour déclencher les sous-titres que pour déclencher les autres fonctionnalités. Par exemple, si le bouton de lecture peut être activé depuis l’interface par un simple geste de tap (sans la nécessité d’activer un premier composant), la fonction de sous-titres doit être disponible de manière équivalente, avec un simple geste de tap. Si la fonction des sous-titres est disponible depuis un menu déroulant qui doit être activé (par un geste de tap par exemple), elle ne sera pas considérée comme étant au même niveau puisqu’il y aura une étape supplémentaire à réaliser.
  3. Si une audiodescription est présente, vérifier que la fonctionnalité qui permet d’activer et désactiver l’audiodescription est présentée au même niveau que les autres fonctionnalités.
  4. Si c’est le cas, le critère est validé.

Note : Bien que les contrôles de volume et de lecture puissent être des composants physiques des terminaux (boutons de volume d’un smartphone par exemple), il n’est pas requis que ces terminaux possèdent des contrôles physiques dédiés à l’activation des sous-titres et de l’audiodescription ou que ces contrôles, s’ils existent, soient situés au même niveau.

Correspondances
  • WCAG 2.1 : N/A
  • EN 301 549 V3.2.1 (2021-03) : 7.3 User controls for captions and audio description.

Critère 3.15 [AA] Pour chaque fonctionnalité qui transmet, convertit ou enregistre un média temporel synchronisé pré-enregistré qui possède une piste de sous-titres, à l’issue du processus, les sous-titres sont-ils correctement conservés ?

Test 3.15.1 : Pour chaque fonctionnalité qui transmet, convertit ou enregistre une vidéo qui possède une piste de sous-titres, à l’issue du processus, les sous-titres respectent-ils ces conditions ?

Méthodologie d’évaluation
iOS et Android
  1. Repérer les fonctionnalités qui permettent de transmettre (envoyer un contenu vers un autre terminal par exemple), convertir ou enregistrer un média temporel.
  2. Exécuter chacune des fonctionnalités (transmettre, convertir et enregistrer).
  3. Pour chacun des médias résultant de la fonctionnalité, évaluer :
    • si les sous-titres sont toujours présents ;
    • si les sous-titres peuvent être affichés ;
    • si les sous-titres sont correctement synchronisés ;
    • si les caractéristiques essentielles des sous-titres sont conservées (par exemple, si dans le média original les sous-titres étaient colorés en fonction du locuteur, cette coloration doit se retrouver dans le média qui résulte de la fonctionnalité).
  4. Si c’est le cas, le critère est validé.
Correspondances
  • WCAG 2.1 : N/A
  • EN 301 549 V3.2.1 (2021-03) : 5.4 Preservation of accessibility information during conversion, 7.1.3 Preservation of captioning.

Critère 3.16 [AA] Pour chaque fonctionnalité qui transmet, convertit ou enregistre un média temporel pré-enregistré avec une audiodescription synchronisée, à l’issue du processus, l’audiodescription est-elle correctement conservée ?

Test 3.16.1 : Pour chaque fonctionnalité qui transmet, convertit ou enregistre un média temporel pré-enregistré avec une audiodescription synchronisée, à l’issue du processus l’audiodescription respecte-t-elle ces conditions ?

  • L’audiodescription est présente ;
  • L’audiodescription peut être activée ;
  • L’audiodescription est correctement synchronisée.
Méthodologie d’évaluation
iOS et Android
  1. Repérer les fonctionnalités qui permettent de transmettre (envoyer un contenu vers un autre terminal par exemple), convertir ou enregistrer un média temporel.
  2. Exécuter chacune des fonctionnalités (transmettre, convertir et enregistrer).
  3. Pour chacun des médias résultant de la fonctionnalité, évaluer :
    • si l’audiodescription est présente ;
    • si l’audiodescription peut être activée ;
    • si l’audiodescription est correctement synchronisée :
      • les sons et paroles de l’audiodescription ne chevauchent pas ceux de la bande-son originale pour provoquer des problèmes de perception et de compréhension ;
      • les informations véhiculées dans l’audiodescription sont données au moment où apparaissent les informations visuelles équivalentes.
  4. Si c’est le cas, le critère est validé.
Correspondances
  • WCAG 2.1 : N/A
  • EN 301 549 V3.2.1 (2021-03) : 5.4 Preservation of accessibility information during conversion, 7.2.3 Preservation of audio description.

Critère 3.17 [AA] Pour chaque média temporel pré-enregistré, la présentation des sous-titres est-elle contrôlable par l’utilisateur (hors cas particuliers) ?

Cas particuliers

Le critère est non applicable pour les sous-titres incrustés (open captions).

Méthodologie d’évaluation
iOS
  1. Repérer dans l’écran les médias temporels pré-enregistrés qui possèdent des sous-titres.
  2. Modifier les paramètres de présentation des sous-titres depuis la plateforme :
    • Aller dans Réglages > Accessibilité > Sous-titres codés et SM > Style ;
    • Sélectionner Créer un style pour définir un style de sous-titres personnalisé et reconnaissable.
    • Définir un ou plusieurs paramètres parmi : la taille des sous-titres, la couleur, le style de bordure des sous-titres, la couleur d’arrière-plan ou encore l’opacité de l’arrière-plan (vérifier que le paramètre Ignorer les réglages personnalisés en bas d’écran est désactivé).
  3. Vérifier que les paramètres définis au niveau de la plateforme sont appliqués aux sous-titres.
  4. Si ce n’est pas le cas, vérifier dans le média la présence d’une fonctionnalité permettant de modifier les paramètres de présentation des sous-titres.
  5. Vérifier que les paramètres définis ci-avant sont appliqués aux sous-titres.
  6. Si c’est le cas, le critère est validé.
Android
  1. Repérer dans l’écran les médias temporels pré-enregistrés qui possèdent des sous-titres.
  2. Modifier les paramètres de présentation des sous-titres depuis la plateforme :
    • Aller dans Paramètres > Accessibilité > Préférence pour les sous-titres > Style et taille des sous-titres ;
    • Définir un ou plusieurs paramètres parmi : la taille des sous-titres, la couleur, le style de bordure des sous-titres, la couleur d’arrière-plan ou encore l’opacité de l’arrière-plan.
  3. Vérifier que les paramètres au niveau de la plateforme sont appliqués aux sous-titres.
  4. Si ce n’est pas le cas, vérifier dans le média la présence d’une fonctionnalité permettant de modifier les paramètres de présentation des sous-titres.
  5. Vérifier que les paramètres définis ci-avant sont appliqués aux sous-titres.
  6. Si c’est le cas, le critère est validé.
Correspondances

Critère 3.18 [AA] Pour chaque média temporel synchronisé pré-enregistré qui possède des sous-titres synchronisés, ceux-ci peuvent-ils être, si nécessaire, vocalisés (hors cas particuliers) ?

Test 3.18.1 : Chaque média temporel synchronisé pré-enregistré qui possède des sous-titres synchronisés respecte-t-il une de ces conditions ?

  • Les sous-titres sont dans un format standardisé ;
  • Il existe une piste audio supplémentaire qui contient les sous-titres vocalisés.
Cas particuliers

Le critère est non applicable dans les cas suivants :

  • Les sous-titres sont incrustés dans la vidéo.
  • La vidéo et les sous-titres utilisent la même langue. Le critère ne concerne que les sous-titres de traduction.
Méthodologie d’évaluation
iOS
  1. Repérer dans l’écran les médias temporels synchronisés pré-enregistrés qui possèdent des sous-titres de traduction.
  2. Vérifier que les sous-titres sont dans un format standardisé (par exemple, le format .srt).
  3. Sinon, activer le lecteur d’écran et naviguer jusqu’au lecteur multimédia.
  4. Activer le rotor.
  5. Faire défiler les paramètres du rotor et trouver l’option « Description multimédia ».
  6. Si c’est le cas, en balayant vers le haut, sélectionner l’option « Énonciation ».
  7. Activer les sous-titres de la vidéo et lancer la vidéo.
  8. Vérifier que les sous-titres affichés sont restitués par le lecteur d’écran.
  9. Si ce n’est pas le cas, vérifier la présence dans le lecteur multimédia d’une piste sonore supplémentaire qui serait la version vocalisée des sous-titres.
  10. Activer la piste audio supplémentaire et vérifier que les sous-titres vocalisés correspondent aux sous-titres affichés.
  11. Si c’est le cas, le critère est validé.

Note : Si l’option « Description multimédia » n’est pas disponible dans le rotor, déplacer le focus du lecteur d’écran pour atteindre la vidéo et utiliser à nouveau le rotor. Si l’option n’apparaît toujours pas, les sous-titres ne pourront pas être restitués par le lecteur d’écran, le critère est non conforme.

Android
  1. Repérer dans l’écran les médias temporels synchronisés pré-enregistrés qui possèdent des sous-titres de traduction.
  2. Vérifier que les sous-titres sont dans un format standardisé (par exemple, le format .srt).
  3. Sinon, vérifier la présence dans le lecteur multimédia d’une piste sonore supplémentaire qui serait la version vocalisée des sous-titres.
  4. Activer la piste audio supplémentaire et vérifier que les sous-titres vocalisés correspondent aux sous-titres affichés.
  5. Si c’est le cas, le critère est validé.
Correspondances
  • WCAG 2.1 : N/A
  • EN 301 549 V3.2.1 (2021-03) : 7.1.5 Spoken subtitles.

Thématique 4 : Tableaux

Critère 4.1 [A] Chaque tableau de données complexe a-t-il un résumé ?

Méthodologie d’évaluation
iOS et Android
  1. Repérer dans l’écran les tableaux de données complexes.
  2. Activer le lecteur d’écran.
  3. Vérifier :
    • qu’un résumé est restitué lorsque le lecteur d’écran atteint le tableau ;
    • ou qu’un résumé est disponible avant le tableau, sous la forme d’un texte précédant le tableau.
  4. Si c’est le cas, le critère est validé.
Correspondances

Critère 4.2 [A] Pour chaque tableau de données complexe ayant un résumé, celui-ci est-il pertinent ?

Méthodologie d’évaluation
iOS et Android
  1. Vérifier que chaque résumé de tableau est pertinent, c’est-à-dire qu’il permet de comprendre la nature des données et la construction du tableau.
  2. Si c’est le cas, le critère est validé.
Correspondances

Critère 4.3 [A] Chaque tableau de données a-t-il un titre ?

Méthodologie d’évaluation
iOS et Android
  1. Repérer dans l’écran les tableaux de données.
  2. Activer le lecteur d’écran.
  3. Vérifier qu’un titre est restitué lorsque le lecteur d’écran atteint le tableau.
  4. Si c’est le cas, le critère est validé.
Correspondances

Critère 4.4 [A] Pour chaque tableau de données ayant un titre, celui-ci est-il pertinent ?

Méthodologie d’évaluation
iOS et Android
  1. Vérifier que chaque titre de tableau de données est pertinent, c’est-à-dire qu’il permet d’identifier la nature des données présentées dans le tableau.
  2. Si c’est le cas, le critère est validé.
Correspondances

Critère 4.5 [A] Pour chaque tableau de données, les entêtes de lignes et de colonnes sont-ils correctement reliés aux cellules de données ?

Méthodologie d’évaluation
iOS et Android
  1. Repérer dans l’écran les tableaux de données.
  2. Activer le lecteur d’écran et parcourir les cellules de données.
  3. Vérifier que les entêtes sont correctement restitués.
  4. Si c’est le cas, le critère est validé.
Correspondances
  • WCAG 2.1 : 1.3.1 Information et relations (A)
  • EN 301 549 V3.2.1 (2021-03) : 11.1.3.1.1 Info and relationships (open functionality), 11.5.2.5 Object information, 11.5.2.6 Row, column, and headers.

Thématique 5 : Composants interactifs

Critère 5.1 [A] Chaque composant d’interface est-il, si nécessaire, compatible avec les technologies d’assistance (hors cas particuliers) ?

Cas particuliers

Le critère est non applicable pour les éléments suivants :

  • L’application est soumise à des exigences de sécurité strictes qui empêchent d’autres applications d’interagir avec son interface (comme une technologie d’assistance). Des exemples de systèmes soumis à des exigences de sécurité strictes sont les systèmes traitant des activités de renseignement, des activités de cryptologie liées à la sécurité nationale, du commandement et du contrôle des forces militaires.
  • Les cartes et les services de cartographie en ligne, pour autant que les informations essentielles soient fournies sous une forme numérique accessible pour ce qui concerne les cartes destinées à la navigation.

Il existe une gestion de cas particuliers pour le test 5.1.2 lorsque :

  • La ponctuation et les lettres majuscules sont présentes dans le texte de l’intitulé visible : elles peuvent être ignorées dans le nom accessible sans porter à conséquence.
  • Le texte de l’intitulé visible sert de symbole : le texte ne doit pas être interprété littéralement au niveau du nom accessible. Le nom doit exprimer la fonction véhiculée par le symbole (par exemple, “B” au niveau d’un éditeur de texte aura pour nom accessible “Mettre en gras”, le signe “>” en fonction du contexte signifiera “Suivant” ou “Lancer la vidéo”). Le cas des symboles mathématiques fait cependant exception (voir la note ci-dessous).

Note : si l’étiquette visible représente une expression mathématique, les symboles mathématiques peuvent être repris littéralement pour servir d’étiquette au nom accessible (ex. : “A>B”). Il est laissé à l’utilisateur le soin d’opérer la correspondance entre l’expression et ce qu’il doit épeler compte tenu de la connaissance qu’il a du fonctionnement de son logiciel de saisie vocale (“A plus grand que B” ou “A supérieur à B”).

Méthodologie d’évaluation

Le test le plus complet est un test de restitution avec un lecteur d’écran. En effet tous les éléments à évaluer, s’ils sont présents, sont restitués par les lecteurs d’écran. D’autres tests avec d’autres technologies d’assistance peuvent être nécessaires pour s’assurer de la compatibilité. Plusieurs méthodes d’évaluation plus ou moins complètes vous sont décrites.

Plusieurs méthodes sont disponibles avec iOS, mais seul le test avec VoiceOver est le test qui permet d’évaluer l’ensemble des éléments demandé par le critère.

De plus, il n’existe pas comme pour le web de documentation technique permettant de décrire le fonctionnement et les implémentations attendues (par exemple pour les fenêtres modales ou les potentiomètres). En l’absence d’une telle documentation, afin d’évaluer au plus juste ce type de composant il est conseillé tout de même de se rapprocher :

iOS avec VoiceOver
  1. Activer le lecteur d’écran.
  2. Repérer dans l’écran les composants interactifs (par exemple, bouton, lien).
  3. Accéder à chaque composant interactif en utilisant les gestes du lecteur d’écran.
  4. Vérifier :
    • qu’un rôle est restitué (par exemple, bouton, zone de modification, lien) ;
    • que le rôle restitué est pertinent au regard de la fonctionnalité associée (par exemple, un composant qui déclenche l’ouverture d’une fenêtre modale et qui est restitué « zone de modification » a un rôle non pertinent, il devrait être identifié comme un bouton) ;
    • qu’un nom est restitué et que ce nom est pertinent, c’est-à-dire qu’il permet de comprendre la fonction de l’élément (pour les champs de formulaire, on se reportera à la thématique « Formulaires » pour les évaluer) ;
    • que si le composant possède un nom visible (un texte visible), l’intitulé est restitué ;
    • que si le composant a un état perceptible (activé, désactivé, sélectionné), cet état est restitué ;
    • que si le composant peut changer d’état (par exemple bouton à bascule, potentiomètre), réaliser les actions nécessaires pour tester les différents états et vérifier que chaque changement d’état est correctement restitué (le passage à l’état sélectionné, l’augmentation du potentiomètre) ;
    • que si le composant a une valeur perceptible (valeur d’un potentiomètre), cette valeur est restituée.
  5. Si c’est le cas, le critère est validé.
iOS Avec Accessibility Inspector
  1. Connecter le terminal mobile iOS à l’ordinateur avec macOS.
  2. Activer le logiciel Accessibility Inspector.
  3. Choisir le terminal mobile comme source et rester sur l’onglet « Inspection » (boutons en haut à droite).
  4. Avec les flèches de Accessibility Inspector, accéder à chaque élément de l’interface.
  5. Vérifier :
    • qu’un rôle est disponible dans le paramètre « Traits » (par exemple, Bouton, Tab, Text Field) ;
    • que le rôle est pertinent au regard de la fonctionnalité associée (par exemple, un composant qui déclenche l’ouverture d’une fenêtre modale et qui est présenté comme Static text a un rôle non pertinent, il devrait être identifié comme un bouton) ;
    • qu’un nom est disponible dans le paramètre « Label » et que ce nom est pertinent, c’est-à-dire qu’il permet de comprendre la fonction de l’élément (pour les champs de formulaire, on se reportera à la thématique « Formulaires » pour les évaluer) ;
    • que si le composant possède un nom visible (un texte visible), l’intitulé défini dans le paramètre « Label » contient au moins cet intitulé.
  6. Si le composant a un état perceptible (activé, désactivé, sélectionné), vérifier que cet état :
    • est disponible dans le paramètre « Traits » ;
    • ou est indiqué dans le paramètre « Label ».
  7. Si le composant peut changer d’état (par exemple bouton à bascule, potentiomètre), réaliser les actions nécessaires pour tester les différents états et vérifier que chaque changement d’état (le passage à l’état sélectionné, l’augmentation du potentiomètre) :
    • est disponible dans le paramètre « Traits » ;
    • ou est indiqué dans le paramètre « Label ».
  8. Si c’est le cas, le critère est validé.
iOS Avec le contrôle vocal

L’application de contrôle vocal permet aux utilisateurs de naviguer à la voix.

Le critère 5.1 dans sa globalité ne peut pas être évalué avec le contrôle vocal, mais une fonctionnalité du contrôle vocal (l’affichage des libellés) permet d’avoir une vue d’ensemble rapide de l’état des composants interactifs.

Le contrôle vocal va permettre de déceler les composants utilisables au toucher qui ne sont pas des composants interactifs détectables par les technologies d’assistance, la présence d’un intitulé et sa pertinence, et la présence du nom visible dans le nom accessible.

  1. Activer le contrôle vocal : Réglages > Accessibilité > Contrôle vocal.
  2. Afficher les libellés des composants interactifs : depuis l’écran de paramètres du contrôle vocal, atteindre le bouton « Superposition » et l’activer, puis choisir « Noms des éléments ».
  3. Dorénavant, lorsque le contrôle vocal sera activé, des infobulles grises apparaitront au-dessus des éléments interactifs qui ont des labels. À noter que si l’écran possède un très grand nombre de contrôles interactifs, les labels s’afficheront par groupes successifs (un groupe de label disparait et un autre apparaît).

Ce qu’il faut savoir : seuls les éléments qui ont des rôles interactifs reconnus par l’API d’accessibilité posséderont un label. Ceci va permettre de repérer rapidement quels éléments utilisables au toucher ne sont pas reconnus par le contrôle vocal et ne sont donc pas des éléments interactifs (ce qui constitue une non conformité).

Procédure :

  1. Repérer dans l’écran tous les contrôles interactifs (activables au toucher).
  2. Activer le contrôle vocal et vérifier que tous les contrôles interactifs identifiés possèdent un label associé (infobulle grise).
  3. Si c’est le cas, vérifier que :
    • le label associé est pertinent ;
    • et que le nom visible (s’il en possède un) est compris dans ce label.
  4. Si c’est le cas, les conditions sur la pertinence de l’intitulé et la présence du nom visible dans le nom accessible sont remplies.
Android
  1. Activer le lecteur d’écran.
  2. Repérer dans l’écran les composants interactifs (par exemple, bouton, lien).
  3. Accéder à chaque composant interactif avec les gestes du lecteur d’écran.
  4. Vérifier :
    • qu’un rôle est restitué (par exemple, bouton, zone de modification, lien) ;
    • que le rôle restitué est pertinent au regard de la fonctionnalité associée (par exemple, un composant qui déclenche l’ouverture d’une fenêtre modale et qui est restitué « zone de modification » a un rôle non pertinent, il devrait être identifié comme un bouton) ;
    • qu’un nom est restitué et que ce nom est pertinent, c’est-à-dire qu’il permet de comprendre la fonction de l’élément (pour les champs de formulaire, on se reportera à la thématique « Formulaires » pour les évaluer) ;
    • que si le composant possède un nom visible (un texte visible), l’intitulé est restitué ;
    • que si le composant a un état perceptible (activé, désactivé, sélectionné), cet état est restitué ;
    • que si le composant peut changer d’état (par exemple bouton à bascule, potentiomètre), réaliser les actions nécessaires pour tester les différents états et vérifier que chaque changement d’état est correctement restitué (le passage à l’état sélectionné, l’augmentation du potentiomètre) ;
    • que si le composant a une valeur perceptible (valeur d’un potentiomètre), cette valeur est restituée.
  5. Si c’est le cas, le critère est validé.
Correspondances
  • WCAG 2.1 : 2.4.4 Link Purpose (In Context), 2.5.3 Étiquette dans le nom (A), 4.1.2 Nom, rôle et valeur (A)
  • EN 301 549 V3.2.1 (2021-03) : 5.6.1 Tactile or auditory status, 11.2.4.4 Link purpose (in context), 11.2.5.3.1 Label in name (open functionality), 11.4.1.2.1 Name, role, value (open functionality), 11.5.2.3 Use of accessibility services, 11.5.2.5 Object information, 11.5.2.7 Values, 11.5.2.8 Label relationships, 11.5.2.9 Parent-child relationships, 11.5.2.11 List of available actions, 11.5.2.12 Execution of available actions, 11.5.2.16 Modifications of states and properties, 11.6.2 No disruption of accessibility features.

Critère 5.2 [A] Chaque composant d’interface est-il contrôlable par le clavier et tout dispositif de pointage (hors cas particuliers) ?

Cas particuliers

Le critère est non applicable pour les éléments suivants :

  • La fonctionnalité dépend de l’utilisation d’un gestionnaire d’événement sans équivalent universel ; par exemple, une application de dessin à main levée ne pourra pas être rendue contrôlable au clavier.
  • L’application est soumise à des exigences de sécurité strictes qui empêchent d’autres applications d’interagir avec son interface (comme une technologie d’assistance). Des exemples de systèmes soumis à des exigences de sécurité strictes sont les systèmes traitant des activités de renseignement, des activités de cryptologie liées à la sécurité nationale, du commandement et du contrôle des forces militaires.
  • Les cartes et les services de cartographie en ligne, pour autant que les informations essentielles soient fournies sous une forme numérique accessible pour ce qui concerne les cartes destinées à la navigation.
Méthodologie d’évaluation

Il s’agit ici de s’assurer que le composant peut être utilisé par le lecteur d’écran, le contrôle vocal, un clavier externe ou tout autre commutateur externe. On peut limiter les tests à quelques dispositifs de pointage puisque les caractéristiques nécessaires (sur les composants interactifs) sont semblables.

Il est néanmoins nécessaire de tester au moins avec le lecteur d’écran et un clavier externe.

Pour le clavier externe, certains paramétrages sont nécessaires pour que le périphérique soit pleinement fonctionnel.

iOS et Android
  1. Activer le lecteur d’écran.
  2. Parcourir l’ensemble des composants interactifs.
  3. Vérifier :
    • qu’il peut être atteint avec le lecteur d’écran ;
    • qu’il peut être activé avec le lecteur d’écran.
  4. Si c’est un composant modifiable (champ de saisie, case à cocher, potentiomètre), vérifier qu’il peut être modifié avec le lecteur d’écran.
  5. Connecter un clavier externe (et paramétrer la navigation au clavier).
  6. Parcourir l’ensemble des composants interactifs.
  7. Vérifier :
    • qu’il peut être atteint avec les touches du clavier ;
    • qu’il peut être activé avec la touche dédiée du clavier.
  8. Si c’est un composant modifiable (champ de saisie, case à cocher, potentiomètre), vérifier qu’il peut être modifié avec les touches du clavier.
  9. Si c’est le cas, le critère est validé.
Correspondances
  • WCAG 2.1 : 1.3.1 Info and Relationships (A), 2.1.1 Keyboard (A), 2.4.7 Visibilité du focus (AA)
  • EN 301 549 V3.2.1 (2021-03) : 11.1.3.1.1 Info and relationships (open functionality), 11.2.1.1.1 Keyboard (open functionality), 11.2.4.7 Focus visible, 11.5.2.3 Use of accessibility services, 11.5.2.7 Values, 11.5.2.12 Execution of available actions, 11.5.2.13 Tracking of focus and selection attributes, 11.5.2.14 Modification of focus and selection attributes, 11.5.2.17 Modifications of values and text.

Critère 5.3 [A] Chaque changement de contexte respecte-t-il une de ces conditions ?

Test 5.3.1 : Chaque changement de contexte respecte-t-il une de ces conditions ?

  • L’utilisateur est averti par un texte du type de changement avant son déclenchement ;
  • Le changement de contexte est initié par une action de l’utilisateur sur un composant ayant un nom explicite.
Méthodologie d’évaluation
iOS et Android
  1. Repérer dans l’écran tous les événements qui initient un changement de contexte, par exemple :
    • une mise à jour dynamique de champs de formulaire ;
    • l’ouverture d’une nouvelle page sur la sélection d’une entrée de liste ;
    • la mise à jour d’une partie essentielle de l’écran sans action de l’utilisateur ;
    • le lancement automatique d’un lecteur vidéo sur la sélection d’une playlist ;
    • la manipulation du focus ayant pour résultat de modifier la position courante de l’utilisateur dans l’écran.
  2. Vérifier :
    • que l’utilisateur est averti par un texte du type de changement avant son déclenchement ;
    • ou que le changement de contexte est initié par un bouton ou un lien explicite.
  3. Si c’est le cas, le critère est validé.
Correspondances

Critère 5.4 [AA] Dans chaque écran, les messages de statut sont-ils correctement restitués par les technologies d’assistance ?

Méthodologie d’évaluation
iOS et Android
  1. Activer le lecteur d’écran.
  2. Réaliser les actions nécessaires à l’apparition d’un message de statut par exemple :
    • remplir correctement un formulaire et le valider pour faire apparaître un message indiquant l’envoi avec succès ;
    • soumettre un formulaire avec des champs obligatoires sans saisie pour faire apparaître un message indiquant la présence d’erreurs ;
    • afficher un écran qui nécessite un certain temps de chargement pour faire apparaître un message de progression ou un indicateur de progression de chargement.
  3. Vérifier que lorsque le statut apparaît, le lecteur d’écran restitue l’information et que cette information est compréhensible.
  4. Si c’est le cas, le critère est validé.
Correspondances
  • WCAG 2.1 : 4.1.3 Messages d’état (AA)
  • EN 301 549 V3.2.1 (2021-03) : 11.4.1.3.1 Status messages (open functionality), 11.5.2.3 Use of accessibility services, 11.5.2.15 Change notification.

Critère 5.5 [A] Chaque état d’un contrôle à bascule présenté à l’utilisateur est-il perceptible ?

Test 5.5.1 : Pour chaque état d’un contrôle à bascule présenté à l’utilisateur, les conditions suivantes sont-elles respectées ?

  • L’état de la fonctionnalité est visible sur l’interface sans modifier l’état du contrôle ;
  • L’état de la fonctionnalité peut être déterminé par le toucher ou le son sans modifier l’état du contrôle.
Méthodologie d’évaluation
iOS et Android
  1. Repérer dans l’écran les contrôles à bascule (boutons avec un ou plusieurs états, par exemple, cases à cocher, bouton radio, switch).
  2. Vérifier qu’il est possible de déterminer l’état du contrôle sur la base de sa présentation dans l’interface (par exemple, un changement de forme lorsque le contrôle passe d’un état à l’autre).
  3. Activer le lecteur d’écran et naviguer jusqu’au contrôle.
  4. Vérifier que l’état du contrôle est restitué par le lecteur d’écran sans avoir à interagir avec le contrôle.
  5. Si c’est le cas, le critère est validé.
Correspondances
  • WCAG 2.1 : N/A
  • EN 301 549 V3.2.1 (2021-03) : 5.6.1 Tactile or auditory status,5.6.2 Visual status.

Thématique 6 : Éléments obligatoires

Critère 6.1 [A] Dans chaque écran, les textes sont-ils restitués par les technologies d’assistance dans la langue principale de l’écran ?

Note : Il n’est pas requis que les changements de langue dans l’écran soient identifiés (par exemple, un terme en langue étrangère inclus dans un paragraphe) mais que l’écran soit restitué au moins correctement dans la langue principale de l’écran. Cependant, dans certains cas d’applications où les changements de langue seraient essentiels à la compréhension du contenu (comme une application de traduction ou une application de cours de langue étrangère) il faudra veiller à ce que les textes en langue étrangère soient correctement restitués dans la langue identifiée.

Méthodologie d’évaluation
iOS
  1. Aller dans Réglages > Accessibilité > VoiceOver > Parole et activer le paramètre « Détecter les langues ».
  2. Activer le lecteur d’écran et parcourir l’ensemble des éléments de l’écran.
  3. Vérifier que le texte est restitué dans la langue principale de l’écran.
  4. Si c’est le cas, le critère est validé.
Android
  1. Aller dans Paramètres > Accessibilité > TalkBack > Paramètres > Paramètres de la synthèse vocale (selon la version de la plateforme, le chemin d’accès peut être différent) :
    • Vérifier que le paramètre « Moteur préféré » est « Synthèse vocale Google » ;
    • Activer les paramètres de la synthèse (bouton à droite de « Moteur préféré ») et vérifier que le paramètre « Détection de la langue » est sur « Forcée ».
  2. Activer le lecteur d’écran et parcourir l’ensemble des éléments de l’écran.
  3. Vérifier que les textes sont restitués dans la langue principale de l’écran.
  4. Si c’est le cas, le critère est validé.
Correspondances

Critère 6.2 [A] Dans chaque écran, les éléments de l’interface ne doivent pas être utilisés uniquement à des fins de présentation. Cette règle est-elle respectée ?

Méthodologie d’évaluation

Dans ce critère, on ne contrôle que les éléments qui ne doivent pas être interactifs (les éléments texte, les tableaux par exemple).

iOS avec VoiceOver
  1. Activer le lecteur d’écran et parcourir l’ensemble des éléments de l’écran.
  2. Vérifier que le rôle restitué par le lecteur d’écran correspond à la nature de l’élément (par exemple, lorsque le lecteur d’écran atteint ce qui apparaît comme un paragraphe et qu’il restitue « Bouton », il s’agit d’une erreur, aucun rôle n’est restitué sur les paragraphes).
  3. Si c’est le cas, le critère est validé.
iOS Avec Accessibility Inspector
  1. Connecter le terminal mobile iOS à l’ordinateur avec macOS.
  2. Activer le logiciel Accessibility Inspector.
  3. Choisir le terminal mobile comme source et rester sur l’onglet « Inspection » (boutons en haut à droite).
  4. Avec les flèches de Accessibility Inspector, accéder à chaque élément de l’interface.
  5. Vérifier que le rôle disponible dans le paramètre « Traits » est pertinent au regard de la nature de l’élément associé (par exemple, un simple texte qui aurait un rôle de bouton serait considéré non conforme, il devrait être identifié comme un texte statique).
  6. Si c’est le cas, le critère est validé.
Android
  1. Activer le lecteur d’écran et parcourir l’ensemble des éléments de l’écran.
  2. Vérifier que le rôle restitué par le lecteur d’écran correspond à la nature de l’élément (par exemple, lorsque le lecteur d’écran atteint ce qui apparaît comme un paragraphe et qu’il restitue « Bouton », il s’agit d’une erreur, aucun rôle n’est restitué sur les paragraphes).
  3. Si c’est le cas, le critère est validé.
Correspondances

Thématique 7 : Structuration de l’information

Critère 7.1 [A] Dans chaque écran, l’information est-elle structurée par l’utilisation appropriée de titres ?

Test 7.1.1 : Chaque écran vérifie-t-il ces conditions ?

  • Le contenu de chaque titre est pertinent ;
  • Chaque passage de texte constituant un titre est identifié comme un titre.
Méthodologie d’évaluation
iOS avec VoiceOver
  1. Activer le lecteur d’écran.
  2. Utiliser le rotor et sélectionner « En-têtes ».
  3. Parcourir les entêtes en glissant un doigt vers le haut ou vers le bas.
  4. Vérifier :
    • que chaque texte qui structure l’écran peut être atteint ;
    • que chaque entête atteint est pertinent, c’est-à-dire :
      • que le titre est utile à la structuration de l’écran ;
      • que le texte contenu dans le titre permet de comprendre le contenu de la section titrée.
  5. Si c’est le cas, le critère est validé.
iOS avec Accessibility Inspector
  1. Connecter le terminal mobile iOS à l’ordinateur avec macOS.
  2. Activer le logiciel Accessibility Inspector.
  3. Choisir le terminal mobile comme source et rester sur l’onglet « Inspection » (boutons en haut à droite).
  4. Avec les flèches de Accessibility Inspector, accéder à chaque élément de l’interface.
  5. Vérifier :
    • que pour chaque texte qui structure l’écran, le paramètre « Traits » contient la valeur « En-têtes » ;
    • que chaque texte dont le paramètre « Traits » contient la valeur « En-têtes » est pertinent, c’est-à-dire :
      • que le titre ainsi déclaré est utile à la structuration de l’écran ;
      • que le texte contenu dans le titre permet de comprendre le contenu de la section ainsi titrée.
  6. Si c’est le cas, le critère est validé.
Android
  1. Activer le lecteur d’écran.
  2. Utiliser le menu des commandes de lecture et sélectionner « Titres ».
  3. Parcourir les titres en glissant un doigt vers le haut ou vers le bas.
  4. Vérifier :
    • que chaque texte qui structure l’écran est atteint de cette manière et est restitué comme titre ;
    • que chaque titre atteint est pertinent, c’est-à-dire :
      • que le titre est utile à la structuration de l’écran ;
      • que le texte contenu dans le titre permet de comprendre le contenu de la section ainsi titrée.
  5. Si c’est le cas, le critère est validé.
Correspondances

Critère 7.2 [A] Dans chaque écran, chaque liste est-elle correctement structurée ?

Méthodologie d’évaluation
iOS et Android
  1. Activer le lecteur d’écran.
  2. Repérer dans l’écran les éléments rassemblés sous forme de liste.
  3. Vérifier que le lecteur d’écran restitue « Liste » lorsqu’il atteint le groupe d’éléments.
  4. Si c’est le cas, le critère est validé.
Correspondances
  • WCAG 2.1 : 1.3.1 Information et relations (A)
  • EN 301 549 V3.2.1 (2021-03) : 11.1.3.1.1 Info and relationships (open functionality), 11.5.2.5 Object information, 11.5.2.9 Parent-child relationships.

Thématique 8 : Présentation de l’information

Critère 8.1 [A] Dans chaque écran, le contenu visible porteur d’information est-il accessible aux technologies d’assistance ?

Méthodologie d’évaluation
iOS et Android
  1. Activer le lecteur d’écran.
  2. Parcourir l’ensemble des éléments en utilisant les gestes du lecteur d’écran.
  3. Vérifier que l’ensemble des informations visibles à l’écran sont restituées par le lecteur d’écran.
  4. Si c’est le cas, le critère est validé.

Note : Dans les applications, il est possible de réaliser des regroupements d’éléments. Par exemple, dans un catalogue de produits, chaque item possède un titre, un prix et une description. Au lieu de prendre le focus avec le lecteur d’écran sur chacun des 3 items, l’application peut être conçue pour que le lecteur d’écran accède seulement à l’item dans sa globalité, ainsi le lecteur d’écran restitue l’ensemble des informations sans que l’utilisateur ait à réaliser plusieurs gestes pour atteindre les 3 items. Ceci est conforme (voire encouragé puisque cela limite les actions à réaliser pour parcourir le contenu), il faut s’assurer que tous les textes contenus sont bien restitués par le lecteur d’écran.

Correspondances

Critère 8.2 [AA] Dans chaque écran, l’utilisateur peut-il augmenter la taille des caractères de 200% au moins (hors cas particuliers) ?

Test 8.2.1 : Chaque écran vérifie-t-il ces conditions ?

  • L’utilisateur peut agrandir la taille des textes de 200% en utilisant les paramètres de la plateforme ;
  • Tous les textes de l’écran sont agrandis ;
  • Tous les textes agrandis restent lisibles et les composants interactifs utilisables.
Cas particuliers

Le critère est non applicable pour les éléments suivants :

  • Les éléments graphiques texte ;
  • Les sous-titres de vidéo.
Méthodologie d’évaluation
iOS
  1. Accéder aux paramètres de réglages des tailles de caractères de la plateforme : Réglages > Accessibilité > Affichage et taille du texte > Police plus grande.
  2. Activer le bouton « Taille de police plus grande » et augmenter la valeur de la taille de la police (potentiomètre en bas de l’écran) jusqu’à atteindre un agrandissement de 200% (le maximum de la jauge permet d’atteindre un zoom supérieur à 200%, le test peut donc se limiter à augmenter le zoom en utilisant l’avant-dernière position du potentiomètre).
  3. Si nécessaire, redémarrer l’application pour s’assurer que le paramètre est pris en compte par l’application.
  4. Vérifier :
    • que tous les textes de l’interface ont été agrandis ;
    • que tous les textes de l’interface restent lisibles et les fonctionnalités utilisables ;
    • que des contenus ne disparaissent pas ;
    • si des textes ont disparu, qu’il existe une méthode dans l’écran pour afficher les textes à la demande (par exemple avec l’appui prolongé sur une icône).
  5. Si c’est le cas, le critère est validé.
Android
  1. Accéder aux paramètres de réglages des tailles de caractères de la plateforme : Paramètres > Accessibilité > Taille de la police (selon la version de la plateforme, le chemin d’accès peut être différent) ;
  2. Augmenter la valeur de la taille de la police (potentiomètre en bas de l’écran) jusqu’à atteindre un agrandissement de 200% (sur certains terminaux, la jauge du potentiomètre peut être différente et offrir des valeurs qui permettent d’atteindre un zoom supérieur à 200%, il faudra alors vérifier que le test ne se fait que pour une valeur de 200%).
  3. Si nécessaire, redémarrer l’application pour s’assurer que le paramètre est pris en compte par l’application.
  4. Vérifier :
    • que tous les textes de l’interface ont été agrandis ;
    • que tous les textes de l’interface restent lisibles et les fonctionnalités utilisables ;
    • que des contenus ne disparaissent pas ;
    • si des textes ont disparu, qu’il existe une méthode dans l’écran pour afficher les textes à la demande (par exemple avec l’appui prolongé sur une icône).
  5. Si c’est le cas, le critère est validé.
Correspondances
  • WCAG 2.1 : 1.4.4 Redimensionnement du texte (AA)
  • EN 301 549 V3.2.1 (2021-03) : 11.1.4.4.1 Resize text (open functionality), 11.5.2.3 Use of accessibility services, 11.7 User preferences.

Critère 8.3 [A] Dans chaque écran, chaque composant en environnement de texte dont la nature n’est pas évidente a-t-il un rapport de contraste supérieur ou égal à 3:1 par rapport au texte environnant ?

Méthodologie d’évaluation
iOS
  1. Activer l’option Différencier sans couleur (Réglages > Accessibilité > Affichage et taille du texte > Différencier sans couleur).
  2. Activer l’option Augmenter le contraste (Réglages > Accessibilité > Affichage et taille du texte > Augmenter le contraste) ou s’il est présent dans l’application, activer le mécanisme de remplacement permettant d’afficher l’application avec un rapport de contraste suffisant.
  3. Repérer dans l’écran les composants d’interface (liens, boutons) avec du texte intégrés dans un environnement de texte (dans une phrase par exemple), signifiés uniquement par la couleur (sans autre mise en forme qui les distingue du reste du texte dans lequel ils sont intégrés).
  4. Activer le logiciel Colour Contrast Analyser sur l’ordinateur et capturer les couleurs du texte environnant et du composant interactif sur le terminal mobile, soit :
  5. Vérifier que le contraste entre la couleur de police du composant et la couleur de police du texte environnant est de 3:1, au moins.
  6. Si c’est le cas, le critère est validé.
Android
  1. S’il existe dans l’application, activer le mécanisme de remplacement permettant d’afficher l’application avec un rapport de contraste suffisant.
  2. Repérer dans l’écran les composants d’interface (liens, boutons) avec du texte intégrés dans un environnement de texte (dans une phrase par exemple) signifiés uniquement par la couleur (sans autre mise en forme qui les distingue du reste du texte dans lequel ils sont intégrés).
  3. Activer le logiciel Colour Contrast Analyser sur l’ordinateur et capturer les couleurs du texte environnant et du composant interactif sur le terminal mobile, soit :
  4. Vérifier que le contraste entre la couleur de police du composant et la couleur de police du texte environnant est de 3:1, au moins.
  5. Si c’est le cas, le critère est validé.
Correspondances

Critère 8.4 [A] Dans chaque écran, pour chaque composant en environnement de texte dont la nature n’est pas évidente, une indication autre que la couleur permet-elle de signaler la prise de focus et le survol à la souris ?

Méthodologie d’évaluation
iOS et Android
  1. Repérer dans l’écran les composants d’interface (liens, boutons) avec du texte intégrés dans un environnement de texte (dans une phrase par exemple), signifiés uniquement par la couleur (sans autre mise en forme qui les distingue du reste du texte dans lequel ils sont intégrés).
  2. Connecter un clavier externe (et paramétrer la navigation au clavier).
  3. Vérifier que la visibilité du focus telle que définie au niveau du système est préservée sur ces éléments.
  4. Connecter une souris.
  5. Vérifier que le survol des composants interactifs en environnement de texte est signifié par un autre moyen que la couleur (mise en gras, soulignement par exemple).
  6. Si c’est le cas, le critère est validé.
Correspondances

Critère 8.5 [A] Dans chaque écran, pour chaque élément recevant le focus, la prise de focus est-elle visible ?

Méthodologie d’évaluation
iOS
  1. Connecter un clavier externe (et paramétrer la navigation au clavier).
  2. Activer tous les paramètres disponibles de style de focus.
  3. Naviguer dans l’application et évaluer si la visibilité du focus telle que définie au niveau du système est préservée sur l’ensemble des éléments de l’application.
  4. Si c’est le cas, le critère est validé.
Android
  1. Connecter un clavier externe (et paramétrer la navigation au clavier).
  2. Naviguer dans l’application et évaluer si la visibilité du focus telle que définie au niveau du système est préservée sur l’ensemble des éléments de l’application.
  3. Si c’est le cas, le critère est validé.
Correspondances

Critère 8.6 [A] Dans chaque écran, l’information ne doit pas être donnée uniquement par la forme, taille ou position. Cette règle est-elle respectée ?

Sont concernés les mots ou ensemble de mots, les textes, les éléments graphiques porteurs d’informations et les médias temporels.

Méthodologie d’évaluation
iOS et Android
  1. Repérer dans l’écran les informations données par la forme, la taille ou la position dans un texte, un élément graphique, un média temporel ou non temporel. Ce peut être une icône positionnée à gauche d’un composant pour signifier qu’il est actif, ou une consigne dans l’écran qui demande d’activer un composant positionné à un certain endroit dans l’écran.
  2. Vérifier qu’il existe un autre moyen de récupérer cette information dans l’écran (par exemple, un texte lisible par tous qui donne la même information).
  3. Si ce n’est pas le cas, activer le lecteur d’écran et vérifier qu’une information alternative à la forme, la taille ou la position et restituée par le lecteur d’écran.
  4. Si c’est le cas, le critère est validé.
Correspondances

Critère 8.7 [AA] Dans chaque écran, les contenus additionnels apparaissant à la prise de focus ou au survol d’un composant d’interface sont-ils contrôlables par l’utilisateur (hors cas particuliers) ?

  • Test 8.7.1 : Chaque contenu additionnel devenant visible à la prise de focus ou au survol d’un composant d’interface peut-il être masqué par une action de l’utilisateur sans déplacer le focus ou le pointeur de la souris (hors cas particuliers) ?
  • Test 8.7.2 : Chaque contenu additionnel qui apparaît au survol d’un composant d’interface peut-il être survolé par le pointeur de la souris sans disparaître (hors cas particuliers) ?
  • Test 8.7.3 : Chaque contenu additionnel qui apparaît à la prise de focus ou au survol d’un composant d’interface vérifie-t-il une de ces conditions (hors cas particuliers) ?
    • Le contenu additionnel reste visible jusqu’à ce que l’utilisateur retire le pointeur souris ou le focus du contenu additionnel et du composant d’interface ayant déclenché son apparition ;
    • Le contenu additionnel reste visible jusqu’à ce que l’utilisateur déclenche une action masquant ce contenu sans déplacer le focus ou le pointeur de la souris du composant d’interface ayant déclenché son apparition ;
    • Le contenu additionnel reste visible jusqu’à ce qu’il ne soit plus valide.
Cas particuliers

Le critère est non applicable lorsque le contenu additionnel est contrôlé par la plateforme (par exemple, attribut title en HTML) ou correspond à une fenêtre modale.

Lorsque le contenu additionnel ne masque ou ne remplace aucun contenu porteur d’information, le test 8.7.1 est non applicable.

Méthodologie d’évaluation
iOS
  1. Connecter un clavier externe (et paramétrer la navigation au clavier).
  2. Parcourir l’écran et repérer les contenus additionnels qui apparaissent à la prise de focus sur un composant d’interface.
  3. Vérifier que le contenu additionnel peut être masqué par une touche du clavier (la touche ESC par exemple).
  4. Vérifier que le contenu additionnel reste visible :
    • jusqu’à ce que le focus soit déplacé en dehors du composant d’interface et du contenu additionnel ;
    • ou tant que le focus est positionné sur le composant d’interface ou dans le contenu additionnel ;
    • ou tant que le contenu additionnel est valide.
  5. Connecter une souris.
  6. Balayer l’écran avec la souris et repérer les contenus additionnels qui apparaissent au survol d’un composant d’interface.
  7. Vérifier que le contenu additionnel peut être survolé par la souris.
  8. Vérifier que le contenu additionnel reste visible :
    • jusqu’à ce que le pointeur de la souris soit déplacé en dehors du composant d’interface et du contenu additionnel ;
    • ou tant que le pointeur de la souris survole le composant d’interface ou le contenu additionnel ;
    • ou tant que le contenu additionnel est valide.
  9. Si c’est le cas, le critère est validé.
Android
  1. Connecter un clavier externe (et paramétrer la navigation au clavier).
  2. Parcourir l’écran et repérer les contenus additionnels qui apparaissent à la prise de focus sur un composant d’interface.
  3. Vérifier que le contenu additionnel peut être masqué par une touche du clavier (généralement la touche ou la combinaison de touches qui aura été associée dans Switch Access pour le paramètre Retour)
  4. Vérifier que le contenu additionnel reste visible :
    • jusqu’à ce que le focus soit déplacé en dehors du composant d’interface et du contenu additionnel ;
    • ou tant que le focus est positionné sur le composant d’interface ou dans le contenu additionnel ;
    • ou tant que le contenu additionnel est valide.
  5. Connecter une souris.
  6. Balayer l’écran avec la souris et repérer les contenus additionnels qui apparaissent au survol d’un composant d’interface.
  7. Vérifier que le contenu additionnel peut être survolé par la souris.
  8. Vérifier que le contenu additionnel reste visible :
    • jusqu’à ce que le pointeur de la souris soit déplacé en dehors du composant d’interface et du contenu additionnel ;
    • ou tant que le pointeur de la souris survole le composant d’interface ou le contenu additionnel ;
    • ou tant que le contenu additionnel est valide.
  9. Si c’est le cas, le critère est validé.
Correspondances

Thématique 9 : Formulaires

Critère 9.1 [A] Chaque champ de formulaire a-t-il une étiquette visible ?

Méthodologie d’évaluation
iOS et Android
  1. Repérer dans l’écran les champs de formulaire (champ de saisie, bouton radio, case à cocher).
  2. Vérifier la présence d’une étiquette visible adjacente.
  3. Activer le champ de formulaire (par exemple, saisir du texte).
  4. Vérifier que l’étiquette reste visible.
  5. Si c’est le cas, le critère est validé.
Correspondances

Critère 9.2 [A] Chaque champ de formulaire a-t-il une étiquette accessible aux technologies d’assistance ?

Méthodologie d’évaluation
iOS avec VoiceOver
  1. Activer le lecteur d’écran.
  2. Naviguer jusqu’aux éléments de formulaire en utilisant les gestes du lecteur d’écran.
  3. Vérifier qu’une étiquette est restituée lorsque le focus du lecteur d’écran est sur le champ de formulaire.
  4. Si c’est le cas, le critère est validé.
iOS avec le contrôle vocal
  1. Activer le contrôle vocal.
  2. Repérer dans l’écran tous les champs de formulaire.
  3. Vérifier qu’une étiquette est détectée par le contrôle vocal (apparition d’une infobulle grise au-dessus du champ).
  4. Si c’est le cas, le critère est validé.
Android
  1. Activer le lecteur d’écran.
  2. Naviguer jusqu’aux éléments de formulaire en utilisant les gestes du lecteur d’écran.
  3. Vérifier qu’une étiquette est restituée lorsque le focus du lecteur d’écran est sur le champ de formulaire.
  4. Si c’est le cas, le critère est validé.
Correspondances

Critère 9.3 [A] Chaque étiquette associée à un champ de formulaire est-elle pertinente ?

Test 9.3.1 : Chaque étiquette associée à un champ de formulaire respecte-t-elle ces conditions ?

  • L’étiquette accessible aux technologies d’assistance est pertinente ;
  • L’étiquette visible est contenue dans l’étiquette accessible aux technologies d’assistance.
Méthodologie d’évaluation
iOS avec VoiceOver
  1. Activer le lecteur d’écran.
  2. Naviguer jusqu’aux éléments de formulaire en utilisant les gestes du lecteur d’écran.
  3. Vérifier :
    • que l’étiquette restituée par le lecteur d’écran est pertinente (elle permet de comprendre la nature de la saisie attendue) ;
    • que l’étiquette visible est contenue dans l’étiquette restituée par le lecteur d’écran.
  4. Si c’est le cas, le critère est validé.
Avec le contrôle vocal
  1. Activer le contrôle vocal.
  2. Repérer dans l’écran tous les champs de formulaire.
  3. Vérifier :
    • que l’étiquette détectée par le contrôle vocal (infobulle grise) est pertinente (elle permet de comprendre la nature de la saisie attendue) ;
    • que l’étiquette visible est contenue dans l’étiquette détectée par le contrôle vocal (infobulle grise).
  4. Si c’est le cas, le critère est validé.
Android
  1. Activer le lecteur d’écran.
  2. Naviguer jusqu’aux éléments de formulaire en utilisant les gestes du lecteur d’écran.
  3. Vérifier :
    • que l’étiquette restituée par le lecteur d’écran est pertinente (elle permet de comprendre la nature de la saisie attendue) ;
    • que l’étiquette visible est contenue dans l’étiquette restituée par le lecteur d’écran.
  4. Si c’est le cas, le critère est validé.
Correspondances

Critère 9.4 [A] Chaque étiquette de champ et son champ associé sont-ils accolés ?

Méthodologie d’évaluation
iOS et Android
  1. Repérer dans l’écran tous les champs de formulaire.
  2. Pour chaque champ de formulaire, vérifier que l’étiquette visible est accolée au champ auquel elle est liée.
  3. Si c’est le cas, le critère est validé.
Correspondances

Critère 9.5 [A] Dans chaque formulaire, l’intitulé de chaque bouton est-il pertinent ?

Test 9.5.1 : Chaque bouton de formulaire respecte-t-il ces conditions ?

  • L’intitulé du bouton accessible aux technologies d’assistance est pertinent ;
  • L’intitulé visible du bouton est contenu dans l’intitulé accessible aux technologies d’assistance.
Méthodologie d’évaluation

2 méthodes d’évaluation sur iOS sont proposées. Les deux méthodes aboutissent aux mêmes résultats. Une seule de ces méthodes est nécessaire pour évaluer le critère sur iOS.

iOS avec VoiceOver
  1. Activer le lecteur d’écran.
  2. Naviguer jusqu’aux boutons de formulaire en utilisant les gestes du lecteur d’écran.
  3. Vérifier :
    • que l’intitulé restitué par le lecteur d’écran est pertinent (il permet de comprendre l’action du bouton) ;
    • que l’intitulé visible est contenu dans l’intitulé restitué par le lecteur d’écran.
  4. Si c’est le cas, le critère est validé.
iOS avec le contrôle vocal
  1. Activer le contrôle vocal.
  2. Repérer dans l’écran les boutons de formulaire.
  3. Vérifier :
    • que l’intitulé détecté par le contrôle vocal (infobulle grise) est pertinent (il permet de comprendre l’action du bouton) ;
    • que l’intitulé visible est contenu dans l’intitulé détecté par le contrôle vocal (infobulle grise) ;
  4. Si c’est le cas, le critère est validé.
Android
  1. Activer le lecteur d’écran.
  2. Naviguer jusqu’aux boutons de formulaire en utilisant les gestes du lecteur d’écran.
  3. Vérifier :
    • que l’intitulé restitué par le lecteur d’écran est pertinent (il permet de comprendre l’action du bouton) ;
    • que l’intitulé visible est contenu dans l’intitulé restitué par le lecteur d’écran.
  4. Si c’est le cas, le critère est validé.
Correspondances

Critère 9.6 [A] Dans chaque formulaire, les champs de même nature sont-ils identifiés, si nécessaire ?

Test 9.6.1 : Les champs de même nature respectent-ils ces conditions, si nécessaire ?

  • Les champs sont regroupés dans un élément commun ;
  • Le regroupement possède un titre pertinent.
Méthodologie d’évaluation
iOS et Android
  1. Activer le lecteur d’écran.
  2. Repérer dans l’écran les champs de même nature qui nécessitent d’être regroupés (par exemple, les champs de saisies des différentes suites de chiffres d’un code de carte bleue).
  3. Vérifier :
    • qu’une information est restituée à la prise de focus sur le premier champ, qui permette d’identifier le groupe auquel appartient le champ (bien que cela soit important pour les utilisateurs, il n’est pas requis que l’information du regroupement soit restituée sur chacun des champs de formulaire, mais seulement au moins sur le premier champ du regroupement) ;
    • que l’information restituée est pertinente, c’est-à-dire qu’elle permet de comprendre quelle est la nature du regroupement.
  4. Si c’est le cas, le critère est validé.
Correspondances

Critère 9.7 [A] Les champs de formulaire obligatoires sont-ils correctement identifiés (hors cas particuliers) ?

Test 9.7.1 : Chaque champ de formulaire obligatoire vérifie-t-il ces conditions ?

  • Le caractère obligatoire est visible ;
  • Le caractère obligatoire est accessible aux technologies d’assistance.
Cas particulier

Le critère est non applicable lorsque le formulaire comporte un seul champ de formulaire ou qu’il indique les champs optionnels de manière :

  • visible ;
  • dans l’étiquette du champ.

Dans le cas où l’ensemble des champs d’un formulaire sont obligatoires, le critère reste applicable.

Méthodologie d’évaluation
iOS et Android
  1. Activer le lecteur d’écran.
  2. Valider le formulaire sans saisir de données afin d’identifier les champs obligatoires.
  3. Pour chaque champ obligatoire, Vérifier :
    • que les informations restituées par le lecteur d’écran à la prise de focus sur le champ contiennent la mention du caractère obligatoire ;
    • et qu’un texte visible à proximité du champ indique le caractère obligatoire du champ de formulaire.
  4. Si c’est le cas, le critère est validé.
Correspondances

Critère 9.8 [A] Pour chaque champ de formulaire obligatoire, le type de données et/ou de format attendu est-il disponible ?

Test 9.8.1 : Chaque champ de formulaire obligatoire respecte-t-il ces conditions ?

  • Le type de données et/ou de format est visible ;
  • Le type de données et/ou de format est accessible aux technologies d’assistance.
Méthodologie d’évaluation
iOS et Android
  1. Activer le lecteur d’écran.
  2. Remplir les champs de formulaire avec des valeurs susceptibles de provoquer des erreurs de saisies (entrer une adresse e-mail mal formée par exemple).
  3. Valider le formulaire.
  4. Pour chaque champ de formulaire obligatoire qui possède un contrôle du format (qui sera présenté avec une erreur après la validation), vérifier :
    • que le type de données et/ou le format attendu sont restitués par le lecteur d’écran à la prise de focus sur le champ ;
    • qu’un texte visible à proximité du champ indique le type de données et/ou le format attendu.
  5. Si c’est le cas, le critère est validé.
Correspondances

Critère 9.9 [A] Dans chaque formulaire, les erreurs de saisie sont-elles accessibles ?

Test 9.9.1 : Chaque erreur de saisie respecte-t-elle ces conditions ?

  • L’erreur de saisie est visible ;
  • L’erreur de saisie est accessible aux technologies d’assistance.
Méthodologie d’évaluation
iOS et Android
  1. Activer le lecteur d’écran.
  2. Remplir les champs de formulaire avec des valeurs susceptibles de provoquer des erreurs de saisie (laisser un champ vide, entrer une adresse e-mail mal formée par exemple).
  3. Valider le formulaire.
  4. Pour chaque champ en erreur, vérifier :
    • que le message d’erreur est visible à proximité du champ ;
    • que le message d’erreur est restitué par le lecteur d’écran à la prise de focus sur le champ.
  5. Si c’est le cas, le critère est validé.
Correspondances

Critère 9.10 [AA] Dans chaque formulaire, le contrôle de saisie est-il accompagné, si nécessaire, de suggestions des types, formats de données ou valeurs attendus ?

Test 9.10.1 : Dans chaque formulaire, le contrôle de saisie vérifie-t-il ces conditions ?

  • Le contrôle de saisie est accompagné, si nécessaire, de suggestions des types et formats de données attendus ;
  • Le contrôle de saisie est accompagné, si nécessaire, de suggestions de valeurs attendues.
Méthodologie d’évaluation
iOS et Android
  1. Activer le lecteur d’écran.
  2. Remplir les champs de formulaire avec des valeurs susceptibles de provoquer des erreurs de saisies (entrer une adresse e-mail mal formée par exemple).
  3. Valider le formulaire.
  4. Pour chaque champ en erreur qui possède un contrôle du format, vérifier la présence d’un exemple réel de saisie dans le message d’erreur (par exemple, pour une adresse e-mail, vérifier la mention d’une adresse réelle sur le modèle « jean.schmitt@accessibilite.lu »).
  5. Si c’est le cas, le critère est validé.
Correspondances

Critère 9.11 [AA] Pour chaque formulaire qui modifie ou supprime des données, ou qui transmet des réponses à un test ou à un examen, ou dont la validation a des conséquences financières ou juridiques, les données saisies peuvent-elles être modifiées, mises à jour ou récupérées par l’utilisateur ?

Méthodologie d’évaluation
iOS et Android
  1. Activer le lecteur d’écran.
  2. Remplir le formulaire.
  3. Pour chaque donnée à caractère financier (par exemple, une indication de revenu), juridique (par exemple, une référence d’acte administratif), personnelle (par exemple, un numéro de téléphone), pour chaque formulaire qui transmet des réponses à un test ou à un examen, vérifier que l’utilisateur peut :
    • modifier ou annuler les données et les actions effectuées sur ces données en cours de saisie (par exemple la saisie du champ et la fonctionnalité d’annulation d’édition du navigateur ne sont pas désactivées) ;
    • ou confirmer, de manière explicite, l’envoi de ces données via un mécanisme dédié (par exemple, un champ de formulaire ou une étape supplémentaire).
  4. Pour chaque formulaire qui modifie ou supprime des données (par exemple la suppression d’une adresse postale), vérifier que l’utilisateur peut :
    • récupérer les données supprimées en cours de saisie ;
    • ou confirmer, de manière explicite, la suppression de ces données via un mécanisme dédié (par exemple, un champ de formulaire ou une étape supplémentaire).
  5. Si c’est le cas, le critère est validé.
Correspondances

Critère 9.12 [AA] Pour chaque champ qui attend une donnée personnelle de l’utilisateur, la saisie est-elle facilitée ?

Test 9.12.1 : Chaque champ qui attend une donnée personnelle de l’utilisateur respecte-t-il ces conditions ?

Méthodologie d’évaluation
iOS
  1. Accéder à chacun des champs de formulaire (taper sur le champ de saisie par exemple pour activer l’apparition des contrôles de saisie).
  2. Pour chaque champ qui attend une donnée personnelle sur l’utilisateur, vérifier que les contrôles natifs adéquats de la plateforme sont présentés à l’utilisateur. Par exemple :
    • pour un champ demandant la saisie de l’adresse e-mail de l’utilisateur, le clavier présenté possède le caractère @ sans que l’utilisateur ait de manipulation de clavier à réaliser (comme afficher le clavier secondaire) ;
    • pour un champ demandant la saisie d’un numéro de téléphone, le pavé numérique est présenté directement à l’utilisateur ;
    • etc.
  3. Vérifier que le formulaire est compatible avec un mécanisme de remplissage automatique. Par exemple, iOS permet un remplissage automatique des champs sur la base des dernières valeurs saisies en fonction de leur nature (adresse postale, ville, nom, prénom, adresse e-mail). Vérifier que des valeurs pertinentes sont suggérées sur ces champs.
  4. Si c’est le cas, le critère est validé.
Android
  1. Accéder à chacun des champs de formulaire (taper sur le champ de saisie par exemple pour activer l’apparition des contrôles de saisie).
  2. Pour chaque champ qui attend une donnée personnelle sur l’utilisateur, vérifier que les contrôles natifs adéquats de la plateforme sont présentés à l’utilisateur. Par exemple :
    • pour un champ demandant la saisie de l’adresse e-mail de l’utilisateur, le clavier présenté possède le caractère @ sans que l’utilisateur ait de manipulation de clavier à réaliser (comme afficher le clavier secondaire) ;
    • pour un champ demandant la saisie d’un numéro de téléphone, le pavé numérique est présenté directement à l’utilisateur ;
    • etc.
  3. Vérifier que le formulaire est compatible avec un mécanisme de remplissage automatique. Par exemple, Google fournit un système de remplissage automatique sur Android. Aller dans Paramètres > Système > Langues et saisie > Paramètres avancés > Service de saisie automatique (selon la version de la plateforme, le chemin d’accès peut être différent) pour activer et paramétrer les données.
  4. Sur le formulaire de l’application, vérifier que le système vous propose une option pour remplir automatiquement avec les données renseignées.
  5. Si c’est le cas, le critère est validé.
Correspondances

Thématique 10 : Navigation

Critère 10.1 [A] Dans chaque écran, l’ordre de tabulation au clavier est-il cohérent ?

Méthodologie d’évaluation
iOS et Android
  1. Connecter un clavier externe (et paramétrer la navigation au clavier).
  2. Naviguer sur l’ensemble des éléments de l’écran et vérifier que l’ordre de tabulation reste cohérent. Il n’est pas obligatoire que la tabulation suive l’ordre de lecture naturel (de gauche à droite et de haut en bas par exemple) tant que les éléments sont accessibles dans un ordre cohérent.
  3. Repérer dans l’écran les composants (bouton par exemple) qui mettent à jour un contenu (affichage d’élément masqué, mise à jour dynamique de contenus par exemple) :
    1. activer le composant ;
    2. après l’affichage du contenu mis à jour, vérifier que la tabulation reste cohérente.
  4. Si c’est le cas, le critère est validé.
Correspondances

Critère 10.2 [A] Dans chaque écran, l’ordre de restitution par les technologies d’assistance est-il cohérent ?

Méthodologie d’évaluation
iOS et Android
  1. Activer le lecteur d’écran.
  2. Naviguer sur l’ensemble des éléments de l’écran avec les gestes du lecteur d’écran et vérifier que l’ordre d’accès aux éléments de l’écran (composants interactifs et textes) reste cohérent. Il n’est pas obligatoire que l’ordre suive l’ordre de lecture naturel (de gauche à droite et de haut en bas par exemple) tant que les éléments sont accessibles dans un ordre cohérent qui ne pose pas de problèmes de compréhension.
  3. Repérer dans l’écran les composants (bouton par exemple) qui mettent à jour un contenu (affichage d’élément masqué, mise à jour dynamique de contenus par exemple) :
    1. activer le composant ;
    2. après l’affichage du contenu mis à jour, vérifier que le parcours du lecteur d’écran reste cohérent.
  4. Si c’est le cas, le critère est validé.

Exemple de contenu dont l’implémentation pose un problème de compréhension : une heure d’arrivée et une heure de départ sont affichées à l’écran sous forme de deux blocs d’informations visuelles (heure d’arrivée 17h00 ; heure de départ 18h00). Le lecteur d’écran atteint séquentiellement « heure d’arrivée » puis « heure de départ » puis « 17h00 » et enfin « 18h00 ». L’ordre de lecture ne correspond pas à l’ordre visuel, et l’ordre de lecture est problématique puisqu’il ne permet pas de lier les informations entre elles.

Correspondances

Critère 10.3 [A] Dans chaque écran, la navigation ne doit pas contenir de piège au clavier. Cette règle est-elle respectée ?

Test 10.3.1 : Dans chaque écran, chaque élément recevant le focus vérifie-t-il une de ces conditions ?

  • Il est possible d’atteindre l’élément suivant ou précédent pouvant recevoir le focus avec le clavier ;
  • L’utilisateur est informé d’un mécanisme fonctionnel permettant d’atteindre au clavier l’élément suivant ou précédent pouvant recevoir le focus.
Méthodologie d’évaluation
iOS
  1. Connecter un clavier externe (et paramétrer la navigation au clavier).
  2. Naviguer sur l’ensemble des éléments de l’écran en utilisant les touches du clavier dédiées (par défaut dans iOS, ce sont les touches Tab et les flèches de direction qui sont utilisées pour naviguer dans les contenus).
  3. Vérifier que :
    • à partir de la position courante, l’élément focusable suivant ou précédent est atteignable avec les touches de navigation du clavier ;
    • l’élément possédant actuellement le focus propose une méthode utilisable au clavier (par exemple, un raccourci clavier) permettant d’atteindre l’élément suivant ou précédent.
  4. Si c’est le cas, le critère est validé.

Note : Certains éléments complexes, souvent gérés par la plateforme, peuvent faire appel à des navigations optimisées qui utilisent généralement les flèches de direction pour passer d’une partie du composant à l’autre. Le test sur le piège au clavier se limite alors à vérifier que le composant peut être atteint et qu’il est possible de passer au composant suivant ou revenir au composant précédent. On ne vérifie pas l’utilisation même du composant dans ce critère.

Android
  1. Connecter un clavier externe (et paramétrer la navigation au clavier).
  2. Naviguer sur l’ensemble des éléments de l’écran en utilisant les touches du clavier (les touches ou la combinaison de touches qui aura été associée dans Switch Access pour les paramètres « Passer à l’option suivante » et « Passer à l’option précédente »).
  3. Vérifier que :
    • à partir de la position courante, l’élément focusable suivant ou précédent est atteignable avec la touche de navigation du clavier ;
    • l’élément possédant actuellement le focus propose une méthode utilisable au clavier (par exemple, un raccourci clavier) permettant d’atteindre l’élément suivant ou précédent.
  4. Si c’est le cas, le critère est validé.

Note : Certains éléments complexes, souvent gérés par la plateforme, peuvent faire appel à des navigations optimisées qui utilisent généralement les flèches de direction pour passer d’une partie du composant à l’autre. Le test sur le piège au clavier se limite alors à vérifier que le composant peut être atteint et qu’il est possible de passer au composant suivant ou revenir au composant précédent. On ne vérifie pas l’utilisation même du composant dans ce critère.

Correspondances

Critère 10.4 [A] Dans chaque écran, les raccourcis clavier n’utilisant qu’une seule touche (lettre minuscule ou majuscule, ponctuation, chiffre ou symbole) sont-ils contrôlables par l’utilisateur ?

Test 10.4.1 : Dans chaque écran, chaque raccourci clavier n’utilisant qu’une seule touche (lettre minuscule ou majuscule, ponctuation, chiffre ou symbole) vérifie-t-il l’une de ces conditions ?

  • Un mécanisme est disponible pour désactiver le raccourci clavier ;
  • Un mécanisme est disponible pour configurer la touche de raccourci clavier au moyen des touches de modification (Ctrl, Alt, Maj, etc.) ;
  • Dans le cas d’un composant d’interface, le raccourci clavier qui lui est associé ne peut être activé que si le focus clavier est sur ce composant.
Méthodologie d’évaluation
iOS et Android
  1. Connecter un clavier externe (et paramétrer la navigation au clavier).
  2. Depuis l’application, appuyer successivement sur chacune des touches de caractère imprimable (les lettres minuscules a-z, les majuscules A-Z, les chiffres 0-9, tous les symboles comme $,*,%,! etc. à partir du moment où ils peuvent être inscrits à l’écran).
  3. Si le raccourci clavier est associé à un seul composant isolé de l’écran, vérifier qu’il ne peut être activé que si le focus clavier est à l’intérieur de ce composant.
  4. Sinon, si une action est déclenchée, vérifier la présence dans l’application d’un élément de configuration permettant :
    • de désactiver ces raccourcis clavier à touche unique ;
    • de configurer ces raccourcis clavier en leur ajoutant une touche de modification Ctrl, Alt, Maj, etc.
  5. Si c’est le cas, le critère est validé.
Correspondances

Thématique 11 : Consultation

Critère 11.1 [A] Pour chaque écran, l’utilisateur a-t-il le contrôle de chaque limite de temps modifiant le contenu (hors cas particuliers) ?

Test 11.1.1 : Chaque limite de temps respecte-t-elle une de ces conditions ?

  • L’utilisateur peut arrêter ou relancer le rafraîchissement ;
  • L’utilisateur peut augmenter la limite de temps entre deux rafraîchissements de dix fois, au moins ;
  • L’utilisateur est averti de l’imminence du rafraîchissement et dispose de vingt secondes, au moins, pour augmenter la limite de temps avant le prochain rafraîchissement ;
  • La limite de temps entre deux rafraîchissements est de vingt heures, au moins.
Cas particuliers

Le critère est non applicable lorsque la limite de temps est essentielle, notamment lorsqu’elle ne pourrait pas être supprimée sans changer fondamentalement le contenu ou les fonctionnalités liées au contenu.

Méthodologie d’évaluation
iOS et Android
  1. Repérer les procédés limitant le temps d’une session (par exemple après une authentification).
  2. Vérifier :
    • la présence d’un mécanisme permettant à l’utilisateur de supprimer la limite de temps (par exemple, un bouton à bascule permettant à l’utilisateur d’activer ou désactiver la limite de temps de la session) ;
    • ou la présence d’un mécanisme permettant à l’utilisateur d’augmenter la limite de temps (par exemple, une liste déroulante avec des valeurs de temps de connexion disponibles) ;
    • ou la présence d’un mécanisme qui avertit l’utilisateur de l’imminence de la limite de temps et laisse 20 secondes, au moins, à l’utilisateur pour augmenter la limite de temps (par exemple, l’ouverture d’une modale avec un bouton permettant d’augmenter la limite de temps) ;
    • ou que la limite de temps est de vingt heures, au moins.
  3. Si c’est le cas, le critère est validé.
Correspondances

Critère 11.2 [A] Pour chaque écran, chaque procédé limitant le temps d’une session peut-il être arrêté ou supprimé (hors cas particuliers) ?

Test 11.2.1 : Chaque procédé limitant le temps d’une session respecte-t-il une de ces conditions ?

  • L’utilisateur peut supprimer la limite de temps ;
  • L’utilisateur peut augmenter la limite de temps ;
  • La limite de temps avant la fin de la session est de vingt heures au moins.
Cas particuliers

Le critère est non applicable lorsque la limite de temps est essentielle, notamment lorsqu’elle ne pourrait pas être supprimée sans changer fondamentalement le contenu ou les fonctionnalités liées au contenu.

Méthodologie d’évaluation
iOS et Android
  1. Repérer les limites de temps de session (par exemple, la déconnexion d’un compte client).
  2. Vérifier :
    • la présence d’un mécanisme permettant à l’utilisateur de supprimer la limite de temps (par exemple, un bouton avec un intitulé explicite) ;
    • ou la présence d’un mécanisme permettant à l’utilisateur d’augmenter la limite de temps (par exemple, un paramètre disponible dans l’application pour gérer les temps de sessions) ;
    • ou que la durée de la session est de vingt heures, au moins.
  3. Si c’est le cas, le critère est validé.
Correspondances

Critère 11.3 [A] Dans chaque écran, chaque document bureautique en téléchargement possède-t-il, si nécessaire, une version accessible (hors cas particuliers) ?

Test 11.3.1 : Chaque document bureautique vérifie-t-il une de ces conditions ?

  • Le document en téléchargement est compatible avec l’accessibilité ;
  • Il existe une version alternative du document en téléchargement compatible avec l’accessibilité ;
  • Il existe une version alternative du document en téléchargement dans l’application accessible aux technologies d’assistance.
Cas particuliers

Le critère est non applicable lorsque les documents bureautiques (ex : PDF, documents Microsoft ou libreOffice, etc.) ont été publiés avant le 23 septembre 2018 (sauf si ces contenus sont nécessaires pour les besoins de processus administratifs actifs concernant des tâches effectuées par l’organisme du secteur public concerné), ils sont exemptés de l’obligation d’accessibilité, d’après la loi du 28 mai 2019.

Méthodologie d’évaluation
iOS et Android
  1. Repérer dans l’écran les composants (un lien, un bouton de formulaire ou un formulaire de téléchargement par exemple) permettant de télécharger un fichier au format bureautique (.doc, .docx, .pdf par exemple).
  2. Pour chaque fichier proposé au téléchargement, dans un format bureautique, vérifier la présence d’une version alternative présentée comme accessible.
  3. Si l’alternative est proposée dans un format bureautique (pdf, odt, doc, docx, EPUB/DAISY) :
  4. Si l’alternative est proposée dans l’application, vérifier que le contenu est conforme au présent référentiel.
  5. Sinon, pour les documents au format bureautique (pdf, odt, doc, docx, EPUB/DAISY) :
  6. Si c’est le cas, le critère est validé.
Correspondances

Critère 11.4 [A] Pour chaque document bureautique ayant une version accessible, cette version offre-t-elle la même information (hors cas particuliers) ?

Cas particuliers

Le critère est non applicable lorsque les documents bureautiques (ex : PDF, documents Microsoft ou libreOffice, etc.) ont été publiés avant le 23 septembre 2018 (sauf si ces contenus sont nécessaires pour les besoins de processus administratifs actifs concernant des tâches effectuées par l’organisme du secteur public concerné), ils sont exemptés de l’obligation d’accessibilité, d’après la loi du 28 mai 2019.

Méthodologie d’évaluation
iOS et Android
  1. Pour chaque fichier proposé au téléchargement dans un format bureautique qui possède une version alternative présentée comme accessible, vérifier que les deux documents (le document d’origine et la version accessible dans un format bureautique ou dans l’application) offrent la même information.
  2. Si c’est le cas, le critère est validé.
Correspondances

Critère 11.5 [A] Dans chaque écran, chaque contenu cryptique (art ASCII, émoticon, syntaxe cryptique) a-t-il une alternative ?

Méthodologie d’évaluation
iOS et Android
  1. Repérer dans l’écran les contenus cryptiques (art ascii, émoticône, syntaxe cryptique).
  2. Vérifier qu’une définition est disponible dans le contexte adjacent (immédiatement avant ou après le contenu cryptique, dans le texte adjacent ou via l’activation d’un composant d’interface).
  3. Sinon, activer le lecteur d’écran.
  4. Naviguer jusqu’au contenu cryptique et vérifier qu’une alternative est restituée.
  5. Si c’est le cas, le critère est validé.
Correspondances

Critère 11.6 [A] Dans chaque écran, pour chaque contenu cryptique (art ASCII, émoticône, syntaxe cryptique) ayant une alternative, cette alternative est-elle pertinente ?

Méthodologie d’évaluation
iOS et Android
  1. Pour chaque contenu cryptique qui possède une alternative, vérifier que l’alternative donnée est pertinente (elle permet de comprendre le contenu ou la fonction).
  2. Si c’est le cas, le critère est validé.
Correspondances

Critère 11.7 [A] Dans chaque écran, les changements brusques de luminosité ou les effets de flash sont-ils correctement utilisés ?

Test 11.7.1 : Les changements brusques de luminosité ou les effets de flash vérifient-ils une de ces conditions ?

  • La fréquence de l’effet est inférieure à 3 par seconde ;
  • La surface totale cumulée des effets est inférieure ou égale à 21 824 pixels.
Méthodologie d’évaluation
iOS et Android
  1. Repérer dans l’écran les contenus clignotants ou qui provoquent des effets de flash : élément graphique animé, vidéo ou animation, effet de mise en forme.
  2. Vérifier :
    • que la fréquence de l’effet est inférieure à 3 flashs par seconde ;
    • ou que la surface cumulée est inférieure à 21824 pixels.
  3. Si c’est le cas, le critère est validé.

Note : L’outil PEAT permet d’analyser les vidéos au format .avi.

Correspondances

Critère 11.8 [A] Dans chaque écran, chaque contenu en mouvement ou clignotant est-il contrôlable par l’utilisateur ?

Test 11.8.1 : Chaque contenu en mouvement ou clignotant respecte-t-il une de ces conditions ?

  • La durée du mouvement ou du clignotement est inférieure ou égale à 5 secondes ;
  • L’utilisateur peut arrêter et relancer le mouvement ou le clignotement ;
  • L’utilisateur peut afficher et masquer le contenu en mouvement ou clignotant ;
  • L’utilisateur peut afficher la totalité de l’information sans le mouvement ou le clignotement.
Méthodologie d’évaluation
iOS et Android
  1. Repérer dans l’écran les contenus en mouvement ou clignotants (un élément graphique, un effet de mise en forme, un carrousel par exemple) déclenchés automatiquement au chargement de l’écran ou lors de l’affichage d’un contenu (cf. note).
  2. Vérifier :
    • que la durée totale du mouvement ou du clignotement est inférieure à 5 secondes ;
    • ou la présence d’un mécanisme (un bouton par exemple) qui permet d’arrêter et de relancer le mouvement ou le clignotement ;
    • ou la présence d’un mécanisme (un bouton par exemple) qui permet de cacher et d’afficher à nouveau le contenu en mouvement ou clignotant ;
    • ou la présence d’un mécanisme (un bouton par exemple) qui permet d’afficher le contenu sans mouvement ou clignotement.
  3. Si c’est le cas, le critère est validé.

Note :

  • l’arrêt ou la mise en pause d’un contenu en mouvement ou clignotant via la prise de focus (l’effet est suspendu uniquement pendant la prise de focus mais reprend une fois la prise de focus perdue) ou au toucher sur le contenu en mouvement (l’effet est suspendu uniquement pendant qu’une pression est effectuée sur le contenu, mais reprend une fois la pression relâchée) ne sont pas considérés comme des procédés conformes.
  • dans certains cas, le mouvement ne peut pas être arrêté, par exemple, une barre de progression, dans ce cas, le critère est non applicable.
Correspondances

Critère 11.9 [AA] Dans chaque écran, le contenu proposé est-il consultable quelle que soit l’orientation de l’écran (portrait ou paysage) (hors cas particuliers) ?

Test 11.9.1 : Dans chaque écran, chaque contenu vérifie-t-il ces conditions ?

  • La consultation est possible quel que soit le mode d’orientation de l’écran ;
  • Le contenu proposé reste le même quel que soit le mode d’orientation de l’écran même si sa présentation et le moyen d’y accéder peuvent différer.
Cas particuliers

Le critère est non applicable lorsque l’orientation du périphérique est essentielle à l’utilisation de l’application, par exemple : interfaces de jeu, de piano, etc. Si l’interface est le seul moyen d’accéder au service proposé, une alternative devrait être mise en place.

Méthodologie d’évaluation
iOS
  1. Ouvrir le Centre de contrôle.
  2. Vérifier que l’orientation de l’écran n’est pas verrouillée dans les paramètres de la plateforme (voir la documentation officielle).
  3. Afficher l’application et basculer le terminal alternativement en mode paysage et portrait.
  4. Vérifier :
    • que l’application est utilisable dans les deux orientations, c’est-à-dire que les éléments de l’application sont repositionnés pour être lisibles ;
    • que les contenus disponibles dans une orientation sont toujours disponibles dans l’autre orientation (directement ou par l’activation d’un composant supplémentaire par exemple).
  5. Si c’est le cas, le critère est validé.
Android
  1. Ouvrir le panneau de configuration rapide.
  2. Vérifier que le paramètre « Rotation automatique » est activé (voir la documentation officielle).
  3. Afficher l’application et basculer le terminal alternativement en mode paysage et portrait.
  4. Vérifier :
    • que l’application est utilisable dans les deux orientations, c’est-à-dire que les éléments de l’application sont repositionnés pour être lisibles ;
    • que les contenus disponibles dans une orientation sont toujours disponibles dans l’autre orientation (directement ou par l’activation d’un composant supplémentaire par exemple).
  5. Si c’est le cas, le critère est validé.
Correspondances

Critère 11.10 [A] Dans chaque écran, les fonctionnalités activables au moyen d’un geste complexe sont-elles activables au moyen d’un geste simple (hors cas particuliers) ?

Cas particuliers

Le critère est non applicable pour les éléments suivants :

  • Les gestes requis par la plateforme.
  • Les fonctionnalités pour lesquelles la réalisation d’un geste complexe est essentielle (exécuter le tracé d’une signature, par exemple).
Méthodologie d’évaluation
iOS et Android
  1. Repérer dans l’écran les fonctionnalités qui nécessitent de réaliser des gestes complexes (repérer la présence de consignes dans l’interface ou dans une documentation associée à l’application), par exemple :
    • l’utilisation simultanée de deux doigts ou plus ;
    • la réalisation d’un tracé de trajectoire (comme le geste swipe).
  2. Vérifier qu’il existe une méthode alternative pour réaliser l’action associée avec un geste simple, par exemple l’appui sur une seule touche du clavier ou un bouton.
  3. Si c’est le cas, le critère est validé.
Correspondances

Critère 11.11 [A] Dans chaque écran, les fonctionnalités activables par la réalisation d’actions simultanées sont-elles activables au moyen d’une action unique. Cette règle est-elle respectée (hors cas particuliers) ?

Cas particuliers

Le critère est non applicable pour les actions requises par la plateforme.

Méthodologie d’évaluation
iOS et Android
  1. Repérer dans l’écran les fonctionnalités qui nécessitent la réalisation de deux actions simultanées, par exemple :
    • l’utilisation simultanée de deux touches d’un clavier ou plus ;
    • devoir énoncer une commande vocale et toucher l’écran en même temps pour réaliser une action.
  2. Vérifier qu’il existe dans l’écran ou l’application une méthode alternative pour réaliser l’action associée avec une action unique, par exemple l’appui sur un bouton.
  3. Si c’est le cas, le critère est validé.
Correspondances
  • WCAG 2.1 : N/A
  • EN 301 549 V3.2.1 (2021-03) : 5.9 Simultaneous user actions.

Critère 11.12 [A] Dans chaque écran, les actions déclenchées au moyen d’un dispositif de pointage sur un point unique de l’écran peuvent-elles faire l’objet d’une annulation (hors cas particuliers) ?

Test 11.12.1 : Dans chaque écran, les actions déclenchées au moyen d’un dispositif de pointage sur un point unique de l’écran vérifient-elles l’une de ces conditions (hors cas particuliers) ?

  • L’action est déclenchée au moment où le dispositif de pointage est relâché ou relevé ;
  • L’action est déclenchée au moment où le dispositif de pointage est pressé ou posé puis annulée lorsque le dispositif de pointage est relâché ou relevé ;
  • L’action est complexe et un mécanisme est disponible pour abandonner (avant achèvement de l’action) ou annuler (après achèvement) l’exécution de l’action.
Cas particuliers

Le critère est non applicable lorsque la fonctionnalité nécessite que le comportement attendu soit réalisé lors d’un événement descendant, par exemple, un émulateur de clavier dont les touches doivent s’activer à la pression comme sur un clavier physique.

Méthodologie d’évaluation
iOS et Android
  1. Repérer dans l’écran les composants interactifs (par exemple, bouton ou lien).
  2. Pour chaque composant interactif, effectuer un appui simple dessus et conserver la pression.
  3. Déplacer le doigt en dehors de la zone interactive et constater que l’action associée n’est pas déclenchée.
  4. Si c’est le cas, le critère est validé.
Correspondances

Critère 11.13 [A] Dans chaque écran, les fonctionnalités qui impliquent un mouvement de l’appareil ou vers l’appareil peuvent-elles être satisfaites de manière alternative (hors cas particuliers) ?

Test 11.13.1 : Chaque fonctionnalité qui implique un mouvement de l’appareil ou vers l’appareil respecte-t-elle ces conditions ?

  • La fonctionnalité peut être déclenchée avec un composant d’interface ;
  • L’utilisateur a la possibilité de désactiver la détection du mouvement pour éviter un déclenchement accidentel de la fonctionnalité.
Cas particuliers

Le critère est non applicable lorsque :

  • Le mouvement est essentiel à l’accomplissement de la fonctionnalité (ex. podomètre).
  • La détection du mouvement est utilisée pour contrôler une fonctionnalité au travers d’une interface compatible avec l’accessibilité.
Méthodologie d’évaluation
iOS et Android
  1. Repérer dans l’écran les fonctionnalités qui se déclenchent au moyen d’un mouvement de l’appareil ou d’un geste vers l’appareil (repérer par exemple la présence de consignes dans l’interface ou dans une documentation associée à l’application qui décrive ce type de déclenchement).
  2. Vérifier :
    • que la fonctionnalité peut être déclenchée sans mouvement, par exemple par l’activation d’un bouton ou d’un lien ;
    • et que l’application propose une méthode pour désactiver la détection du mouvement (par exemple, un paramètre dans l’application).
  3. Si c’est le cas, le critère est validé.
Correspondances

Critère 11.14 [AA] Pour chaque fonctionnalité de conversion d’un document, les informations relatives à l’accessibilité disponibles dans le document source sont-elles conservées dans le document de destination (hors cas particuliers) ?

Sont concernés tous les formats numériques tels que le texte, l’audio et la vidéo.

Cas particuliers

Le critère est non applicable lorsque le format de conversion ne dispose pas des éléments nécessaires à l’identification des informations d’accessibilité. Par exemple, si la conversion se fait depuis un format HTML vers un format TXT, alors le critère est non applicable.

Méthodologie d’évaluation
iOS et Android
  1. Repérer dans l’écran les fonctionnalités de conversion de document (par exemple exportation en PDF, en .odt, HTML etc.)
  2. Repérer dans le contenu original les informations d’accessibilité présentes (par exemple, une alternative d’un élément graphique, des niveaux de titres, une table des matières).
  3. Vérifier que dans le document résultant de la conversion, les informations d’accessibilité sont toujours présentes (sauf si le format de conversion choisi ne possède pas de support pour les informations d’accessibilité du document source).
  4. Si c’est le cas, le test est validé.
Correspondances
  • WCAG 2.1 : N/A
  • EN 301 549 V3.2.1 (2021-03) : 5.4 Preservation of accessibility information during conversion.

Critère 11.15 [A] Chaque fonctionnalité d’identification ou de contrôle de l’application qui repose sur l’utilisation de caractéristique biologique de l’utilisateur, dispose-t-elle d’une méthode alternative ?

Test 11.15.1 : Chaque fonctionnalité d’identification ou de contrôle de l’application qui repose sur l’utilisation de caractéristique biologique de l’utilisateur respecte-t-elle une de ces conditions ?

  • Il existe une alternative qui ne repose pas sur une caractéristique biologique de l’utilisateur ;
  • Il existe une alternative qui repose sur une caractéristique biologique de l’utilisateur qui soit suffisamment différente.
Méthodologie d’évaluation
iOS et Android
  1. Repérer dans l’écran les fonctionnalités d’identification (authentification) et de contrôle qui reposent sur l’utilisation de caractéristiques biologiques (par exemple reconnaissance vocale, empreinte digitale, reconnaissance faciale).
  2. Vérifier qu’il existe une méthode alternative pour réaliser l’action, par exemple :
    • pour une fonctionnalité d’authentification qui passe par une reconnaissance d’empreinte digitale, un bouton est disponible sur l’écran de connexion pour accéder à la saisie d’un mot de passe à la place.
    • pour une fonctionnalité d’authentification qui passe par une reconnaissance vocale, l’application propose également une reconnaissance d’empreinte digitale (si la méthode alternative repose également sur une caractéristique biologique, il est souhaitable qu’elle n’implique pas une caractéristique biologique similaire. Par exemple, si la méthode initiale implique la voix, la méthode alternative ne devrait pas impliquer la voix.)
  3. Si c’est le cas, le critère est validé.
Correspondances
  • WCAG 2.1 : N/A
  • EN 301 549 V3.2.1 (2021-03) : 5.3 Biometrics.

Critère 11.16 [A] Pour chaque application qui intègre une fonctionnalité de répétition des touches, la répétition est-elle ajustable (hors cas particuliers) ?

Test 11.16.1 : Pour chaque application qui intègre une fonctionnalité de répétition des touches, les conditions suivantes sont-elles respectées ?

  • Le délai de déclenchement de la fonction de répétition peut être paramétré à 2 secondes au moins ;
  • Le délai entre deux répétitions peut être paramétré au moins à 2 secondes.
Cas particuliers

Le critère est non applicable :

  • Pour les répétitions de touches gérées au niveau de la plateforme ;
  • Pour les applications qui disposent d’une méthode permettant de désactiver la fonctionnalité de répétition des touches.
Méthodologie d’évaluation
iOS et Android
  1. Repérer dans l’application la présence d’une fonctionnalité de répétition de touches (repérer par exemple la présence de consignes dans l’interface ou dans une documentation associée à l’application).
  2. Vérifier que le délai de déclenchement de la fonction de répétition (le délai entre la toute première pression de touche à répéter et la mise en œuvre de la fonction de répétition) :
    • est de 2 secondes au moins ;
    • ou qu’il existe une méthode permettant de le paramétrer à 2 secondes au moins (par exemple, un champ de saisie dans les paramètres utilisateurs de l’application).
  3. Vérifier que le délai entre deux répétitions :
    • est de 2 secondes au moins ;
    • ou qu’il existe une méthode permettant de le paramétrer à 2 secondes au moins (par exemple, un champ de saisie dans les paramètres utilisateurs de l’application).
  4. Si c’est le cas, le test est validé.
Correspondances
  • WCAG 2.1 : N/A
  • EN 301 549 V3.2.1 (2021-03) : 5.7 Key repeat.

Thématique 12 : Documentation et fonctionnalités d’accessibilité

Critère 12.1 [AA] La documentation de l’application décrit-elle les fonctionnalités d’accessibilité de l’application et leur utilisation ?

Test 12.1.1 : La documentation de l’application inclut-elle les éléments suivants au moins ?

  • Une description des fonctionnalités d’accessibilité de l’application ;
  • Une explication de l’utilisation des fonctionnalités d’accessibilité de l’application ;
  • Des informations concernant l’accessibilité de la plateforme et sa compatibilité avec les technologies d’assistance.
Méthodologie d’évaluation
iOS et Android
  1. Repérer dans l’application la présence d’une documentation, par exemple :
  2. Repérer dans l’application la présence de fonctionnalités d’accessibilité.
  3. Vérifier la présence dans la documentation :
    • de la description des fonctionnalités d’accessibilité de l’application, par exemple :
      • des paramètres d’accessibilité intégrés dans l’application comme la gestion des couleurs, des tailles de polices, la gestion des animations ;
      • un rotor personnalisé sur certains écrans (le rotor est une fonctionnalité des lecteurs d’écran qui permet une navigation rapide entre des types d’éléments d’un écran, certaines plateformes permettent de définir des éléments de navigation rapide spécifique à une application dans ce rotor. Voir une démonstration) ;
      • des gestes ou mouvements d’appareil qui déclenchent des fonctionnalités ;
      • des raccourcis clavier spéciaux disponibles pour certaines technologies d’assistance.
    • de la description des composants complexes pour lesquels il est mis en place une gestion particulière selon les technologies d’assistance ;
    • d’explications sur les modalités d’utilisation de ces fonctionnalités (leur localisation, les méthodes pour les activer) ;
    • de la description des éléments non conformes ou non compatibles avec certaines technologies d’assistance, et de la présence d’alternatives le cas échéant.
  4. Si c’est le cas, le critère est validé.
Correspondances
  • WCAG 2.1 : N/A
  • EN 301 549 V3.2.1 (2021-03) : 12.1.1 Accessibility and compatibility features.

Critère 12.2 [A] Pour chaque fonctionnalité d’accessibilité décrite dans la documentation, l’ensemble du parcours qui permet de l’activer répond aux besoins d’accessibilité des utilisateurs qui en ont besoin. Cette règle est-elle respectée (hors cas particuliers) ?

Cas particuliers

Le critère est non applicable pour les fonctionnalités intégrées à la plateforme.

Méthodologie d’évaluation
iOS et Android
  1. Repérer dans l’application les fonctionnalités d’accessibilité décrites dans la documentation. Par exemple :
    • une fonctionnalité qui permet d’accéder à une version en langage simplifié de l’application ;
    • une fonctionnalité qui permet de verrouiller l’orientation d’un écran.
  2. Vérifier qu’il est possible pour les utilisateurs qui ont besoin :
    • de percevoir la présence de cette fonctionnalité dans l’interface ;
    • d’activer cette fonctionnalité, par exemple, une fonctionnalité est disponible qui permet d’accéder à une version en langage simplifié de l’application, alors tous les composants qui composent le parcours permettant d’atteindre la fonctionnalité doivent être en langage simplifié.
  3. Si c’est le cas, le critère est validé.
Correspondances
  • WCAG 2.1 : N/A
  • EN 301 549 V3.2.1 (2021-03) : 5.2 Activation of accessibility features.

Critère 12.3 [A] L’application ne perturbe pas les fonctionnalités d’accessibilité de la plateforme. Cette règle est-elle respectée ?

Méthodologie d’évaluation
iOS
  1. Identifier dans la documentation de la plateforme les fonctionnalités d’accessibilité mises à disposition des utilisateurs (voir la documentation concernant les fonctionnalités d’accessibilité fournie par iOS).
  2. Vérifier que l’application n’empêche pas leur utilisation, par exemple :
    • si l’application implémente des interactions qui déclenchent des fonctionnalités, ces interactions n’empêchent pas le bon fonctionnement des fonctionnalités d’accessibilité de la plateforme comme le lecteur d’écran ou les autres fonctionnalités basées sur le toucher ;
    • si l’application embarque une reconnaissance vocale, alors l’utilisation de la commande vocale intégrée à la plateforme n’est pas perturbée ;
    • si l’application implémente des raccourcis clavier, ceux-ci n’utilisent pas des combinaisons de touches déjà employées par la plateforme pour des fonctionnalités d’accessibilité (VoiceOver peut être utilisé avec un clavier par exemple, les raccourcis proposés ne doivent pas interférer) ;
    • ou toute autre fonctionnalité de l’application.
  3. Si c’est le cas, le critère est validé.
Android
  1. Identifier dans la documentation de la plateforme les fonctionnalités d’accessibilité mises à disposition des utilisateurs (voir la documentation concernant les fonctionnalités d’accessibilité fournie par Android).
  2. Vérifier que l’application n’empêche pas leur utilisation, par exemple :
    • si l’application implémente des interactions qui déclenchent des fonctionnalités, ces interactions n’empêchent pas le bon fonctionnement des fonctionnalités d’accessibilité de la plateforme comme le lecteur d’écran ou les autres fonctionnalités basées sur le toucher ;
    • si l’application embarque une reconnaissance vocale, alors l’utilisation de la commande vocale intégrée à la plateforme n’est pas perturbée ;
    • si l’application implémente des raccourcis clavier, ceux-ci n’utilisent pas des combinaisons de touches déjà employées par la plateforme pour des fonctionnalités d’accessibilité (TalkBack peut être utilisé avec un clavier par exemple, les raccourcis proposés ne doivent pas interférer) ;
    • ou toute autre fonctionnalité de l’application.
  3. Si c’est le cas, le critère est validé.
Correspondances
  • WCAG 2.1 : N/A
  • EN 301 549 V3.2.1 (2021-03) : 11.6.2 No disruption of accessibility features.

Critère 12.4 [A] La documentation de l’application est-elle accessible ?

Méthodologie d’évaluation
iOS et Android
  1. Repérer dans l’application la présence d’une documentation, par exemple :
    • un écran d’aide ;
    • une déclaration d’accessibilité ;
    • tout autre contenu qui fait office de documentation (cela peut être un document pdf, une page HTML externe lisible dans un navigateur web).
  2. Si c’est le cas, vérifier pour chaque élément de documentation :
  3. Si c’est le cas, le critère est validé.
Correspondances

Thématique 13 : Outils d’édition

Critère 13.1 [A] L’outil d’édition permet-il de définir les informations d’accessibilité nécessaires pour créer un contenu conforme ?

Méthodologie d’évaluation
iOS et Android
  1. Repérer dans l’outil les fonctionnalités d’édition (par exemple, un éditeur de texte, mais cela peut être une médiathèque ou toute autre interface qui permet de saisir du texte ou définir des propriétés).
  2. Vérifier qu’il est possible de définir les informations d’accessibilité nécessaires pour rendre le contenu conforme au RAWeb. Par exemple :
    • définir l’alternative textuelle d’une image depuis l’éditeur de texte ou une médiathèque ;
    • définir un intitulé de lien ;
    • etc.
  3. Si c’est le cas, le critère est validé.
Correspondances

Critère 13.2 [A] L’outil d’édition met-il à disposition des aides à la création de contenus accessibles ?

Méthodologie d’évaluation
iOS et Android
  1. Repérer dans l’outil la présence d’aides à la création de contenus accessibles. Cela peut être :
    • une documentation utilisateur qui explique comment définir les propriétés d’accessibilité pour chaque élément de contenu ;
    • des tests automatiques ou semi-automatiques disponibles depuis les fonctionnalités d’édition ;
    • des tests manuels disponibles depuis les fonctionnalités d’édition pour guider les auteurs dans la détection d’erreurs.
  2. Vérifier que les aides à la création de contenus accessibles sont pertinentes, c’est-à-dire qu’elles permettent de créer un contenu accessible.
  3. Si c’est le cas, le critère est validé.
Correspondances

Critère 13.3 [A] Le contenu généré par chaque transformation des contenus est-il accessible (hors cas particuliers) ?

Cas particuliers

Le critère est non applicable lorsque le format de destination ne permet pas de conserver les informations d’accessibilité présentes dans le contenu en entrée.

Méthodologie d’évaluation
iOS et Android
  1. Depuis les fonctionnalités d’édition (un éditeur de texte, mais cela peut être une médiathèque et toute autre interface qui permet de saisir du texte ou définir des propriétés), saisir les typologies de contenus proposées par l’éditeur (titre, liste, tableau, image, etc.). Utiliser également les différents paramètres permettant de définir des informations d’accessibilité (renseigner l’alternative textuelle d’une image, ajouter une description sur un lien, etc.)
  2. Enregistrer les saisies.
  3. Consulter le contenu généré :
    • dans la fonctionnalité d’édition (par exemple, dans l’éditeur de texte) ;
    • dans l’interface de publication des contenus (par exemple, la page web de publication).
  4. Vérifier :
    • que les informations d’accessibilité (par exemple l’alternative d’une image, les niveaux de titres) sont préservées dans le contenu généré ;
    • que la technologie prend en charge les informations d’accessibilité pour la forme restructurée de l’information (vérifier que la transformation des informations est compatible avec la technologie, notamment pour s’assurer que ces informations pourront être exploitées par les technologies d’assistance).
  5. Si c’est le cas, le critère est validé.
Correspondances

Critère 13.4 [AA] Pour chaque erreur d’accessibilité relevée par un test d’accessibilité automatique ou semi-automatique, l’outil d’édition fournit-il des suggestions de réparation ?

Méthodologie d’évaluation
iOS et Android
  1. Repérer dans l’outil la présence de fonctionnalités de tests automatiques ou semi-automatiques.
  2. Modifier les valeurs ou contenus dans les zones d’édition afin de créer des erreurs d’accessibilité dans le contenu généré (web et non web).
  3. Activer les fonctionnalités de tests.
  4. Vérifier :
    • que l’outil répare automatiquement l’erreur ;
    • ou que l’outil met à disposition de l’auteur des suggestions de réparations.
  5. Dans le cas d’un test semi-automatique, vérifier :
    • l’outil met à disposition une aide à la décision et des suggestions de réparations ;
    • ou que l’outil met à disposition de l’auteur des explications lui permettant d’effectuer la réparation.
  6. Si c’est le cas, le critère est validé.
Correspondances

Critère 13.5 [A] Pour chaque ensemble de gabarits, un gabarit au moins permet de répondre aux exigences du RAWeb. Cette règle est-elle respectée ?

Méthodologie d’évaluation
iOS et Android
  1. Repérer la présence de gabarits mis à disposition par l’outil d’édition.
  2. Tester le respect des critères du RAWeb et vérifier qu’au moins un des gabarits est totalement conforme.
  3. Si c’est le cas, le critère est validé.
Correspondances
  • WCAG 2.1 : N/A
  • EN 301 549 V3.2.1 (2021-03) : 11.8.1 Content technology,11.8.5 Templates.

Critère 13.6 [A] Chaque gabarit qui permet de répondre aux exigences du RAWeb est-il clairement identifiable ?

Méthodologie d’évaluation
iOS et Android
  1. Repérer la présence de gabarits totalement conformes au RAWeb mis à disposition par l’outil d’édition.
  2. Vérifier la présence d’une mention explicite permettant de les identifier. Par exemple, depuis la liste des gabarits, les gabarits conformes possèdent une étiquette « gabarit accessible ».
  3. Si c’est le cas, le critère est validé.
Correspondances
  • WCAG 2.1 : N/A
  • EN 301 549 V3.2.1 (2021-03) : 11.8.1 Content technology,11.8.5 Templates.

Thématique 14 : Services d’assistance

Critère 14.1 [AA] Chaque service d’assistance fournit-il des informations relatives aux fonctionnalités d’accessibilité de l’application décrites dans la documentation ?

Méthodologie d’évaluation
iOS et Android
  1. Repérer la mise à disposition d’un service d’assistance depuis l’application.
  2. Si c’est le cas, repérer dans l’application la présence d’une documentation, par exemple :
  3. Repérer la présence dans la documentation :
    • de la description des fonctionnalités d’accessibilité de l’application, par exemple :
      • des paramètres d’accessibilité intégrés dans l’application comme la gestion des couleurs, des tailles de polices, la gestion des animations ;
      • un rotor personnalisé sur certains écrans (le rotor est une fonctionnalité des lecteurs d’écran qui permet une navigation rapide entre des types d’éléments d’un écran, certaines plateformes permettent de définir des éléments de navigation rapide spécifique à une application dans ce rotor. Voir une démonstration) ;
      • des gestes ou mouvements d’appareil qui déclenchent des fonctionnalités ;
      • des raccourcis clavier spéciaux disponibles pour certaines technologies d’assistance.
    • de la description des composants complexes pour lesquels il est mis en place une gestion particulière selon les technologies d’assistance ;
    • d’explications sur les modalités d’utilisation de ces fonctionnalités (leur localisation, les méthodes pour les activer) ;
    • de la description des éléments non conformes ou non compatibles avec certaines technologies d’assistance, et de la présence d’alternatives le cas échéant.
  4. Vérifier que le service support propose des informations concernant ces fonctionnalités.
  5. Si c’est le cas, le critère est validé.
Correspondances
  • WCAG 2.1 : N/A
  • EN 301 549 V3.2.1 (2021-03) : 12.2.2 Information on accessibility and compatibility features.

Critère 14.2 [A] Le service d’assistance répond aux besoins de communication des personnes handicapées directement ou par l’intermédiaire d’un service de relais. Cette règle est-elle respectée ?

Méthodologie d’évaluation
iOS et Android
  1. Repérer la présence dans l’application d’un service d’assistance.
  2. Si c’est le cas, vérifier que le service d’assistance peut être utilisé par toutes les personnes en situation de handicap. Il peut être utile de rechercher dans la documentation de l’application pour trouver ces informations. Par exemple, si le service d’assistance est disponible depuis un numéro de téléphone, vérifier qu’il existe des moyens alternatifs pour les utilisateurs qui ne peuvent pas s’exprimer à l’oral (personnes sourdes ou malentendantes) ou qui ne peuvent pas utiliser le langage verbal (personnes aphasiques). Par exemple :
    • une messagerie instantanée qui fournit un service équivalent (dialogue en temps réel avec un opérateur humain) ;
    • la mise à disposition d’une traduction écrite simultanée ou visuelle des informations orales ou sonores, ou la mise à disposition d’un interprète en langue des signes (utilisation d’un service de relais).
  3. Si c’est le cas, le critère est validé.
Correspondances
  • WCAG 2.1 : N/A
  • EN 301 549 V3.2.1 (2021-03) : 12.2.3 Effective communication.

Thématique 15 : Communication en temps réel

Critère 15.1 [A] Pour chaque application de communication orale bidirectionnelle, l’application est-elle capable d’encoder et de décoder cette communication avec une gamme de fréquences dont la limite supérieure est de 7 000 Hz au moins ?

Méthodologie d’évaluation
iOS et Android

La façon la plus sûre d’évaluer ce critère est de faire une recherche soit dans l’interface soit dans la documentation de l’application pour obtenir cette information. Il est également recommandé de demander à l’éditeur de l’application de fournir cette information.

Une implémentation de la recommandation UIT-T G.722 par exemple semble être une solution optimale.

Correspondances
  • WCAG 2.1 : N/A
  • EN 301 549 V3.2.1 (2021-03) : 6.1 Audio bandwidth for speech.

Critère 15.2 [A] Chaque application qui permet une communication orale bidirectionnelle dispose-t-elle d’une fonctionnalité de communication écrite en temps réel ?

Test 15.2.1 : Chaque application qui permet une communication orale bidirectionnelle respecte-t-elle une de ces conditions ?

  • L’application dispose d’une fonctionnalité intégrée de communication écrite en temps réel ;
  • L’application peut être connectée à un terminal qui intègre une fonctionnalité de communication écrite en temps réel.
Méthodologie d’évaluation
iOS et Android
  1. Vérifier que l’application permet la communication orale bidirectionnelle.
  2. Si c’est le cas, vérifier la présence d’une fonctionnalité de communication écrite en temps réel (il peut être parfois nécessaire d’activer un paramètre dédié dans l’application pour permettre la communication écrite en temps réel).
  3. Sinon, vérifier si l’application peut se connecter à un terminal intégrant une fonctionnalité de communication écrite en temps réel (cette évaluation peut être complexe à mener sans la mise à disposition d’un terminal de communication en temps réel ou si le réseau utilisé par le terminal ne supporte pas les protocoles de texte en temps réel. Une première étape peut être de rechercher dans la documentation ou de questionner directement l’éditeur de l’application.)
  4. Si c’est le cas, le critère est validé.
Correspondances
  • WCAG 2.1 : N/A
  • EN 301 549 V3.2.1 (2021-03) : 6.2.1.1 RTT communication.

Critère 15.3 [A] Pour chaque application qui permet une communication orale bidirectionnelle et écrite en temps réel, les deux modes sont-ils utilisables simultanément ?

Méthodologie d’évaluation
iOS et Android
  1. Vérifier que l’application permet la communication orale bidirectionnelle.
  2. Si c’est le cas, vérifier la présence d’une fonctionnalité de communication écrite en temps réel.
  3. Si c’est le cas, vérifier qu’il est possible d’utiliser les deux modes de communications en même temps, c’est-à-dire que des utilisateurs peuvent envoyer des messages écrits en temps réels au même moment que d’autres utilisateurs parlent par exemple.
  4. Si c’est le cas, le critère est validé.
Correspondances
  • WCAG 2.1 : N/A
  • EN 301 549 V3.2.1 (2021-03) : 6.2.1.2 Concurrent voice and text.

Critère 15.4 [A] Pour chaque fonctionnalité de communication écrite en temps réel, les messages peuvent-ils être identifiés (hors cas particuliers) ?

Test 15.4.1 : Pour chaque fonctionnalité de communication écrite en temps réel, les messages respectent-ils ces conditions ?

  • Les messages reçus et envoyés sont séparés dans la présentation ;
  • La présentation permet d’identifier la nature du message (reçu ou envoyé) ;
  • La présentation permet d’identifier les auteurs des messages ;
  • La nature du message (reçu ou envoyé) est accessible aux technologies d’assistance ;
  • L’identification de l’auteur du message est accessible aux technologies d’assistance.
Cas particuliers

Le critère est non applicable lorsque la fonctionnalité de communication orale bidirectionnelle ne permet pas d’identifier les participants, il n’est alors pas requis que la fonctionnalité de communication écrite en temps réel identifie les auteurs des messages.

Méthodologie d’évaluation
iOS et Android
  1. Activer l’application et la fonctionnalité de communication écrite en temps réel de l’application sur deux terminaux et les connecter à une même session.
  2. Envoyer un message écrit depuis les deux terminaux pour obtenir des messages avec des statuts différents (envoyé et reçus).
  3. Vérifier :
    • que les messages envoyés et reçus sont visuellement séparés (par exemple, les messages envoyés sont dans une fenêtre et les messages reçus dans une autre, ou il y a un saut de ligne entre chaque message reçu et envoyé s’ils sont présentés dans une même fenêtre) ;
    • qu’il est possible visuellement de distinguer les messages envoyés et les messages reçus (par exemple, repérer la mention « Envoyé » à proximité d’un message envoyé ou « Reçu » à proximité d’un message reçu) ;
    • si l’identification de l’interlocuteur est disponible pour le mode de communication oral (par exemple, mise en avant de l’avatar de la personne ayant la parole), que les auteurs des messages écrits sont identifiés également (par exemple, la présence d’un nom ou un identifiant précédant le message).
  4. Activer le lecteur d’écran et naviguer dans les messages.
  5. Vérifier que le lecteur d’écran restitue :
    • l’information du statut envoyé ou reçu de chaque message ;
    • l’identification de l’auteur du message.
  6. Si c’est le cas, le critère est validé.
Correspondances

Critère 15.5 [A] Pour chaque application de communication orale bidirectionnelle, un indicateur visuel de l’activité orale est-il présent ?

  • Test 15.5.1 : Pour chaque application de communication orale et écrite en temps réel, un indicateur visuel de l’activité orale est-il présent ?
  • Test 15.5.2 : Pour chaque application de communication orale bidirectionnelle qui dispose d’une vidéo en temps réel, un indicateur visuel de l’activité orale est-il présent ?
Méthodologie d’évaluation
iOS et Android
  1. Vérifier que l’application permet la communication orale bidirectionnelle et la communication écrite en temps réel ou la diffusion de la vidéo en temps réel.
  2. Si c’est le cas, activer l’application sur deux terminaux et les connecter à une même session.
  3. Faire parler un utilisateur depuis un des terminaux.
  4. Vérifier sur l’interface l’apparition d’un indicateur visuel permettant d’identifier qu’une personne est en train de parler. Il n’est pas nécessaire pour ce critère d’identifier qui parle, mais simplement d’identifier qu’il y a une personne qui est en train de parler. Par exemple, un halo autour ou une icône à proximité de l’avatar de la personne qui parle.
  5. Si c’est le cas, le critère est validé.
Correspondances

Critère 15.6 [A] Chaque application de communication écrite en temps réel qui peut interagir avec d’autres applications de communication écrite en temps réel respecte-t-elle les règles d’interopérabilité en vigueur ?

Méthodologie d’évaluation
iOS et Android

Il n’est pas proposé de méthode d’évaluation pour ce critère.

Note importante : Ce critère est très complexe à évaluer et demande une certaine maîtrise de l’ensemble des concepts et normes d’interopérabilité. Si l’application que vous évaluez ou développez doit couvrir ce critère, nous vous renvoyons à la lecture intégrale du critère 6.2.3 Interoperability dans la norme EN 301 549.

Correspondances
  • WCAG 2.1 : N/A
  • EN 301 549 V3.2.1 (2021-03) : 6.2.3 Interoperability.

Critère 15.7 [AA] Pour chaque application qui permet une communication écrite en temps réel, le délai de transmission de chaque unité de saisie est de 500ms ou moins. Cette règle est-elle respectée ?

Méthodologie d’évaluation
iOS et Android
  1. Vérifier que l’application permet la communication écrite en temps réel.
  2. Si c’est le cas, activer l’application et la fonctionnalité de communication écrite sur deux terminaux distincts et les connecter à une même session.
  3. Saisir du texte sur le premier terminal et observer son apparition sur le second terminal. L’apparition sur le second terminal doit être instantanée (inférieure à une demi-seconde). Selon le fonctionnement de la fonctionnalité, chaque caractère n’est pas envoyé individuellement. En effet, si la fonctionnalité de communication écrite en temps réel implémente une prédiction de mots, c’est lorsque le mot désiré sera sélectionné qu’il sera envoyé, pas lors de la saisie des premiers caractères servant à déclencher l’affichage de suggestion. Un test par observation simple peut être suffisant pour constater l’apparition instantanée sur le terminal qui reçoit le message écrit.
  4. Si c’est le cas, le critère est validé.
Correspondances
  • WCAG 2.1 : N/A
  • EN 301 549 V3.2.1 (2021-03) : 6.2.4 RTT responsiveness.

Critère 15.8 [A] Pour chaque application de télécommunication, l’identification de l’interlocuteur qui initie un appel est-elle accessible ?

Test 15.8.1 : Pour chaque application de télécommunication qui fournit l’identification de l’interlocuteur, l’identification respecte-t-elle ces conditions ?

  • L’identification de l’interlocuteur est présentée sous forme de texte ;
  • L’identification de l’interlocuteur est accessible aux technologies d’assistance.
Méthodologie d’évaluation
iOS et Android
  1. Activer le lecteur d’écran depuis un terminal.
  2. Depuis un second terminal, lancer un appel vers le premier terminal.
  3. Lorsque l’appel entrant apparaît, vérifier :
    • que l’identification de l’interlocuteur est disponible sous format texte visible (par exemple, un nom ou un numéro de téléphone) ;
    • et que cette identification est correctement restituée par le lecteur d’écran.
  4. Si c’est le cas, le critère est validé.
Correspondances
  • WCAG 2.1 : N/A
  • EN 301 549 V3.2.1 (2021-03) : 6.3 Caller ID.

Critère 15.9 [A] Pour chaque application de communication orale bidirectionnelle qui fournit l’identification de l’interlocuteur, existe-t-il un moyen de présenter cette identification pour les utilisateurs de langue des signes ?

Méthodologie d’évaluation
iOS et Android
  1. Activer l’application et lancer un appel vidéo entre les deux terminaux.
  2. Vérifier la présence sur le terminal recevant l’appel d’une méthode permettant aux utilisateurs de langue des signes d’identifier l’interlocuteur.
  3. Si c’est le cas, le critère est validé.
Correspondances
  • WCAG 2.1 : N/A
  • EN 301 549 V3.2.1 (2021-03) : 6.5.6 Speaker identification with video (sign language) communication.

Critère 15.10 [A] Pour chaque application de communication orale bidirectionnelle qui dispose de fonctionnalités vocales, celles-ci sont-elles utilisables sans la nécessité d’écouter ou parler ?

Méthodologie d’évaluation
iOS et Android
  1. Repérer les fonctionnalités disponibles (en dehors de la fonctionnalité de communication orale) qui se basent sur l’écoute d’information ou l’énonciation de commande, par exemple :
    • une messagerie vocale ;
    • un standard téléphonique automatique (par exemple, qui demande d’énoncer un chiffre entre 1 et 4 pour être redirigé vers un service) ;
    • ou tout autre serveur vocal interactif.
  2. Vérifier :
    • que l’information est disponible sans devoir écouter ou parler ;
    • que les actions peuvent être réalisées sans devoir écouter ou parler ou qu’il existe une alternative à la fonctionnalité qui peut être utilisée sans devoir écouter ou parler.
  3. Si c’est le cas, le critère est validé.
Correspondances
  • WCAG 2.1 : N/A
  • EN 301 549 V3.2.1 (2021-03) : 6.4 Alternatives to voice-based services.

Critère 15.11 [AA] Pour chaque application de communication orale bidirectionnelle qui dispose d’une vidéo en temps réel, la qualité de la vidéo est-elle suffisante ?

Test 15.11.1 : Pour chaque application de communication orale bidirectionnelle qui dispose d’une vidéo en temps réel, les conditions suivantes sont-elles respectées ?

  • La résolution de la vidéo répond à la norme QVGA au moins ;
  • La fréquence des images est de 20 images par seconde au moins ;
  • Le décalage entre la vidéo et les paroles ne doit pas être supérieur à 100 ms.
Méthodologie d’évaluation
iOS et Android

Pour les conditions concernant la résolution et la fréquence des images, la façon la plus sûre d’évaluer ce critère est de faire une recherche soit dans l’interface soit dans la documentation de l’application pour obtenir ces informations. Il est également recommandé de demander à l’éditeur de l’application de fournir ces détails techniques.

Pour la dernière condition concernant le décalage entre la vidéo et l’audio, le test peut s’établir sur une simple observation :

  1. Activer l’application sur deux terminaux.
  2. Établir une connexion d’appel vidéo entre les deux terminaux.
  3. Vérifier la synchronisation entre les paroles et la vidéo (synchronisation labiale, mouvement des lèvres).
  4. Si c’est le cas, le critère est validé.
Correspondances