7. Navigation avec un lecteur d'écran

7.1 Les éléments porteurs d'information sont vocalisés de façon pertinente.

7.1.1

La vocalisation de chaque élément porteur d'information (hors composant d'interface) permet-elle de comprendre l'information véhiculée ?


Méthodologie du test 7.1.1

iOS et Android

  1. Activer le lecteur d'écran
  2. Parcourir l'écran et vérifier que :
    • chaque contenu graphique porteur d'information (hors composant d'interface) est vocalisé de façon pertinente ;
    • chaque contenu textuel porteur d'information (hors composant d'interface) est vocalisé de façon pertinente.
  3. Si c'est le cas, le critère est validé.


Références

WCAG 2.1

Critère(s) de succès :


RGAA 4.1.2

Critère(s) de référence :

7.2 Les éléments décoratifs sont correctement ignorés.

7.2.1

Chaque élément à but décoratif est-il correctement ignoré par le lecteur d'écran ?

Méthodologie du test 7.2.1

iOS et Android
  1. Activer le lecteur d'écran
  2. Parcourir l'écran et repérer les éléments décoratifs
  3. Vérifier :
    • qu'ils ne peuvent pas être atteints avec le lecteur d'écran
    • que leur contenu n'est pas restitué
  4. Si c'est le cas, le critère est validé.


Références

WCAG 2.1

Critère(s) de succès :


RGAA 4.1.2

Critère(s) de référence :

7.3 Les contenus cachés ont vocation à être ignorés.

7.3.1


Chaque contenu caché a-t-il vocation à être ignoré par le lecteur d'écran ?


Méthodologie du test 7.3.1

iOS et Android
  1. Activer le lecteur d'écran
  2. Parcourir l'écran
  3. Vérifier que chaque contenu caché a vocation à être ignoré par le lecteur d'écran
  4. Vérifier qu'aucun élément fantôme n'est restitué par le lecteur d'écran
  5. Si c'est le cas, le critère est validé.


Références

WCAG 2.1

Critère(s) de succès :

RGAA 4.1.2

Critère(s) de référence :

7.4 L'ordre de vocalisation des éléments est cohérent.

7.4.1


L'ordre de vocalisation des éléments de l'écran est-il logique et compréhensible ?


Méthodologie du test 7.4.1

iOS et Android
  1. Activer le lecteur d'écran
  2. Parcourir l'écran
  3. Vérifier que l'ordre de vocalisation des éléments suit un ordre logique et permet de comprendre les informations véhiculées.
  4. Si c'est le cas, le critère est validé.


Références

WCAG 2.1

Critère(s) de succès :


RGAA 4.1.2

Critère(s) de référence :

7.5 Chaque champ de saisie est vocalisé avec son étiquette au moment où le champ reçoit le focus.

7.5.1

Chaque champ de saisie recevant le focus est-il vocalisé en même temps que son étiquette associée ?


Méthodologie du test 7.5.1

iOS et Android
  1. Activer le lecteur d'écran
  2. Parcourir l'écran
  3. Vérifier que chaque étiquette est vocalisée en même temps que son champ associé.
  4. Si c'est le cas, le critère est validé.


Références

WCAG 2.1

Critère(s) de succès :


RGAA 4.1.2

Critère(s) de référence :

7.6 Les éléments liés entre eux sont groupés, de façon pertinente, au sein d'un même bloc d'annonce pour la vocalisation.

7.6.1


Tous les éléments d'un même groupe d'informations sont-ils vocalisés en une fois à la prise de focus du groupe ?


Méthodologie du test 7.6.1

iOS et Android
  1. Activer le lecteur d'écran
  2. Parcourir l'écran
  3. Vérifier que les éléments reliés sont groupés au sein d'un même bloc d'annonce pour la vocalisation. Par exemple :
    • Pour un article : son titre, sa catégorie et son résumé sont vocalisés en une seule fois.
    • Pour un produit : son nom, sa référence et son prix sont vocalisés en une seule fois.
  4. Si c'est le cas, le critère est validé.


Références

WCAG 2.1

Critère(s) de succès :


RGAA 4.1.2

Critère(s) de référence :

7.7 L'information est structurée par l'utilisation appropriée de titres de section.

7.7.1

Chaque écran possède-t-il au moins un titre ?

Méthodologie du test 7.7.1

iOS
  1. Activer le lecteur d'écran.
  2. Utiliser le rotor et sélectionner « En-têtes ».
  3. Parcourir l'écran en glissant un doigt vers le haut ou vers le bas.
  4. Vérifier l'existence d'au moins un titre
  5. 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 l'écran en glissant un doigt vers le haut ou vers le bas.
  4. Vérifier l'existence d'au moins un titre
  5. Si c'est le cas, le critère est validé.


7.7.2

Chaque passage de texte constituant un titre en possède-t-il la sémantique ?


Méthodologie du test 7.7.2

iOS
  1. Activer le lecteur d'écran.
  2. Utiliser le rotor et sélectionner « En-têtes ».
  3. Parcourir les en-têtes 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 entête ;
    • que chaque entête atteint est pertinent, c'est-à-dire :
    • que l'entête est utile à la structuration de l'écran ;
    • que le texte contenu dans l'entête permet de comprendre le contenu de la section titrée.
  5. 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é.


