Référentiel d'accessibilité des applications mobiles RAAM 2.0
Notes de révision
Cette édition est une refonte complète de la version 1.0 d'octobre 2021 du Référentiel d'accessibilité des applications mobiles (RAAM) établie par Urbilog Compéthance.
Le RAAM 2.0 suit maintenant le modèle par thématiques utilisé dans le Référentiel général d'amélioration de l'accessibilité (RGAA) de l'état français.
Le référentiel fait aussi référence aux critères de succès des niveaux A et AA de la norme internationale Web content accessibility guidelines (WCAG) 2.1.
À propos des vues web
Les vues web 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.
À propos des zones cibles tactiles et des pointeurs
Les cibles tactiles sont les parties de l’écran qui répondent aux entrées de l’utilisateur, s’étendant au-delà des limites visuelles d’un élément. Par exemple, une icône peut sembler être de 24 x 24 dp, mais le remplissage qui l’entoure comprend la cible tactile complète de 44 x 44 dp.
Pour la plupart des plates-formes, envisagez de créer des cibles tactiles d’au moins 44 x 44 dp. La taille cible recommandée pour les éléments d’écran tactile est de 7 à 10 mm. Il peut être approprié d’utiliser des cibles tactiles plus grandes pour accueillir un plus large éventail d’utilisateurs.
1. Couleurs
1.1 Dans chaque écran, l'information ne doit pas être transmise uniquement par la couleur.
Tests et références du critère 1.1
1.1.1
Pour chaque élément de l'interface dont la mise en couleur est porteuse d'information, l'information ne doit pas être donnée uniquement par la couleur. Cette règle est-elle respectée ?
Méthodologie du test 1.1.1
iOS et Android
- 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.
- 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.
- Avec le lecteur d'écran, accéder à l'information donnée par la couleur.
- Vérifier qu'une information équivalente est restituée par le lecteur d'écran (par exemple, l'état « sélectionné » d'un bouton vert).
- Si c'est le cas, le critère est validé.
1.1.2
Pour chaque indication de couleur donnée par un texte (écrit ou vocalisé), l'information ne doit pas être donnée uniquement par la couleur. Cette règle est-elle respectée ?
Méthodologie du test 1.1.2
iOS et Android
- Repérer chaque indication de couleur donnée par un texte (écrit ou vocalisé) porteuse d'information.
- Vérifier qu'il existe un autre moyen d'accéder à l'information
- 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 :
1.2 Dans chaque écran, le contraste entre la couleur du texte et la couleur de son arrière-plan est suffisamment élevé (hors cas particuliers).
Test et références du critère 1.2
1.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 ?
- Le rapport de contraste entre le texte et son arrière-plan est d'au moins 4.5:1 pour le texte en taille normale et d'au moins 3:1 pour le texte de grande taille;
- Un mécanisme de remplacement permet à l'utilisateur d'afficher le texte en taille normale avec un rapport de contraste de 4.5:1 au moins et le texte de grande taille avec un rapport de contraste de 3:1 au moins.
Méthodologie du test
iOS
- S'il existe dans l'application, activer le mécanisme de remplacement permettant d'afficher l'application avec un rapport de contraste suffisant.
- 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.
-
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 :
- En diffusant l'écran du terminal mobile sur l'ordinateur ;
- En réalisant des captures d'écran des éléments à évaluer (et en les important sur l'ordinateur).
-
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.
- Si c'est le cas, le critère est validé.
Note
Il est possible d'utiliser l'application Xcode 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
- S'il existe dans l'application, activer le mécanisme de remplacement permettant d'afficher l'application avec un rapport de contraste suffisant.
- 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.
-
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 :
- En diffusant l'écran du terminal mobile sur l'ordinateur ;
- En réalisant des captures d'écran des éléments à évaluer (et en les important sur l'ordinateur).
-
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.
- 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.
Cas particuliers
Dans ces situations, le critère est non applicable pour ces éléments.
- Le texte fait partie d'un logo ou d'un nom de marque d'un organisme ou d'une société ;
- Le texte ou l'image de texte est purement décoratif ;
- Le texte fait partie d'une image véhiculant une information, mais le texte lui-même n'apporte aucune information essentielle ;
- Le texte ou l'image de texte fait partie d'un élément d'interface sur lequel aucune action n'est possible (par exemple, un bouton ayant un état désactivé).
Références
WCAG 2.1
Critère(s) de succès :
RGAA 4.1.2
Critère(s) de référence :
1.3 Dans chaque écran, les couleurs utilisées dans les composants d'interface ou les éléments graphiques porteurs d'informations sont suffisamment contrastées (hors cas particuliers).
Tests et références du critère 1.3
1.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.
Méthodologie du test 1.3.1
iOS et Android
- 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.
-
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.
- 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.
-
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 :
- En diffusant l'écran du terminal mobile sur l'ordinateur ;
- En réalisant des captures d'écran des éléments à évaluer (et en les important sur l'ordinateur).
- Vérifier que le rapport de contraste entre les couleurs identifiées est de 3:1 au moins.
- Si c'est le cas, le critère est validé.
1.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) ?
- Le rapport de contraste est de 3:1, au moins ;
- Un mécanisme de remplacement permet un rapport de contraste de 3:1, au moins.
Méthodologie du test 1.3.2
iOS et Android
- 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.
-
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.
- 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.
-
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 :
- En diffusant l'écran du terminal mobile sur l'ordinateur ;
- En réalisant des captures d'écran des éléments à évaluer (et en les important sur l'ordinateur).
- Vérifier que le rapport de contraste entre les couleurs identifiées est de 3:1 au moins.
- Si c'est le cas, le critère est validé.
Cas particuliers
Les cas suivants sont non applicables pour ce critère :
- Composant d'interface inactif (par exemple, un bouton ayant un état désactivé) sur lequel aucune action n'est possible.
- Composant d'interface pour lequel la couleur n'est pas nécessaire pour identifier le composant ou son état (exemple un groupe de liens faisant office de navigation dont la position dans la page, la taille et la couleur du texte permettent de comprendre qu'il s'agit de liens même si la couleur du soulignement des liens avec le fond blanc n'a pas un ratio de 3:1 et que le texte lui a un ratio de 4.5:1).
- élément graphique ou parties d'élément graphique non porteur d'information ou ayant une alternative (description longue, informations identiques visibles dans la page).
- é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 (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 dynamiques dont le contraste au survol / focus est suffisant
Références
WCAG 2.1
Critère(s) de succès :
RGAA 4.1.2
Critère(s) de référence :
2. Multimédia
2.1 Chaque média temporel est clairement identifiable (hors cas particuliers).
Test et références du critère 2.1
2.1.1
Pour chaque média temporel, seulement son, seulement vidéo ou synchronisé, le contenu textuel adjacent permet-il d'identifier clairement le média temporel (hors cas particuliers) ?
Méthodologie du test 2.1.1
iOS et Android
- Retrouver à l'écran les médias temporels pré-enregistrés seulement vidéo, audio ou synchronisé ;
- Pour chaque média temporel, vérifier qu'un passage de texte (un titre ou un paragraphe, par exemple) qui précède ou suit immédiatement le média temporel, permet de l'identifier ;
- Si c'est le cas, le critère est validé.
Cas particuliers
Il existe une gestion de cas particulier lorsque le média temporel est utilisé à des fins décoratives (c'est-à-dire qu'il n'apporte aucune information). Dans cette situation, le critère est non applicable.
Références
WCAG 2.1
Critère(s) de succès :
RGAA 4.1.2
Critère(s) de référence :
2.2 Chaque média temporel pré-enregistré a, si nécessaire, une transcription textuelle ou une audiodescription (hors cas particuliers).
Tests et références du critère 2.2
2.2.1
Chaque média temporel pré-enregistré seulement audio, vérifie-t-il, si nécessaire, l'une de ces conditions (hors cas particuliers) ?
- Il existe une transcription textuelle accessible via un lien ou bouton adjacent ;
- Il existe une transcription textuelle adjacente clairement identifiable.
Méthodologie du test 2.2.1
iOS et Android
- Retrouver à l'écran les médias temporels seulement audio qui nécessitent une transcription textuelle ;
-
Pour chaque média temporel seulement audio, vérifier la présence d'une transcription textuelle :
- Soit accessible au moyen d'un bouton ou d'un lien adjacent (une URL ou une ancre) ;
- Soit adjacente clairement identifiable.
- Si c'est le cas pour chaque média temporel, le test est validé.
2.2.2
Chaque média temporel pré-enregistré seulement vidéo vérifie-t-il, si nécessaire, l'une de ces conditions (hors cas particuliers) ?
- Il existe une version alternative « audio seulement », clairement identifiable, accessible via un lien ou bouton adjacent ;
- Il existe une transcription textuelle, clairement identifiable, accessible via un lien ou bouton adjacent ;
- Il existe une audiodescription synchronisée ;
- Il existe une version alternative, clairement identifiable, avec une audiodescription synchronisée accessible via un lien ou bouton adjacent.
Méthodologie du test 2.2.2
iOS et Android
- Retrouver à l'écran les médias temporels seulement vidéo qui nécessitent une transcription textuelle ou une audiodescription ;
-
Pour chaque média temporel seulement vidéo, vérifier la présence :
- Soit d'une version alternative audio seulement accessible au moyen d'un lien ou bouton adjacent (une URL ou une ancre) ;
- Soit d'une version alternative audio seulement adjacente ;
- Soit d'une transcription textuelle accessible au moyen d'un bouton ou d'un lien adjacent (une URL ou une ancre) ;
- Soit d'une transcription textuelle adjacente clairement identifiable ;
- Soit d'une audiodescription synchronisée ;
- Soit d'une version alternative avec une audiodescription synchronisée accessible au moyen d'un bouton ou d'un lien adjacent (une URL ou une ancre).
- Si c'est le cas pour chaque média temporel, le test est validé.
2.2.3
Chaque média temporel synchronisé pré-enregistré vérifie-t-il, si nécessaire, une de ces conditions (hors cas particuliers) ?
- Il existe une transcription textuelle, clairement identifiable, accessible via un lien ou bouton adjacent ;
- Il existe une version alternative, clairement identifiable, avec une audiodescription synchronisée accessible via un lien ou bouton adjacent.
Méthodologie du test 2.2.3
iOS et Android
- Retrouver à l'écran les médias temporels synchronisés qui nécessitent une transcription textuelle ou une audiodescription ;
-
Pour chaque média temporel synchronisé, vérifier la présence :
- Soit d'une transcription textuelle accessible au moyen d'un lien ou bouton adjacent (une URL ou une ancre) ;
- Soit d'une transcription textuelle adjacente clairement identifiable ;
- Soit d'une audiodescription synchronisée ;
- Soit d'une version alternative avec une audiodescription synchronisée accessible au moyen d'un bouton ou d'un lien adjacent (une URL ou une ancre).
- Si c'est le cas pour chaque média temporel, le test est validé.
Cas particuliers
Il existe une gestion de cas particulier lorsque :
- 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 ;
- Pour les services de l'état, les collectivités territoriales et leurs établissements : si le média temporel a été publié entre le 23 septembre 2019 et le 23 septembre 2020 sur un site internet, intranet ou extranet créé depuis le 23 septembre 2018, il est exempté de l'obligation d'accessibilité ;
- Pour les personnes de droit privé mentionnées aux 2° à 4° du I de l'article 47 de la loi du 11 février 2005 : si le média temporel a été publié avant le 23 septembre 2020, il est exempté de l'obligation d'accessibilité.
Dans ces situations, le critère est non applicable.
Références
WCAG 2.1
Critère(s) de succès :
RGAA 4.1.2
Critère(s) de référence :
2.3 Pour chaque média temporel pré-enregistré ayant une transcription textuelle ou une audiodescription synchronisée, celles-ci sont pertinentes (hors cas particuliers).
Tests et références du critère 2.3
2.3.1
Pour chaque média temporel pré-enregistré seulement audio, ayant une transcription textuelle, celle-ci est-elle pertinente (hors cas particuliers).
Méthodologie du test 2.3.1
iOS et Android
- Retrouver à l'écran les médias temporels pré-enregistrés seulement audio qui possèdent une transcription textuelle ;
- Pour chaque média temporel seulement audio, vérifier que transcription textuelle est pertinente ;
- Si c'est le cas pour chaque média temporel, le test est validé.
2.3.2
Chaque média temporel pré-enregistré seulement vidéo vérifie-t-il une de ces conditions (hors cas particuliers) ?
- La transcription textuelle est pertinente ;
- L 'audiodescription synchronisée est pertinente (toutes les informations visuelles qu'il est possible de vocaliser dans les blancs de la bande son principale sont présentes, les textes incrustés notamment);
- L 'audiodescription synchronisée de la version alternative est pertinente ;
- La version alternative audio seulement est pertinente.
Méthodologie du test 2.3.2
iOS et Android
- Retrouver à l'écran les médias temporels pré-enregistrés seulement vidéo qui possèdent une transcription textuelle ;
-
Pour chaque média temporel seulement vidéo, vérifier la pertinence :
- Soit de la transcription textuelle ;
- Soit de l'audiodescription synchronisée ;
- Soit de l'audiodescription synchronisée de la version alternative ;
- Soit de la version alternative audio seulement.
- Si c'est le cas pour chaque média temporel, le test est validé.
2.3.3
Chaque média temporel synchronisé pré-enregistré vérifie-t-il une de ces conditions (hors cas particuliers) ?
- La transcription textuelle est pertinente ;
- L 'audiodescription synchronisée est pertinente (toutes les informations visuelles qu'il est possible de vocaliser dans les blancs de la bande son principale sont présentes, les textes incrustés notamment) ;
- L 'audiodescription synchronisée de la version alternative est pertinente.
Méthodologie du test 2.3.3
iOS et Android
- Retrouver à l'écran les médias temporels pré-enregistrés synchronisés ;
-
Pour chaque média temporel synchronisé, vérifier la pertinence :
- Soit de la transcription textuelle ;
- Soit de l'audiodescription synchronisée ;
- Soit de l'audiodescription synchronisée de la version alternative.
- Si c'est le cas pour chaque média temporel, le test est validé.
Cas particuliers
Il existe une gestion de cas particulier lorsque :
- 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 ;
- Pour les services de l'état, les collectivités territoriales et leurs établissements : si le média temporel a été publié entre le 23 septembre 2019 et le 23 septembre 2020 sur un site internet, intranet ou extranet créé depuis le 23 septembre 2018, il est exempté de l'obligation d'accessibilité ;
- Pour les personnes de droit privé mentionnées aux 2° à 4° du I de l'article 47 de la loi du 11 février 2005 : si le média temporel a été publié avant le 23 septembre 2020, il est exempté de l'obligation d'accessibilité.
Dans ces situations, le critère est non applicable.
Références
WCAG 2.1
Critère(s) de succès :
RGAA 4.1.2
Critère(s) de référence :
2.4 Chaque média temporel synchronisé pré-enregistré a, si nécessaire, des sous-titres synchronisés (hors cas particuliers).
Test et références du critère 2.4
2.4.1
Chaque média temporel synchronisé pré-enregistré vérifie-t-il, si nécessaire, l'une de ces conditions (hors cas particuliers) ?
- Le média temporel synchronisé possède des sous-titres synchronisés ;
- Il existe une version alternative possédant des sous-titres synchronisés accessible via un lien ou bouton adjacent.
Méthodologie du test 2.4.1
iOS et Android
- Retrouver à l'écran les médias temporels pré-enregistrés synchronisés ;
-
Pour chaque média temporel synchronisé, vérifier la présence :
- Soit de sous-titres synchronisés ;
- Soit d'une version alternative possédant des sous-titres synchronisés accessible au moyen d'un lien ou d'un bouton adjacent.
- Si c'est le cas pour chaque média temporel, le test est validé.
Cas particuliers
Il existe une gestion de cas particulier lorsque :
- 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 ;
- Pour les services de l'état, les collectivités territoriales et leurs établissements : si le média temporel a été publié entre le 23 septembre 2019 et le 23 septembre 2020 sur un site internet, intranet ou extranet créé depuis le 23 septembre 2018, il est exempté de l'obligation d'accessibilité ;
- Pour les personnes de droit privé mentionnées aux 2° à 4° du I de l'article 47 de la loi du 11 février 2005 : si le média temporel a été publié avant le 23 septembre 2020, il est exempté de l'obligation d'accessibilité.
Dans ces situations, le critère est non applicable.
Références
WCAG 2.1
Critère(s) de succès :
RGAA 4.1.2
Critère(s) de référence :
2.5 Pour chaque média temporel synchronisé pré-enregistré ayant des sous-titres synchronisés, ces sous-titres sont pertinents.
Test et références du critère 2.5
2.5.1
Pour chaque média temporel synchronisé pré-enregistré ayant des sous-titres synchronisés, ces sous-titres sont-ils pertinents ?
Méthodologie du test 2.5.1
iOS et Android
- Retrouver à l'écran les médias temporels synchronisés possédant des sous-titres synchronisés ;
-
Pour chaque média temporel synchronisé, vérifier que les sous-titres sont :
- Pertinents (toutes les informations sonores importantes sont présentes, les dialogues notamment) ;
- Et correctement synchronisés.
- Si c'est le cas pour chaque média temporel synchronisé, le test 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 :
2.6 Chaque son déclenché automatiquement est contrôlable par l'utilisateur.
Test et références du critère 2.6
2.6.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 du test 2.6.1
iOS et Android
-
Au chargement du document, si un son se déclenche automatiquement, vérifier que :
- Soit la séquence sonore a une durée inférieure ou égale à 3 secondes ;
- Soit un dispositif (un bouton par exemple), sur l'élément ayant déclenché le son (voir note), ou dans la page, permet de le stopper ;
- Soit le volume de la séquence peut être contrôlé par l'utilisateur, indépendamment du contrôle de volume du système.
- Si c'est le cas, le test 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 :
2.7 Chaque média temporel propose des fonctionnalités de contrôle de sa consultation.
Test et références du critère 2.7
2.7.1
Pour chaque média temporel, des fonctionnalités de contrôle de sa lecture sont-elles présentes ?
Méthodologie de test 2.7.1
iOS et Android
- Repérer dans l'écran les médias temporels pré-enregistrés.
-
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 de désactiver le son ;
- Si le média possède une audiodescription, vérifier qu'il existe une fonctionnalité qui permet d'activer et de désactiver l'audiodescription.
- Si le média possède des sous-titres synchronisés, s'il s'agit de sous-titres non incrustés (closed captions) , vérifier qu'il existe une fonctionnalité qui permet d'activer et de désactiver ces sous-titres.
- 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 :
3. Tableaux
3.1 Chaque tableau de données complexe a un résumé et celui-ci est pertinent.
Test et références du critère 3.1
3.1.1
Pour chaque tableau de données complexe, un résumé pertinent est-il disponible ?
Méthodologie du test 3.1.1
iOS et Android
- Repérer dans l'écran les tableaux de données complexe.
- Vérifier qu'un résumé est disponible avant le tableau, sous la forme d'un texte précédant le tableau.
- Vérifier que ce résumé est pertinent.
- 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 :
3.2 Chaque tableau de données a un titre, et celui-ci est pertinent.
Test et références du critère 3.2
3.2.1
Pour chaque tableau de données, un titre pertinent est-il disponible ?
Méthodologie du test 3.2.1
iOS et Android
- Repérer dans l'écran les tableaux de données.
- Vérifier qu'un titre est disponible avant le tableau, sous la forme d'un texte.
- Vérifier que ce titre est pertinent.
- 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 :
3.3 Pour chaque tableau de données, les entêtes de lignes et de colonnes sont correctement reliés aux cellules de données.
Test et références du critère 3.3
3.3.1
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 du test 3.3.1
iOS et Android
- Repérer dans l'écran les tableaux de données.
- Activer le lecteur d'écran et parcourir les cellules de données.
- Vérifier que les entêtes sont correctement restitués.
- 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 :
4. Présentation de l'information
4.1 Dans chaque écran, l'information ne doit pas être transmise uniquement par une caractéristique sensorielle.
Test et références du critère 4.1
4.1.1
L'information transmise par une caractéristique sensorielle (forme, taille, position, orientation, son, vibration) peut-elle être obtenue par un texte ou un message explicite ?
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 du test 4.1.1
iOS et Android
- Repérer dans l'écran les informations données par la forme, la taille, la position, l'orientation, le son ou la vibration 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.
- 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).
- Si ce n'est pas le cas, activer le lecteur d'écran et vérifier qu'une information alternative à la forme, la taille, la position, l'orientation, le son ou la vibration est restituée par le lecteur d'écran.
- 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 :
4.2 Chaque lien dont la nature n'est pas évidente est visible par rapport au texte environnant.
Test et références du critère 4.2
4.2.1
Dans chaque page web, chaque lien texte signalé uniquement par la couleur, et dont la nature n'est pas évidente, vérifie-t-il ces conditions ?
- La couleur du lien a un rapport de contraste supérieur ou égal à 3:1 par rapport au texte environnant ;
- Le lien dispose d'une indication visuelle au survol autre qu'un changement de couleur ;
- Le lien dispose d'une indication visuelle au focus autre qu'un changement de couleur.
Méthodologie du test 4.2.1
iOS et Android
- Retrouver à l'écran les éléments de type lien ;
- Pour chaque élément de type lien, s'il peut être confondu avec un texte normal lorsqu'il est signalé uniquement par la couleur, vérifier que le contraste entre la couleur de police du lien et la couleur de police du texte environnant est de 3:1, au moins ;
- Cette vérification doit être faite pour les différents états du lien s'ils sont présentés au moyen d'une couleur différente : l'état non visité, l'état visité, l'état activé, l'état au survol et l'état à la prise de focus ;
- Si c'est le cas pour chaque élément de type lien, le test 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 :
4.3 Dans chaque écran, le texte peut être agrandi sans perte de contenu ou de fonctionnalité (hors cas particuliers).
Test et références du critère 4.3
4.3.1
Chaque écran vérifie-t-il ces conditions ?
- L'utilisateur peut agrandir la taille des textes de 200% en utilisant les paramètres du système ;
- Tous les textes de l'écran sont agrandis ;
- Tous les textes agrandis restent lisibles et les composants interactifs utilisables.
Méthodologie du test 4.3.1
iOS
-
Ouvrir le centre de contrôle, puis toucher le bouton « Taille du texte »
.
- Faire glisser le curseur vers le haut ou le bas pour augmenter ou réduire la taille du texte jusqu'à 190 %.
- En bas de l'écran, vérifier que la modification s'applique uniquement à l'application.
- Redémarrer l'application pour s'assurer que le paramètre est pris en compte par l'application.
-
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).
- Si c'est le cas, le critère est validé.
Android
- Accéder aux paramètres de réglages des tailles de caractères du système : Paramètres → Accessibilité → Taille de la police (selon la version du système, le chemin d'accès peut être différent) ;
- 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%).
- Si nécessaire, redémarrer l'application pour s'assurer que le paramètre est pris en compte par l'application.
-
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).
- Si c'est le cas, le critère est validé.
Note technique
Il n'est pas recommandé d'utiliser des éléments graphiques contenant du texte. Lorsqu'il est possible de reproduire les mêmes effets avec la technologie dans laquelle est développée l'interface, il est nécessaire que le texte soit reproduit dans ce format ou qu'un mécanisme de remplacement permette à l'utilisateur de remplacer ces éléments graphiques par du texte stylé.
Cas particuliers
Le critère est non applicable pour les éléments suivants :
- Les éléments graphiques texte dont les effets ne peuvent être reproduits dans la technologie dans laquelle est développée l'interface ;
- Le texte des logos ;
- Les sous-titres de vidéo.
Références
WCAG 2.1
Critère(s) de succès :
RGAA 4.1.2
Critère(s) de référence :
4.4 Dans chaque écran, la fonctionnalité de zoom des options d'accessibilité du terminal est utilisable et fonctionnelle.
Test et références du critère 4.4
4.4.1
L'utilisateur a-t-il la possibilité d'utiliser le zoom numérique fourni par les options d'accessibilité de l'appareil ?
Méthodologie du test 4.4.1
iOS
- Aller dans Réglages → Accessibilité → Zoom
- Activer la fonctionnalité de zoom
-
Parcourir les écrans :
- Toucher deux fois avec trois doigts pour zoomer
- Vérifier que la fonctionnalité de zoom n'est pas bloquée
- Si c'est le cas, le critère est validé.
Android
- Aller dans Réglages → Accessibilité → Agrandissement
- Activer la fonctionnalité d'agrandissement
-
Parcourir les écrans :
- Appuyez trois fois rapidement sur l'écran pour zoomer
- Vérifier que la fonctionnalité de zoom n'est pas bloquée
- 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 :
5. Formulaires
5.1 Chaque champ de formulaire a une étiquette visible.
Test et références du critère 5.1
5.1.1
Chaque champ de formulaire a-t-il une étiquette visible ?
Méthodologie du test 5.1.1
iOS et Android
- Repérer dans l'écran les champs de formulaire (champ de saisie, bouton radio, case à cocher).
- Vérifier la présence d'une étiquette visible.
- Activer le champ de formulaire (par exemple, saisir du texte).
- Vérifier que l'étiquette reste visible.
- 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 :
5.2 Pour chaque champ de formulaire ayant une étiquette visible, celle-ci est pertinente.
Test et références du critère 5.2
5.2.1
Chaque étiquette visible d'un champ de formulaire est-elle pertinente ?
Méthodologie du test 5.2.1
iOS et Android
- Repérer dans l'écran tous les champs de formulaire.
- Pour chaque champ de formulaire ayant une étiquette visible, vérifier que l'étiquette visible est pertinente (elle permet de comprendre la nature de la saisie attendue) ;
- 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 :
5.3 Dans chaque formulaire, chaque étiquette de champ et son champ associé sont accolés.
Test et références du critère 5.3
Méthodologie du test 5.3.1
iOS et Android
- Repérer dans l'écran tous les champs de formulaire.
- Pour chaque champ de formulaire, vérifier que l'étiquette visible est visuellement proche du champ auquel elle est liée.
-
Pour chaque champ de type bouton radio, case à cocher :
- L'étiquette est visuellement accolée immédiatement au-dessous ou à droite du champ de formulaire lorsque le sens de lecture de la langue de l'étiquette est de gauche à droite.
- L'étiquette est visuellement accolée immédiatement au-dessous ou à gauche du champ de formulaire lorsque le sens de lecture de la langue de l'étiquette est de droite à gauche.
-
Pour les autres types de champ :
- L'étiquette est visuellement accolée immédiatement au-dessus ou à gauche du champ de formulaire lorsque le sens de lecture de la langue de l'étiquette est de gauche à droite.
- L'étiquette est visuellement accolée immédiatement au-dessus ou à droite du champ de formulaire lorsque le sens de lecture de la langue de l'étiquette est de droite à gauche.
- 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 :
5.4 Dans chaque formulaire, le contrôle de saisie est utilisé de manière pertinente (hors cas particuliers).
Test et références du critère 5.4
5.4.1
Dans chaque formulaire, le contrôle de saisie vérifie-t-il ces conditions ?
- Les indications du caractère obligatoire de la saisie des champs sont visibles et permettent d'identifier nommément le champ concerné préalablement à la validation du formulaire ;
- Le contrôle de saisie est accompagné, si nécessaire, d'une instruction ou d'une indication du type de données et/ou de format obligatoire ;
- Les erreurs de saisie des champs sont visibles ;
Méthodologie du test 5.4.1
iOS et Android
- Valider le formulaire sans saisir de données afin d'identifier les champs obligatoires.
- Pour chaque champ obligatoire, vérifier qu'un texte visible à proximité du champ indique le caractère obligatoire du champ de formulaire.
- Pour chaque champ où une suggestion d'un type ou d'un format est nécessaire, vérifier qu'un texte visible à proximité du champ indique le type de données et/ou le format attendu.
- Pour chaque champ en erreur, vérifier que le message d'erreur est visible à proximité du champ ;
- Si c'est le cas, le critère est validé.
Note technique
Dans un long formulaire dont la majorité des champs sont obligatoires, on pourrait constater que ce sont les quelques champs restés facultatifs qui sont explicitement signalés comme tels. Dans ce cas, il faudrait s'assurer que :
- Un message précise visuellement en haut de formulaire que « tous les champs sont obligatoires sauf ceux indiqués comme étant facultatifs » ;
- Une mention « facultatif » est présente visuellement dans le libellé des champs facultatifs ou dans la légende d'un groupe de champs facultatifs ;
- Un état « obligatoire » reste associé à chaque champ qui n'est pas concerné par ce caractère facultatif.
Cas particuliers
L'indication du caractère obligatoire de la saisie sera considéré comme 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 associée au champ.
Dans le cas où l'ensemble des champs d'un formulaire sont obligatoires, le test reste applicable.
Références
WCAG 2.1
Critère(s) de succès :
RGAA 4.1.2
Critère(s) de référence :
5.5 Dans chaque formulaire, le contrôle de saisie est accompagné, si nécessaire, de suggestions facilitant la correction des erreurs de saisie.
Test et références du critère 5.5
5.5.1
Pour chaque erreur de saisie, les types et les formats de données, et des exemples de valeurs attendues, sont-ils suggérés, si nécessaire ?
Méthodologie du test 5.5.1
iOS et Android
- 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).
- Valider le formulaire.
- Pour chaque message d'erreur, vérifier que les types et les formats de données attendus sont suggérés ;
- Pour chaque message d'erreur, vérifier que des exemples de valeurs attendues sont suggérés ;
- Si c'est le cas pour chaque message d'erreur, le test 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 :
5.6 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 être modifiées, mises à jour ou récupérées par l'utilisateur.
Tests et références du critère 5.6
5.6.1
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, la saisie des données vérifie-t-elle une de ces conditions ?
- L'utilisateur peut modifier ou annuler les données et les actions effectuées sur ces données après la validation du formulaire ;
- L'utilisateur peut vérifier et corriger les données avant la validation d'un formulaire en plusieurs étapes ;
- Un mécanisme de confirmation explicite, via une case à cocher ou une étape supplémentaire, est présent.
Méthodologie du test 5.6.1
iOS et Android
- Remplir le formulaire.
- Retrouver à l'écran les formulaires qui modifient ou suppriment des données, ou qui transmettent des réponses à un test ou un examen, ou dont la validation a des conséquences financières ou juridiques ;
-
Pour chaque formulaire, vérifier que l'utilisateur peut :
- Soit modifier ou annuler les données et les actions effectuées sur ces données après la validation du formulaire ;
- Soit vérifier et corriger les données avant la validation d'un formulaire en plusieurs étapes ;
- Soit disposer d'un mécanisme de confirmation explicite (par exemple, une case à cocher ou une étape supplémentaire).
- Si c'est le cas, le critère est validé.
5.6.2
Chaque formulaire dont la validation modifie ou supprime des données à caractère financier, juridique ou personnel vérifie-t-il une de ces conditions ?
- Un mécanisme permet de récupérer les données supprimées ou modifiées par l'utilisateur ;
- Un mécanisme de demande de confirmation explicite de la suppression ou de la modification, via un champ de formulaire ou une étape supplémentaire, est proposé.
Méthodologie du test 5.6.2
iOS et Android
- Remplir le formulaire.
- Retrouver à l'écran les formulaires qui modifient ou suppriment des données à caractère financier, juridique ou personnel ;
-
Pour chaque formulaire, vérifier que l'utilisateur dispose :
- Soit d'un mécanisme qui permet de récupérer les données supprimées ou modifiées ;
- Soit d'un mécanisme de demande de confirmation explicite de la suppression ou de la modification (par exemple, une case à cocher ou une étape supplémentaire).
- 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 :
5.7 La finalité d'un champ de saisie peut être déduite pour faciliter le remplissage automatique des champs avec les données de l'utilisateur.
Test et références du critère 5.7
5.7.1
Chaque champ de formulaire dont l'objet se rapporte à une information concernant l'utilisateur vérifie-t-il ces conditions ?
- Les contrôles natifs adéquats du système sont présentés à l'utilisateur ;
- Le champ est compatible avec une fonctionnalité de remplissage automatique.
Méthodologie du test 5.7.1
iOS
- Accéder à chacun des champs de formulaire (taper sur le champ de saisie, par exemple, pour activer l'apparition des contrôles de saisie).
-
Pour chaque champ qui attend une donnée personnelle sur l'utilisateur, vérifier que les contrôles natifs adéquats du système 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.
- 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.
- Si c'est le cas, le critère est validé.
Android
- Accéder à chacun des champs de formulaire (taper sur le champ de saisie, par exemple, pour activer l'apparition des contrôles de saisie).
-
Pour chaque champ qui attend une donnée personnelle sur l'utilisateur, vérifier que les contrôles natifs adéquats du système 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.
- 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 du système, le chemin d'accès peut être différent) pour activer et paramétrer les données.
- 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.
- 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 :
6. Navigation générale
6.1 Dans chaque ensemble d'écrans, les mécanismes de navigation sont présents et toujours à la même place (hors cas particuliers).
Test et références du critère 6.1
6.1.1
Dans chaque ensemble d'écrans, les mécanismes de navigation sont-ils présents et toujours à la même place dans la présentation ?
Méthodologie du test 6.1.1
iOS et Android
- Parcourir les ensembles d'écrans
-
Pour chaque ensemble d'écrans :
- Vérifier l'existence d'un ou plusieurs mécanismes de navigation
- Pour chaque mécanisme de navigation, vérifier qu'il est placé au même endroit sur chaque écran.
- Si c'est le cas, le critère est validé.
Cas particuliers
Il existe une gestion de cas particuliers lorsque :
- L'écran est l'écran d'accueil de l'application ;
- L'application est constituée d'un seul écran ;
- Le changement fait suite à une modification initiée par l'utilisateur.
- Dans ces situations, le critère est non applicable.
Références
WCAG 2.1
Critère(s) de succès :
RGAA 4.1.2
Critère(s) de référence :
6.2 Chaque écran dispose d'un titre visible et pertinent.
Test et références du critère 6.2
6.2.1
Chaque écran dispose-t-il d'un titre visible et celui-ci est-il pertinent ?
Méthodologie du test 6.2.1
iOS et Android
Références
WCAG 2.1
Critère(s) de succès :
RGAA 4.1.2
Critère(s) de référence :
7. Navigation avec un lecteur d'écran
7.1 Les éléments porteurs d'information sont vocalisés de façon pertinente.
Test et références du critère 7.1
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
- Activer le lecteur d'écran
-
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.
- 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.
Test et références du critère 7.2
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
- Activer le lecteur d'écran
- Parcourir l'écran et repérer les éléments décoratifs
-
Vérifier :
- qu'ils ne peuvent pas être atteints avec le lecteur d'écran
- que leur contenu n'est pas restitué
- 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.
Test et références du critère 7.3
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
- Activer le lecteur d'écran
- Parcourir l'écran
- Vérifier que chaque contenu caché a vocation à être ignoré par le lecteur d'écran
- Vérifier qu'aucun élément fantôme n'est restitué par le lecteur d'écran
- 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.
Test et références du critère 7.4
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
- Activer le lecteur d'écran
- Parcourir l'écran
- Vérifier que l'ordre de vocalisation des éléments suit un ordre logique et permet de comprendre les informations véhiculées.
- 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.
Test et références du critère 7.5
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
- Activer le lecteur d'écran
- Parcourir l'écran
- Vérifier que chaque étiquette est vocalisée en même temps que son champ associé.
- 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.
Test et références du critère 7.6
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
- Activer le lecteur d'écran
- Parcourir l'écran
-
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.
- 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.
Tests et références du critère 7.7
7.7.1
Chaque écran possède-t-il au moins un titre ?
Méthodologie du test 7.7.1
iOS
- Activer le lecteur d'écran.
- Utiliser le rotor et sélectionner « En-têtes ».
- Parcourir l'écran en glissant un doigt vers le haut ou vers le bas.
- Vérifier l'existence d'au moins un titre
- Si c'est le cas, le critère est validé.
Android
- Activer le lecteur d'écran.
- Utiliser le menu des commandes de lecture et sélectionner « Titres ».
- Parcourir l'écran en glissant un doigt vers le haut ou vers le bas.
- Vérifier l'existence d'au moins un titre
- 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
- Activer le lecteur d'écran.
- Utiliser le rotor et sélectionner « En-têtes ».
- Parcourir les en-têtes en glissant un doigt vers le haut ou vers le bas.
-
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.
- Si c'est le cas, le critère est validé.
Android
- Activer le lecteur d'écran.
- Utiliser le menu des commandes de lecture et sélectionner « Titres ».
- Parcourir les titres en glissant un doigt vers le haut ou vers le bas.
-
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.
- 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.
Tests et références du critère 7.8
7.8.1
Chaque composant d'interface vérifie-t-il, si nécessaire, une de ces conditions ?
- Le nom, le rôle, la valeur, le paramétrage et les changements d'états sont accessibles aux technologies d'assistance via une API d'accessibilité ;
- Une alternative adjacente clairement identifiable compatible avec une API d'accessibilité permet d'accéder aux mêmes fonctionnalités.
Méthodologie du test 7.8.1
iOS et Android
- Activer le lecteur d'écran
- Repérer dans l'écran les composants interactifs (par exemple, bouton, lien, champs de formulaire, onglets, accordéons).
-
Vérifier que pour chaque composant, une de ces conditions est vérifiée :
- Le nom, le rôle, la valeur, le paramétrage et les changements d'états sont restitués ;
- Une alternative adjacente clairement identifiable compatible avec une API d'accessibilité permet d'accéder aux mêmes fonctionnalités.
- 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) ?
Méthodologie du test 7.8.2
iOS et Android
- Activer le lecteur d'écran.
- Repérer dans l'écran les composants interactifs (par exemple, bouton, lien, champs de formulaire, onglets, accordéons).
- Accéder à chaque composant interactif en utilisant les gestes du lecteur d'écran.
-
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.
- 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.
Test et références du critère 7.9
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
-
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.
-
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.
- 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.
Test et références du critère 7.10
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
- Activer le lecteur d'écran.
-
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.
- Vérifier que lorsque le statut apparaît, le lecteur d'écran restitue l'information et que cette information est compréhensible.
- 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.
Tests et références du critère 7.11
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
- Ouvrir le lanceur d'application du terminal
- Activer le lecteur d'écran
- Vérifier que l'intitulé donné à l'exécutable de l'application permet de clairement l'identifier
- Vérifier que cet intitulé est correctement vocalisé
- 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
- Ouvrir le lanceur d'application du terminal
- Activer le lecteur d'écran
- Positionner le focus sur l'exécutable de l'application
- Appuyer deux fois et maintenir enfoncé
- Vérifier que l'intitulé donné à chaque raccourci de l'application est pertinent et correctement vocalisé.
- Si c'est le cas, le test est validé.
Références
WCAG 2.1
Critère(s) de succès :
8. Navigation au clavier
8.1 Dans chaque écran, pour chaque élément recevant le focus, la prise de focus est visible.
Test et références du critère 8.1
8.1.1
Pour chaque élément recevant le focus, la prise de focus vérifie-t-elle une de ces conditions ?
- Le style du focus natif du système d'exploitation, de la technologie d'assistance, ou du navigateur, n'est pas supprimé ou dégradé.
- Un style du focus défini par l'auteur est visible.
Méthodologie du test
iOS et Android
- Connecter un clavier externe (et paramétrer la navigation au clavier).
- Naviguer dans l'application et évaluer si la visibilité du focus est préservée sur l'ensemble des éléments de l'application.
- 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 :
8.2 Dans chaque écran, l'ordre de tabulation est cohérent.
Test et références du critère 8.2
8.2.1
Dans chaque écran, l'ordre de tabulation dans le contenu est-il cohérent ?
Méthodologie du test 8.2.1
iOS et Android
- Connecter un clavier externe (et paramétrer la navigation au clavier).
- 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.
-
Repérer dans l'écran les composants (bouton par exemple) qui actualisent un contenu (affichage d'élément masqué, mise à jour dynamique de contenus par exemple) :
- activer le composant ;
- après l'affichage du contenu actualisé, vérifier que la tabulation reste cohérente.
- 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 :
8.3 La navigation ne contient pas de piège au clavier.
Test et références du critère 8.3
8.3.1
Dans chaque page web, 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 la touche de tabulation ;
- 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 du test 8.3.1
iOS et Android
- Retrouver dans l'écran l'ensemble des éléments d'interface susceptibles de recevoir le focus (au moyen de la tabulation ou au moyen d'un script) ;
-
Pour chaque élément d'interface, vérifier que l'utilisateur peut atteindre l'élément suivant ou précédent pouvant recevoir le focus :
- Soit au moyen de la touche de tabulation (Tab ou Maj+Tab) ;
- Soit au moyen d'une autre interaction clavier dont l'utilisateur est informé (par exemple, les flèches de direction).
- Si c'est le cas pour chaque élément d'interface, le test 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 :
8.4 Chaque fonctionnalité de l'interface est contrôlable au clavier (hors cas particuliers).
Test et références du critère 8.4
8.4.1
Chaque composant d'interface vérifie-t-il une de ces conditions ?
- L'élément est atteignable et contrôlable au clavier ;
- Il existe une manière alternative, atteignable et contrôlable au clavier, d'accéder à la même fonctionnalité.
Méthodologie du test 8.4.1
iOS et Android
- Connecter un clavier externe (et paramétrer la navigation au clavier).
- Parcourir l'ensemble des composants interactifs.
-
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.
- sinon, vérifier qu'un élément atteignable et contrôlable au clavier permettant de réaliser la même action est présent à l'écran.
- 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.
- Si c'est le cas, le critère est validé.
Cas particuliers
Il existe une gestion de cas particulier lorsque 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. Dans ces situations, le critère est non applicable.
Références
WCAG 2.1
Critère(s) de succès :
RGAA 4.1.2
Critère(s) de référence :
9. Consultation
9.1 L'utilisateur a le contrôle de chaque limite de temps modifiant le contenu (hors cas particuliers).
Test et références du critère 9.1
9.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.
Méthodologie du test 9.1.1
iOS et Android
- Repérer les procédés limitant le temps d'une session (par exemple, après une authentification).
-
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.
- Si c'est le cas, le critère est validé.
Cas particuliers
Il existe une gestion de cas particuliers lorsque la limite de temps est essentielle, notamment lorsqu'elle ne pourra pas être supprimée sans changer fondamentalement le contenu ou les fonctionnalités liées au contenu.
Références
WCAG 2.1
Critère(s) de succès :
RGAA 4.1.2
Critère(s) de référence :
9.2 Chaque document bureautique en téléchargement possède, si nécessaire, une version accessible (hors cas particuliers).
Test et références du critère 9.2
9.2.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.
Méthodologie du test 9.2.1
iOS et Android
- Retrouver à l'écran les liens et les contrôles de formulaire (un bouton de formulaire ou un formulaire de téléchargement par exemple) permettant de télécharger un fichier au format bureautique ;
-
Pour chaque fichier au format bureautique, vérifier la présence d'une version alternative présentée comme accessible :
- Pour les documents au format .pdf, analyser le fichier avec l'outil PAC (PDF Accessibility Checker ) et vérifier l'absence d'erreur d'accessibilité dans le document (cf. note) ;
- Pour les documents au format .doc ou .docx, analyser le fichier avec l'outil de vérification d'accessibilité de Microsoft Office (à partir de la version 2010) et vérifier l'absence d'erreur d'accessibilité (cf. note) ;
- Pour les documents au format .odt, analyser le document avec l'éditeur OpenOffice et vérifier que l'ensemble des contenus est en conformité avec la liste des critères « Liste document bureautique en téléchargement » (cf. note pour une méthode alternative) ;
- Pour les documents au format EPUB/DAISY, analyser le document avec un éditeur EPUB/DAISY et vérifier que l'ensemble des contenus est en conformité avec la liste des critères « Liste document bureautique en téléchargement ».
- Pour les documents eux-mêmes au format .html, analyser l'accessibilité du document.
- Si c'est le cas pour chaque fichier au format bureautique, le test est validé.
Cas particuliers
Il existe une gestion de cas particuliers :
- Pour les personnes de droit privé mentionnées aux 2° à 4° du I de l'article 47 de la loi du 11 février 2005 : si les fichiers bureautiques (ex : PDF, documents Microsoft ou LibreOffice, etc.) ont été publiés avant le 23 septembre 2018 (sauf si ce sont des documents nécessaires pour accomplir une démarche administrative relevant des tâches effectuées par l'organisme concerné), ils sont exemptés de l'obligation d'accessibilité.
Dans cette situation, le critère est non applicable.
Références
WCAG 2.1
Critère(s) de succès :
RGAA 4.1.2
Critère(s) de référence :
9.3 Pour chaque document bureautique ayant une version accessible, cette version offre la même information.
Test et références du critère 9.3
9.3.1
- La version compatible avec l'accessibilité offre la même information ;
- La version alternative est pertinente et offre la même information.
Méthodologie du test 9.3.1
iOS et Android
- Retrouver à l'écran les fichiers en téléchargement au format bureautique accompagné de leur version alternative accessible ;
- Pour chaque couple de fichiers, ouvrir les deux documents (le document d'origine et le document accessible) et vérifier que les deux documents apportent la même information ;
- Si c'est le cas pour chaque couple de fichiers, le test 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 :
9.4 Les changements brusques de luminosité ou les effets de flash sont correctement utilisés.
Test et références du critère 9.4
9.4.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 du test 9.4.1
iOS et Android
- 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.
-
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.
- Si c'est le cas, le critère est validé.
Note :
L'évaluation de ce critère peut être complexe. Lorsque l'effet est géré par un script ou au moyen de CSS, l'analyse du code est suffisante. L'outil PEAT permet d'analyser les vidéos au format .avi, par exemple. Un exemple de vidéo ayant provoqué des crises d'épilepsie peut être consulté ici : London 2012 Olympics Seizure.
Références
WCAG 2.1
Critère(s) de succès :
RGAA 4.1.2
Critère(s) de référence :
9.5 Chaque contenu en mouvement ou clignotant est contrôlable par l'utilisateur.
Test et références du critère 9.5
9.5.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 du test 9.5.1
iOS et Android
- 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).
-
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.
- 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.
Références
WCAG 2.1
Critère(s) de succès :
RGAA 4.1.2
Critère(s) de référence :
9.6 Le contenu proposé est consultable quelle que soit l'orientation de l'écran (portrait ou paysage) (hors cas particuliers).
Test et références du critère 9.6
9.6.1
Dans chaque page écran, chaque contenu vérifie-t-il ces conditions (hors cas particuliers) ?
- 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 utilisé même si sa présentation et le moyen d'y accéder peut différer.
Méthodologie du test 9.6.1
iOS
-
Ouvrir le Centre de contrôle.
-
Vérifier que l'orientation de l'écran n'est pas verrouillée dans les paramètres du système (voir la documentation officielle).
-
Afficher l'application et basculer le terminal alternativement en mode paysage et portrait.
-
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).
-
Si c'est le cas, le critère est validé.
Android
-
Ouvrir le panneau de configuration rapide.
-
Vérifier que le paramètre « Rotation automatique » est activé (voir la documentation officielle).
-
Afficher l'application et basculer le terminal alternativement en mode paysage et portrait.
-
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).
-
Si c'est le cas, le critère est validé.
- 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).
- 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).
Cas particuliers
Il existe des interfaces pour lesquelles l'orientation du périphérique est essentielle à leur utilisation.
Dans ces situations, le critère est non applicable. Il peut s'agir d'interfaces de jeu, de piano, de dépôt de chèques bancaires, etc.
Si l'interface est le seul moyen d'accéder au service proposé, une alternative devrait être mise en place pour pallier cette carence.
Références
WCAG 2.1
Critère(s) de succès :
RGAA 4.1.2
Critère(s) de référence :
9.7 Les fonctionnalités utilisables ou disponibles au moyen d'un geste complexe peuvent également être disponibles au moyen d'un geste simple (hors cas particuliers).
Test et références du critère 9.7
9.7.1
Dans chaque page web, chaque fonctionnalité utilisable ou disponible soit suite à un contact multipoint, soit suite à un geste basé sur le suivi d'une trajectoire sur l'écran, est-elle également utilisable ou disponible suite à un contact en un point unique de l'écran (hors cas particuliers).
Méthodologie du test 9.7.1
iOS et Android
-
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).
- 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.
- Si c'est le cas, le critère est validé.
Cas particuliers
Il existe une gestion de cas particuliers dans deux types de situations :
- Le critère ne s'applique qu'à des fonctionnalités mises en place par l'auteur de l'application. Il ne concerne donc pas les gestes requis par l'agent utilisateur ou le système d'exploitation ;
- Le critère ne s'applique pas aux fonctionnalités dont la réalisation d'un geste complexe est essentielle (exécuter le tracé d'une signature, par exemple).
Références
WCAG 2.1
Critère(s) de succès :
RGAA 4.1.2
Critère(s) de référence :
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).
Test et références du critère 9.8
9.8.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é ;
- 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.
Méthodologie du test 9.8.1
iOS et Android
- Repérer dans l'écran les composants interactifs (par exemple, bouton ou lien).
- Pour chaque composant interactif, effectuer un appui simple dessus et conserver la pression.
- Déplacer le dispositif de pointage en dehors de la zone interactive et constater que l'action associée n'est pas déclenchée.
- Si c'est le cas, le critère est validé
Cas particuliers
Le critère est non applicable pour les actions requises par la plateforme.
Note technique
Un exemple de mécanisme mis en place pour annuler ou abandonner une action déclenchée au moyen d'un dispositif de pointage sur un point unique de l'écran est l'utilisation d'une fenêtre modale permettant d'annuler l'action après son achèvement ;
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).
Test et références du critère 9.9
9.9.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é.
Méthodologie du test 9.9.1
iOS et Android
- 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écrivent ce type de déclenchement).
-
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).
- Si c'est le cas, le critère est validé.
Cas particuliers
Il existe une gestion de cas particulier 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é.
Références
WCAG 2.1
Critère(s) de succès :
RGAA 4.1.2
Critère(s) de référence :
Glossaire
A
Accessible aux technologies d'assistance
Pour qu'une information soit accessible aux technologies d'assistance, elle doit être mise à disposition de ces dernières, au travers du logiciel lui-même ou par l'intermédiaire d'une API d'accessibilité, cette dernière méthode étant la plus répandue.
Ceci peut être réalisé au travers des propriétés descriptives parfois non visibles sur l'interface, mais restituées par les technologies d'assistance, soit au travers des paramètres de l'API définissant, par exemple, des états (sélectionné, actif, désactivé, etc.).
Accessible et activable par le clavier et tout dispositif de pointage
Les dispositifs de pointage en environnement mobile peuvent être, mais ne sont pas limités à :
- le toucher ;
- la souris ;
- les dispositifs d'eye tracking ;
- les dispositifs d'analyse par point sur iOS (ou recherche par point sur Android) ;
- la commande vocale.
Un composant d'interface (lien, bouton, champ de formulaire, etc.) est accessible par tout dispositif de pointage lorsque l'utilisateur :
- peut prendre le focus sur le composant, indifféremment du dispositif ;
- peut enclencher l'action prévue par le composant d'interface par une manipulation propre au dispositif (une certaine touche du clavier, un geste sur l'écran par exemple);
Attention : pour certains composants d'interface comme les potentiomètres (slider, bouton rotatif), plusieurs interactions sont possibles et donc plusieurs manipulations propres au dispositif peuvent être requises pour interagir avec le composant. Au clavier, par exemple pour les potentiomètres, les flèches de direction (droite, gauche, haut et bas) permettent d'interagir et de modifier le composant.
Dans ce référentiel, l'expression « contrôlable par le clavier et tout dispositif de pointage » se rapporte également à la présente définition.
Note importante : le recours à certaines technologies peut rendre la gestion du focus trop complexe ou trop instable pour ne reposer que sur la tabulation, les touches de direction et la touche entrée. Dans ce cas, la mise à disposition de raccourcis clavier peut être la seule solution pour rendre le composant utilisable. Le critère ne peut être considéré comme conforme qu'à la condition que les raccourcis clavier utilisés soient correctement documentés et qu'ils soient fonctionnels.
Accolés (étiquette et champ accolés)
Il faut que l'étiquette et son champ soient visuellement proches, de manière que la relation entre les deux ne puisse pas prêter à confusion.
Audiodescription synchronisée (média temporel)
Narration ajoutée (via un fichier son) à une piste sonore pour décrire les détails visuels importants qui ne peuvent être compris à partir de la piste sonore principale seulement. L'audiodescription doit être synchronisée avec le média temporel par un dispositif applicatif lié au lecteur lui-même ou fourni par le développement, par exemple, avec JavaScript.
Note 1 : l'audiodescription d'une vidéo fournit de l'information à propos des actions, des personnages, des changements de scènes, du texte apparaissant à l'écran et d'autres contenus visuels.
Note 2 : dans une audiodescription standard, la narration est ajoutée durant les pauses qui existent dans le dialogue.
Note 3 : lorsque toute l'information de la vidéo est déjà donnée dans la piste audio, aucune audiodescription supplémentaire n'est requise.
C
Centre de contrôle
Pour ouvrir le centre de contrôle, il faut :
- Sur un iPhone avec Face ID, balayer vers le bas depuis le coin supérieur droit de l'écran.
- Sur un iPhone avec un bouton principal, balayer vers le haut depuis le bord inférieur de l'écran.
Champ de saisie
Objet d'un formulaire permettant à l'utilisateur :
- De saisir des données textuelles ou préformatées (par exemple, un champ de texte, un champ de mot de passe)
- De sélectionner des valeurs prédéfinies (par exemple, une liste déroulante, des boutons radio, des cases à cocher)
- De téléverser des fichiers
- Ou d'afficher des résultats
Les boutons ne sont pas considérés comme des champs de formulaires.
Compatible avec les technologies d'assistance
Un contenu ou une fonctionnalité doit être compatible avec les technologies d'assistance des utilisateurs ainsi qu'avec les fonctions d'accessibilité des logiciels via une API d'accessibilité.
Cela concerne, à la fois, la technologie, ses fonctionnalités et ses usages :
La façon dont la technologie est utilisée doit être compatible avec les technologies d'assistance des utilisateurs. Cela signifie que la façon dont la technologie est utilisée a été testée dans une perspective d'interopérabilité avec des utilisateurs des technologies d'assistance dans les contenus du logiciel.
La technologie fonctionne de façon native sur la plateforme et utilise l'API d'accessibilité du système.
Composant d'interface
Un composant d'interface est un élément avec lequel l'utilisateur peut interagir, par exemple, un bouton, un lien, une zone de saisie.
Certains composants peuvent être plus complexes comme un menu, une fenêtre de dialogue, un système d'onglets.
Enfin, pour les vues web, un composant d'interface peut être basé sur des éléments natifs de HTML ou développés de toutes pièces en JavaScript et des attributs WAI-ARIA. En particulier pour les éléments ayant des attributs WAI-ARIA correspondant à un motif de conception, il est recommandé de considérer le document WAI-ARIA 1.1 Authoring Practices lors de leur implémentation.
Compréhensible (ordre de lecture)
Un contenu compréhensible est lisible (l'ordre des éléments est logique) et cohérent (l'enchaînement de la lecture est cohérent).
Contenu caché
Un contenu caché est un élément de l'interface dont la restitution par les technologies d'assistance est empêchée.
Par exemple : un menu déroulant réduit, un contenu accordéon réduit, une modale non affichée, un tableau d'onglet non sélectionné sont des contenus cachés tant qu'ils ne sont pas visibles à l'écran.
Contraste
Opposition marquée entre la luminosité d'une couleur de premier plan et d'une couleur d'arrière-plan. Le rapport de contraste est basé sur la différence de luminance relative entre l'arrière-plan et le premier plan selon la règle : (L1 + 0,05) / (L2 + 0,05) où L1 est la luminance relative la plus claire et L2 la luminance relative la plus sombre. La luminosité est calculée selon la formule suivante : L = 0,2126 _ R + 0,7152 _ G + 0,0722 * B. Où R, G et B sont définis par :
Si R sRGB ⩽ 0,03928 alors R = R sRGB /12,92 sinon R = ((R sRGB +0,055)/1,055) ^ 2,4 ;
Si G sRGB ⩽ 0,03928 alors G = G sRGB /12,92 sinon G = ((G sRGB +0,055)/1,055) ^ 2,4 ;
Si B sRGB ⩽ 0,03928 alors B = B sRGB /12.92 sinon B = ((B sRGB +0,055)/1,055) ^ 2,4.
et R sRGB, G sRGB et B sRGB sont définis par :
R sRGB = R8bit/255 ;
G sRGB = G8bit/255 ;
B sRGB = B8bit/255.
Le caractère « ^ » est l'opérateur de puissance.
Note : la mesure de contraste concerne le texte, le texte en image, le texte et le texte en image dans les animations, le texte de sous-titrage et le texte incrusté dans les vidéos. Pour le texte et le texte en image dans les animations, le texte de sous-titrage et le texte incrusté dans les vidéos, la taille de la police doit être mesurée par rapport à la taille d'affichage par défaut (telle qu'affichée). Les textes présents dans les éléments d'une image ou d'une vidéo (par exemple un écriteau, une affiche…) ne sont pas concernés.
Source (en anglais) : Procédure de calcul de contraste des WCAG .
Contraste (taille des textes)
La norme distingue plusieurs tailles de textes à évaluer, chaque taille relevant d'un seuil de contraste. Ces tailles sont évaluées en pixel ou en point. Plus un texte est grand (supérieur à 18,5px avec effet de graisse ou 24px sans effet de graisse) moins le rapport requis est élevé (3:1).
Compte tenu de la difficulté à évaluer les tailles de polices sur mobile, tous les textes devraient être considérés en taille normale sauf pour des textes significativement très grands.
Par exemple, on pourrait considérer un texte « significativement très grand » si les lettres qui le composent ont une hauteur et/ou largeur au moins égales à 1,5 cm.
Contrôle de la consultation (d'un média temporel)
Possibilité pour l'utilisateur de contrôler la consultation d'un média temporel par le clavier et tout dispositif de pointage, au moins. Les points suivants doivent être respectés :
- Liste des fonctionnalités obligatoires de contrôle de la consultation :
- L'objet multimédia doit toujours avoir les fonctionnalités suivantes, au minimum : lecture, pause ou stop ;
- Si l'objet multimédia a du son, il doit avoir une fonctionnalité d'activation / désactivation du son ;
- Si l'objet multimédia a une audiodescription, il doit avoir une fonctionnalité de contrôle de l'apparition / disparition de l'audiodescription.
- Chaque fonctionnalité doit être accessible par le clavier, via la touche de tabulation, et par tout dispositif de pointage au moins.
- Chaque fonctionnalité doit être activable par le clavier et par tout dispositif de pointage, au moins.
Note : s'il n'y a pas de son à un média temporel, il n'est pas utile de mettre une fonctionnalité d'activation / désactivation du son. Si cette fonctionnalité est cependant présente et qu'elle nécessite une alternative textuelle pour être comprise par certains utilisateurs, il faut alors lui en donner une puisque l'utilisateur est susceptible d'y accéder et de vouloir l'activer.
Contrôle (son déclenché automatiquement)
Possibilité pour l'utilisateur d'arrêter ou de relancer un son déclenché automatiquement.
Note : la méthode de contrôle du son devrait être disponible comme premier élément de la page.
Contrôle de saisie (formulaire)
Ensemble des processus qui permettent de prévenir l'utilisateur :
- des champs obligatoires,
- des indications de type ou de format attendus,
- des erreurs de saisie dans un formulaire.
D
Donnée personnelle de l'utilisateur
Les données personnelles concernant l'utilisateur dans un formulaire peuvent être :
- le nom ;
- le prénom ;
- le mot de passe ;
- l'adresse e-mail ;
- l'adresse postale ;
- le code postal ;
- le numéro de téléphone ;
- les codes de carte bleue ;
- la date d'anniversaire ;
- l'URL d'une page web présentant l'utilisateur ou l'organisation que représente la personne.
E
Élément décoratif
Élément de l'interface n'ayant aucune fonction et ne véhiculant aucune information particulière par rapport au contenu auquel il est associé.
Exemples :
- Un élément graphique servant à caler la mise en page.
- Une image décorative
- Un élément textuel utilisé comme séparateur
- Une vidéo décorative
Élément fantôme
Élément perturbant la navigation, non utilisable sur la vue courante : bien qu'invisible à l'écran, il est restitué par le lecteur d'écran (élément positionné en dehors de la zone visible ou masqué par d'autres éléments).
La superposition d'écrans est quelque chose de courant sur mobile mais il faut s'assurer que les informations d'une vue placée « sous » une autre ne sont pas restituées.
Un exemple fréquent d'élément fantôme survient lors de la création de composant personnalisé tels que des « alert dialog » par exemple.
Élément graphique
Élément faisant appel à une représentation visuelle telle que des images, des pictogrammes ou des graphiques.
Cet élément peut être composé d'une ou plusieurs parties dont la visibilité est nécessaire à sa compréhension (par exemple chaque point sur chaque ligne d'un graphique de statistiques).
Le rôle « Image » n'est pas restitué de manière uniforme sur tous les environnements.
TalkBack (Android) : la nature des éléments graphiques n'est pas restituée lorsqu'ils sont intégrés dans une application native, le lecteur d'écran restituera la description si elle est définie, mais n'annoncera pas « image ». Par contre, pour les images intégrées dans des vues web, le lecteur d'écran restitue « éléments graphiques ».
VoiceOver (iOS) : que ce soit dans une application native ou dans une vue web, VoiceOver restitue « Image » pour les images auxquelles il peut accéder.
De manière générale, selon la méthode de développement, il est également possible que le rôle ne soit restitué ni sur TalkBack ni sur VoiceOver. Dès lors, c'est l'observation seule qui permettra de déterminer la nature de l'élément.
Il n'est pas essentiel que le rôle « Image » soit restitué dans la majeure partie des cas. Sauf cas particuliers où l'identification du rôle est essentiel, l'absence de rôle restitué ne peut pas constituer une non-conformité.
Élément porteur d'information
Contenu textuel ou graphique véhiculant des informations.
En-tête de colonne ou de ligne
Contenu d'une cellule dans un tableau de données (la première cellule d'une colonne ou d'une ligne, généralement) qui sert d'intitulé pour la totalité ou une partie des cellules de la colonne ou de la ligne. Une colonne ou une ligne peut contenir plusieurs en-têtes (en-tête intermédiaire).
Étiquette de champ de formulaire
Texte à proximité du champ de formulaire permettant d'en connaître la nature, le type ou le format des informations attendues.
Étiquettes cohérentes
Les étiquettes de champs de formulaire présentes dans une même page ou dans un ensemble de pages et réclamant la saisie d'une même information doivent être formulées sans ambiguïté pour que l'utilisateur sache que l'information qu'il doit communiquer est la même.
G
Gestes complexes et gestes simples
Un geste simple avec un écran implique un contact en un point unique de l'écran. Il peut s'agir d'une pression ou d'un clic simple, d'une double pression ou d'un double-clic, d'une pression prolongée.
Un geste complexe peut être :
- un geste impliquant plusieurs points de contact sur l'écran (exemple : un geste avec deux doigts sur l'écran pour zoomer ou dézoomer une carte) ;
- un geste basé sur le suivi d'une trajectoire sur l'écran (exemple : fonction permettant de détecter le déplacement d'un doigt vers la gauche ou droite sur une surface tactile pour déclencher le passage à l'item précédent / suivant d'un carrousel).
I
Ignoré par les technologies d'assistance
La restitution d'éléments comme des éléments graphiques de décoration qui n'apportent pas d'information pertinente peut créer des conditions de consultation complexes en surchargeant d'informations inutiles la restitution par les technologies d'assistance.
Il est donc important de pouvoir empêcher la restitution de ces éléments. La plupart des API d'accessibilité possèdent des propriétés ou des méthodes permettant d'empêcher la restitution de ce type d'élément.
Image de décoration
Image n'ayant aucune fonction et ne véhiculant aucune information particulière par rapport au contenu auquel elle est associée.
Exemples :
- Une image précédant chaque item d'une liste ;
- Une image servant à caler la mise en page ;
- Une image de coin arrondie pour habiller un bloc d'information ;
- Une image d'illustration n'apportant aucune information nécessaire à la compréhension du texte auquel elle est associée.
Image porteuse d'information
Image qui véhicule une information nécessaire à la compréhension du contenu auquel elle est associée.
Image véhiculant une information (donnée par la couleur)
Image dont tout ou partie du contenu transmet visuellement une information par l'intermédiaire d'une couleur uniquement.
Indication de champ obligatoire
Indication textuelle ou graphique (icône) permettant à l'utilisateur de savoir que la saisie d'un champ est obligatoire préalablement à la saisie.
Note : Dans le cas où cette indication ne serait pas réalisée de manière textuelle explicite (icône, « * », « ! », etc.), l'explication de la signification de cette indication doit se situer, visuellement et dans l'ordre du code source, avant la première utilisation de l'indication.
Indication donnée par une caractéristique sensorielle (la forme, la taille, la position, le son, la vibration)
Il peut s'agir, par exemple :
- De la présence d'un marqueur visuel, pour indiquer la page active dans un menu de navigation (indication donnée par la position) ;
- D'une mise en avant-plan pour indiquer un onglet actif (indication donnée par la forme) ;
- D'une modification de la taille de police dans un nuage de tags (indication donnée par la taille);
- D'une vibration ou d'un son pour indiquer le résultat d'une action.
Ou de toute autre caractéristique sensorielle similaire.
Indication du type de données et/ou de format
Indication textuelle permettant à l'utilisateur de savoir quel est le type de donnée et/ou le format de saisie requis par un champ obligatoire, préalablement à son renseignement.
Exemples :
- Courriel (format : vous@domaine.com)
- Code postal (format : 00000)
- Date (format : JJ/MM/AAAA)
Information (donnée par la couleur)
Information transmise visuellement par l'intermédiaire d'une couleur. L'indication que les champs en rouge sont obligatoires dans un formulaire, l'utilisation d'un fond bleu pour indiquer la page en cours de consultation dans un menu avec le fond vert, le changement de couleur d'un nom d'article pour indiquer son indisponibilité dans une liste d'articles sont autant d'exemples d'indication donnée par la couleur.
Lorsqu'une information donnée par la couleur est accompagnée d'une autre méthode à destination des utilisateurs qui ne voient pas ou perçoivent mal les couleurs ou leurs associations, le critère sera considéré comme non applicable.
Les moyens de transmettre une information autrement que par la couleur peuvent être :
- Une indication textuelle visible
- Un moyen faisant intervenir du graphisme (pictogramme, image de fond, forme, style de bordure différent, etc) et par le biais d'un complément au niveau du code.
- Un autre style typographique (gras, italique, taille de texte, autre police, etc) et par le biais d'un complément au niveau du code.
L
Lien dont la nature n'est pas évidente
Lien qui peut être confondu avec un texte normal lorsqu'il est signalé uniquement par la couleur par certains types d'utilisateurs ne percevant pas ou mal les couleurs. Par exemple, dans ce texte « Nouvelle grève à la SNCF », si le mot « grève » est un lien signalé uniquement par la couleur, sa nature peut être ignorée par les utilisateurs ne percevant pas la couleur et accédant au contenu CSS activé.
Note : « signalés uniquement par la couleur » signifie que le lien n'est accompagné d'aucun marqueur visuel (icône, soulignement, bordure…). En conséquence, un lien de la même couleur que le texte environnant est concerné par ce critère.
M
Mécanisme qui permet d'afficher un rapport de contraste conforme
Composant d'interface dont l'activation permet de modifier l'apparence de l'application ou de l'écran (ou de la page dans le cas d'une vue web) de manière à afficher les contenus avec un ratio de contraste suffisant. Le design de ce composant d'interface devra être conforme aux critères 1.2 et 1.3 sans recourir lui-même à un mécanisme permettant d'afficher un rapport de contraste conforme. Ce mécanisme doit conserver à l'identique les contenus et les fonctionnalités de l'application ou de l'écran (ou de la page dans le cas d'une vue web) qu'il modifie.
Mécanismes de remplacement disponibles sur iOS
- Augmenter le contraste : l'option est disponible depuis le chemin : Réglages → Accessibilité → Affichage et taille du texte → Augmenter le contraste. Lorsqu'elle est activée, cette option permet de charger des styles différents qui auraient été définis par l'auteur pour cette option précise afin d'offrir une version plus contrastée aux utilisateurs qui en auraient besoin. De plus, cette option permet d'augmenter le contraste des composants natifs d'iOS comme les boutons switch.
- Différencier sans couleur : L'option est disponible depuis le chemin : Réglages → Accessibilité → Affichage et taille du texte → Différencier sans couleur. Lorsqu'elle est activée, cette option permet de charger des informations visuelles supplémentaires autres que la couleur (par exemple, forme ou taille) qui auraient été définies par l'auteur pour cette option précise afin de mettre en évidence un élément graphique dont la mise en couleur est porteuse d'information (un bouton actif par exemple).
Mécanismes de remplacement disponibles sur Android
- Augmenter le contraste : l'option est disponible depuis le chemin : Paramètres → Accessibilité → Taille d'affichage et texte → Texte avec contraste élevé. Lorsqu'elle est activée, cette option permet de charger des styles différents qui auraient été définis par l'auteur pour cette option précise afin d'offrir une version plus contrastée aux utilisateurs qui en auraient besoin.
Média temporel (type son, vidéo et synchronisé)
- Média temporel seulement audio : contenu sonore (wave, MP3…).
- Média temporel seulement vidéo : images ou photos en mouvement ou en séquence.
- Média temporel synchronisé : flux audio ou vidéo synchronisé avec un autre format pour présenter de l'information et/ou comportant des composants temporels interactifs. Un média temporel peut être consulté de 2 manières différentes :
- fichier à télécharger consultable avec un logiciel externe ;
- contenu embarqué dans le logiciel et consultable depuis l'interface.
Un média temporel peut être diffusé en temps réel ou être proposé en lecture de manière asynchrone (média préenregistré).
Menu et barre de navigation
Liste de composants d'interfaces (liens ou boutons) permettant une navigation spécifique dans l'application, dans une rubrique ou dans une collection d'écrans.
Les principales barres de navigation sont :
- Un menu de navigation ;
- Un fil d'ariane ;
- Une liste de navigation d'une liste de résultats ;
- Des liens d'évitement.
Il existe différents types de menu de navigation :
- Menu de navigation principal ;
- Menu de sous-rubrique ;
- Menu contextuel ;
- Table des matières concernant un ensemble de pages.
N
Nom, rôle, valeur, paramétrage et changements d'état
Un composant doit avoir un rôle et un nom appropriés, ses valeurs, états et paramètres éventuels doivent également être accessibles et correctement transmis aux API d'accessibilité.
Le nom peut être l'intitulé du composant comme l'intitulé d'un bouton par exemple.
La valeur est, par exemple, l'élément sélectionné d'une liste déroulante ou la valeur actuelle d'un curseur.
Le rôle correspond au type d'élément défini dans la spécification de la technologie employée. Le rôle (bouton, lien, champ de saisie par exemple) est généralement restitué par les technologies d'assistance.
Le paramétrage correspond aux informations particulières d'un composant. Par exemple un paramètre qui transmet aux API l'information que le composant contrôle tel ou tel contenu.
Les changements d'état doivent également être mis à disposition. Par exemple, l'utilisation d'une propriété permettant de signaler aux API que le composant est « ouvert » ou « fermé ». Note : un état peut également être transmis via le nom, lorsque l'intitulé est changé dynamiquement pour correspondre à l'état de la zone contrôlée notamment.
Ces paramètres ne sont pas obligatoires, mais peuvent être requis s'ils sont indispensables pour rendre le composant accessible. C'est à l'auditeur de considérer les cas où ces paramètres sont indispensables en fonction du contexte lié à l'utilisation du composant.
L'auditeur doit également vérifier que, lorsqu'ils sont présents, ces paramètres sont correctement utilisés.
O
Ordre de tabulation
Ordre dans lequel le focus se déplace (vers un élément suivant ou vers un élément précédent). L'ordre naturel est celui qui est implémenté via le code source. Lorsqu'il est modifié, c'est ce nouvel ordre qui fait référence.
Attention : lorsqu'un élément initie un changement dans la page (changement de contexte, gestion de zones cachées, ajout de contenu, gestion de champs de formulaire…), il est nécessaire d'activer l'élément qui initie le changement pour tester la cohérence de l'ordre de tabulation.
P
Prise de focus
La prise de focus est l'état renvoyé par un élément qui reçoit l'attention suite à une action de l'utilisateur. Il y a plusieurs moyens de donner le focus à un élément :
- en activant l'élément par un dispositif de pointage (au toucher sur l'écran) ;
- en atteignant l'élément par une touche d'un clavier externe (tabulation, flèche de direction) ;
- en atteignant l'élément en utilisant un commutateur externe (switch, joystick).
La prise de focus sur environnement mobile doit s'évaluer avec les technologies d'assistance et les paramètres adéquats activés. En effet, le simple fait de connecter un contacteur externe (clavier, switch par exemple) n'est pas suffisant pour que la gestion au clavier soit pleinement fonctionnelle. Ainsi, la visibilité de la prise de focus ne devrait être évaluée que lorsque ces éléments sont activés et paramétrés.
Procédé de rafraîchissement
Technique visant à modifier le contenu d'un ou de plusieurs éléments à l'écran. Le procédé de rafraîchissement peut s'effectuer par rechargement automatique de l'écran ou de manière dynamique sans rechargement de l'écran. L'utilisateur doit pouvoir contrôler chaque procédé de rafraîchissement de manière indépendante.
R
Résumé (de tableau)
Un résumé est un passage de texte associé à un tableau de données complexe. Il permet de donner des informations sur la nature et la structure du tableau afin d'en faciliter l'utilisation par les utilisateurs de technologies d'assistance par exemple.
S
Sous-titres synchronisés (objet multimédia)
Texte des informations audio (paroles d'un personnage, bruit important pour comprendre l'action…) présentes dans un média temporel et affiché de manière synchrone avec le flux de l'objet multimédia.
Note 1 : pour différencier les sources sonores (différents personnages, voix off…), il est recommandé d'utiliser un mécanisme approprié (mise entre crochets, mise en italique, annonce explicite du type « voix off : … »).
Note 2 : il ne faut pas confondre le sous-titrage pour la traduction et le sous-titrage pour sourds et malentendants. Ces deux types de sous-titrages poursuivent différents buts. Seule la présence et la pertinence d'un sous-titrage pour sourds et malentendants permet d'être conforme.
T
Tableau de données
élément permettant de structurer des informations en lignes et en colonnes via des cellules de données et des cellules d'en-têtes.
Tableau de données complexe
Lorsqu'un tableau de données contient des en-têtes qui ne sont pas répartis uniquement sur la première ligne et/ou la première colonne de la grille ou dont la portée n'est pas valable pour l'ensemble de la colonne ou de la ligne, on parle de tableau de données complexe. Il est alors nécessaire de fournir un « résumé » permettant d'en expliquer sa nature et sa structure afin d'en faciliter la consultation pour des utilisateurs de technologies d'assistance par exemple.
Taille du texte (centre de contrôle)
L'ajout du bouton « Taille du texte » au centre de contrôle se fait en accédant à Réglages → Centre de contrôle, puis en choisissant « Taille du texte ».
Titre d'écran
Le titre d'écran est le premier élément vocalisé ou vu sur un écran mobile. Il a vocation à faciliter la navigation, de tous, en informant l'utilisateur, à tout moment, de sa position dans l'application.
Note : Une erreur courante est de mettre un titre unique pour toutes les pages d'une application, voire aucun titre du tout.
Titre de section
Passage de texte permettant de structurer l'information du contenu de l'écran.
Titre d'un tableau (de données)
Texte relié au tableau qui permet d'identifier le contenu d'un tableau de données de manière claire et concise.
Transcription textuelle (média temporel)
Contenu textuel associé à un média temporel par la technique appropriée (texte présent dans l'interface ou dans un fichier texte qui se trouve dans le même écran ou consultable grâce à un bouton). Ce contenu donne accès à l'utilisateur (de manière indépendante de la consultation de l'objet multimédia) à :
- La totalité de ce qui y est exprimé oralement.
- Toutes les informations descriptives nécessaires à une compréhension équivalente de l'action.
Ces informations textuelles doivent être présentées dans l'ordre chronologique de leur apparition dans le média temporel.
V
Version accessible (pour un document en téléchargement)
Les documents en téléchargement dont les types de format sont reconnus compatibles avec l'accessibilité doivent être rendus accessibles soit directement, soit par l'intermédiaire d'une version accessible ou d'une version en HTML. Les formats de document dont la compatibilité est reconnue sont :
- Microsoft Office (Word 2003, OOXML) ;
- Open Office Org (ODF) ;
- Adobe PDF ;
- Epub/Daisy.
Note : le format txt ne peut pas être utilisé pour produire une version accessible pour un document en téléchargement.
Version alternative « audio seulement »
Une version « audio seulement » est une version sonore, sous la forme d'un simple fichier au format MP3 par exemple, utilisée comme alternative à une vidéo seulement (vidéo sans information sonore). Les seuls utilisateurs impactés par l'accessibilité étant les personnes aveugles, qui ne peuvent pas voir la vidéo, WCAG considère comme acceptable de proposer en alternative une version sonore.
La version « audio seulement » doit contenir toutes les informations visuelles importantes de la vidéo.
Généralement il est plus simple de produire une version sonore qu'une version textuelle lorsque la vidéo est très descriptive (la transcription textuelle nécessitant souvent un travail rédactionnel important). Il est rappelé, néanmoins, que seule la transcription textuelle assure un accès universel aux informations diffusées par la vidéo, dans le cas où un utilisateur ne serait pas en capacité de lancer la vidéo par exemple.
Environnement de test
Les systèmes d'exploitation retenus sont Android et iOS et les navigateurs Chrome et Safari. Il appartient à l'auditeur de définir, en concertation avec les responsables de l'application auditée, les versions de système d'exploitation et de navigateur en adéquation avec le contexte d'usage du site et l'environnement de test utilisé lors du développement de l'application. Les versions des technologies d'assistance à utiliser seront soit la dernière disponible en langue française sur le système d'exploitation retenu, soit la version précédente.
Environnement de test iOS
- Système : iOS (dernière version)
- Technologie d'assistance : VoiceOver (dernière version)
- Navigateur internet : Safari (dernière version)
Environnement de test Android
- Système : Android (dernière version)
- Technologie d'assistance : Talkback (dernière version)
- Navigateur internet : Chrome (dernière version)
Autres environnements
Des outils complémentaires de développement ou d'aide à l'inspection peuvent être utiles telles que :
- Xcode Accessibility Inspector sur Mac OS
- Android Studio sur Windows ou Mac OS
- SCRCPY (Screen Copy) sur Windows ou Mac OS
- Vysor sur Windows ou Mac OS
- Colour Contrast Analyser sur Windows ou Mac OS
- Google Accessibility Scanner sur Android
Références documentaires
Le RGAA a été établi grâce à une multitude de références et de sources documentaires. Ce document liste les références utilisées.
Documents de références
- RGAA 4.1 - référence à la date de décembre 2020
- WCAG 2.1 - référence à la date de juin 2018
- Mobile Accessibility at W3C - référence à la date de mai 2021
- RAAM1 du Gouvernement du Grand-Duché de Luxembourg - référence à la date de juin 2021
Autres documents
- La va11ydette d'Orange
- Accessibility | Material Design 3
- Components | Material Design 3
- Accessibility modifiers | Apple Developer Documentation
- All components | Apple Developer Documentation
- Patterns | Apple Developer Documentation
- iOS Accessibility in SwiftUI Tutorial Part 1: Getting Started
- iOS Accessibility in SwiftUI Tutorial Part 2: Organizing
- iOS Accessibility in SwiftUI Tutorial Part 3: Adapting
- Android Accessibility by Tutorials
- Créer des applications accessibles | Android Developers
Licence
Ce document est placé sous licence ouverte 2.0 ou ultérieure.