9. Consultation

9.1 L'utilisateur a le contrôle de chaque limite de temps modifiant le contenu (hors cas particuliers).

9.1.1

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

Méthodologie du test 9.1.1

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

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

9.2.1

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

Méthodologie du test 9.2.1

iOS et Android
  1. 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 ;
  2. 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.
  3. 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.

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
  1. Retrouver à l'écran les fichiers en téléchargement au format bureautique accompagné de leur version alternative accessible ;
  2. 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 ;
  3. 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.

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
  1. Repérer dans l'écran les contenus clignotants ou qui provoquent des effets de flash : élément graphique animé, vidéo ou animation, effet de mise en forme.
  2. Vérifier :
    • que la fréquence de l'effet est inférieure à 3 flashs par seconde ;
    • ou que la surface cumulée est inférieure à 21824 pixels.
  3. Si c'est le cas, le critère est validé.

Note :

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

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
  1. Repérer dans l'écran les contenus en mouvement ou clignotants (un élément graphique, un effet de mise en forme, un carrousel par exemple) déclenchés automatiquement au chargement de l'écran ou lors de l'affichage d'un contenu (cf. note).
  2. Vérifier :
    • que la durée totale du mouvement ou du clignotement est inférieure à 5 secondes ;
    • ou la présence d'un mécanisme (un bouton par exemple) qui permet d'arrêter et de relancer le mouvement ou le clignotement ;
    • ou la présence d'un mécanisme (un bouton par exemple) qui permet de cacher et d'afficher à nouveau le contenu en mouvement ou clignotant ;
    • ou la présence d'un mécanisme (un bouton par exemple) qui permet d'afficher le contenu sans mouvement ou clignotement.
  3. Si c'est le cas, le critère est validé.


Note :

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


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

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
  1. Ouvrir le Centre de contrôle.
  2. Vérifier que l'orientation de l'écran n'est pas verrouillée dans les paramètres du système (voir la documentation officielle).
  3. Afficher l'application et basculer le terminal alternativement en mode paysage et portrait.
  4. Vérifier :
    • que l'application est utilisable dans les deux orientations, c'est-à-dire que les éléments de l'application sont repositionnés pour être lisibles ;
    • que les contenus disponibles dans une orientation sont toujours disponibles dans l'autre orientation (directement ou par l'activation d'un composant supplémentaire par exemple).
  5. Si c'est le cas, le critère est validé.

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


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

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
  1. Repérer dans l'écran les fonctionnalités qui nécessitent de réaliser des gestes complexes (repérer la présence de consignes dans l'interface ou dans une documentation associée à l'application), par exemple :
    • l'utilisation simultanée de deux doigts ou plus ;
    • la réalisation d'un tracé de trajectoire (comme le geste swipe).
  2. Vérifier qu'il existe une méthode alternative pour réaliser l'action associée avec un geste simple, par exemple, l'appui sur une seule touche du clavier ou un bouton.
  3. Si c'est le cas, le critère est validé.


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 :

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

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
  1. Repérer dans l'écran les composants interactifs (par exemple, bouton ou lien).
  2. Pour chaque composant interactif, effectuer un appui simple dessus et conserver la pression.
  3. Déplacer le dispositif de pointage en dehors de la zone interactive et constater que l'action associée n'est pas déclenchée.
  4. Si c'est le cas, le critère est validé


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 :

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

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
  1. Repérer dans l'écran les fonctionnalités qui se déclenchent au moyen d'un mouvement de l'appareil ou d'un geste vers l'appareil (repérer par exemple la présence de consignes dans l'interface ou dans une documentation associée à l'application qui décrivent ce type de déclenchement).
  2. Vérifier :
    • que la fonctionnalité peut être déclenchée sans mouvement, par exemple par l'activation d'un bouton ou d'un lien ;
    • et que l'application propose une méthode pour désactiver la détection du mouvement (par exemple, un paramètre dans l'application).
  3. Si c'est le cas, le critère est validé.

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 :

7.10 Les messages de statut sont correctement restitués.

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

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

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
  1. Repérer dans l'écran les composants interactifs (par exemple, bouton ou lien).
  2. Pour chaque composant interactif, effectuer un appui simple dessus et conserver la pression.
  3. Déplacer le dispositif de pointage en dehors de la zone interactive et constater que l'action associée n'est pas déclenchée.
  4. Si c'est le cas, le critère est validé


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

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
  1. Repérer dans l'écran les fonctionnalités qui se déclenchent au moyen d'un mouvement de l'appareil ou d'un geste vers l'appareil (repérer par exemple la présence de consignes dans l'interface ou dans une documentation associée à l'application qui décrivent ce type de déclenchement).
  2. Vérifier :
    • que la fonctionnalité peut être déclenchée sans mouvement, par exemple par l'activation d'un bouton ou d'un lien ;
    • et que l'application propose une méthode pour désactiver la détection du mouvement (par exemple, un paramètre dans l'application).
  3. Si c'est le cas, le critère est validé.

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 :