Références

WCAG 2.1

Critère(s) de succès :


RGAA 4.1.2

Critère(s) de référence :

7.8 Chaque composant d'interface est, si nécessaire, compatible avec le lecteur d'écran.

7.8.1

Chaque composant d'interface vérifie-t-il, si nécessaire, une de ces conditions ?



Méthodologie du test 7.8.1

iOS et Android
  1. Activer le lecteur d'écran
  2. Repérer dans l'écran les composants interactifs (par exemple, bouton, lien, champs de formulaire, onglets, accordéons).
  3. Vérifier que pour chaque composant, une de ces conditions est vérifiée :
  4. Si c'est le cas, le test est validé.



7.8.2

Chaque composant d'interface vérifie-t-il ces conditions (hors cas particuliers) ?

  • Le composant possède un nom pertinent ;
  • Le nom accessible du composant contient au moins l'intitulé visible ;
  • Le composant possède un rôle pertinent ;
  • Le composant possède une valeur pertinente ;
  • Le composant possède un état pertinent.


Méthodologie du test 7.8.2

iOS et Android
  1. Activer le lecteur d'écran.
  2. Repérer dans l'écran les composants interactifs (par exemple, bouton, lien, champs de formulaire, onglets, accordéons).
  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 test est validé.


Cas particuliers du test 7.8.2

  • 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 »).

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.


Références

WCAG 2.1

Critère(s) de succès :


RGAA 4.1.2

Critère(s) de référence :

7.9 L'utilisateur est averti ou a le contrôle des changements de contexte.

7.9.1

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

  • L'utilisateur est averti par un message 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 du test 7.9.1

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'un nouvel écran 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 ;
    • le déplacement 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é.


Références

WCAG 2.1

Critère(s) de succès :

RGAA 4.1.2

Critère(s) de référence :

7.10 Les messages de statut sont correctement restitués.

7.10.1


Chaque message de statut qui :

  • informe de la réussite, du résultat d'une action ou de l'état d'une application
  • présente ou avertit de l'existence d'une erreur
  • indique la progression d'un processus

est-il bien vocalisé par le lecteur d'écran ?

Méthodologie du test 7.10.1

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é.


Références

WCAG 2.1

Critère(s) de succès :


RGAA 4.1.2

Critère(s) de référence :

7.11 L'application est clairement identifiable depuis l'écran de lancement.

7.11.1

Dans le lanceur d'application du terminal, l'application est-elle clairement identifiable ?


Méthodologie du test 7.11.1

iOS et Android
  1. Ouvrir le lanceur d'application du terminal
  2. Activer le lecteur d'écran
  3. Vérifier que l'intitulé donné à l'exécutable de l'application permet de clairement l'identifier
  4. Vérifier que cet intitulé est correctement vocalisé
  5. Si c'est le cas, le test est validé.

7.11.2

Dans le lanceur d'application du terminal, chaque raccourci de l'application possède-t-il un intitulé pertinent ?


Méthodologie du test 7.11.2

iOS et Android
  1. Ouvrir le lanceur d'application du terminal
  2. Activer le lecteur d'écran
  3. Positionner le focus sur l'exécutable de l'application
  4. Appuyer deux fois et maintenir enfoncé
  5. Vérifier que l'intitulé donné à chaque raccourci de l'application est pertinent et correctement vocalisé.
  6. Si c'est le cas, le test est validé.

Références

WCAG 2.1

Critère(s) de succès :

9.8 Les actions déclenchées au moyen d'un dispositif de pointage sur un point unique de l'écran peuvent faire l'objet d'une annulation (hors cas particuliers).

7.8.1

Chaque composant d'interface vérifie-t-il, si nécessaire, une de ces conditions ?



Méthodologie du test 7.8.1

iOS et Android
  1. Activer le lecteur d'écran
  2. Repérer dans l'écran les composants interactifs (par exemple, bouton, lien, champs de formulaire, onglets, accordéons).
  3. Vérifier que pour chaque composant, une de ces conditions est vérifiée :
  4. Si c'est le cas, le test est validé.



7.8.2

Chaque composant d'interface vérifie-t-il ces conditions (hors cas particuliers) ?

  • Le composant possède un nom pertinent ;
  • Le nom accessible du composant contient au moins l'intitulé visible ;
  • Le composant possède un rôle pertinent ;
  • Le composant possède une valeur pertinente ;
  • Le composant possède un état pertinent.


Méthodologie du test 7.8.2

iOS et Android
  1. Activer le lecteur d'écran.
  2. Repérer dans l'écran les composants interactifs (par exemple, bouton, lien, champs de formulaire, onglets, accordéons).
  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 test est validé.


Cas particuliers du test 7.8.2

  • 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 »).

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.


Références

WCAG 2.1

Critère(s) de succès :


RGAA 4.1.2

Critère(s) de référence :

9.9 Les fonctionnalités qui impliquent un mouvement de l'appareil ou vers l'appareil peuvent être satisfaites de manière alternative (hors cas particuliers).

7.9.1

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

  • L'utilisateur est averti par un message 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 du test 7.9.1

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'un nouvel écran 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 ;
    • le déplacement 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é.


Références

WCAG 2.1

Critère(s) de succès :

RGAA 4.1.2

Critère(s) de référence :