Cet article a été rédigé conjointement par Chris McMeeking et Jennifer Dailey.
Le contenu évolutif comprend des éléments qui changent en permanence, tels que les horloges et les publicités défilantes. Contrairement aux éléments dynamiques qui ne changent qu’à la suite d’une action de l’utilisateur, les mises à jour des éléments évolutifs ne doivent pas toutes être signalées par VoiceOver. Une mise en œuvre de ce type rendrait l’application plus difficile à parcourir et à utiliser pour les utilisateurs de VoiceOver. Toutefois, cela ne doit pas conduire à ne pas considérer cet élément comme un élément d’accessibilité. Les utilisateurs non voyants doivent recevoir via VoiceOver les mêmes informations que celles que les utilisateurs voyants obtiennent via l’interface utilisateur visuelle.
Le problème de l'horloge
La meilleure façon de mettre en œuvre l’accessibilité pour la mise à jour du contenu variera légèrement d’une situation à l’autre. L’accessibilité doit être suffisante pour que les utilisateurs de VoiceOver sachent sur quel élément se trouve le focus et aient une idée générale de son contenu ; cependant, elle ne doit pas générer un nombre excessif de notifications de VoiceOver au point de nuire à l’ergonomie et au bon fonctionnement de l’application. Imaginons que je souhaite intégrer une horloge affichant l’heure, les minutes et les secondes actuelles. Lorsqu’un utilisateur sélectionne l’horloge, celle-ci ne doit pas annoncer l’heure toutes les secondes, car VoiceOver ne serait pas en mesure de lire intégralement l’heure en une seconde. Le système prendrait très rapidement du retard dans les notifications et transmettrait des informations obsolètes à l’utilisateur. (Ainsi, l’horloge peut afficher 16 h 25 min 45 s, mais VoiceOver indiquera qu’il est 16 h 25 min 42 s.) L’horloge doit être accessible, mais de manière à éviter qu’elle ne transmette des informations obsolètes à VoiceOver.
Publicités défilantes
Les bannières et publicités défilantes posent un défi différent. Dans le cas de l’horloge, nous ne sommes pas nécessairement intéressés par tout le contenu qu’elle a jamais affiché. Si nous manquons une ou deux secondes, ce n’est pas grave ! En revanche, dans le cas des publicités défilantes, il peut y avoir des informations qu’un utilisateur souhaite examiner plus en détail. Que se passe-t-il si, pendant que l’utilisateur écoute l’annonce d’une publicité, la bannière est déjà passée à la suivante ? L’utilisateur peut-il revenir à cette publicité ? Quel retard a-t-il pris ? Pour un utilisateur de VoiceOver, la réponse à ces questions n’est pas forcément simple, et ces cas doivent être traités avec précaution.
Solutions possibles
Veuillez noter que ces solutions ne sont pas forcément optimales dans tous les cas de figure. Comme indiqué précédemment, chaque situation impliquant la mise à jour de contenu est différente ; les solutions permettant de rendre cette mise à jour accessible dépendront donc du contexte. Vous trouverez ci-dessous quelques pistes pour améliorer l'accessibilité de ces éléments.
Repenser l'interface utilisateur
Une solution consiste à envisager de supprimer les informations non essentielles de l'interface utilisateur. Revenons à l'exemple de l'horloge. Les secondes affichées sur une horloge constituent-elles vraiment une information essentielle ? Dans certains cas, oui, et dans ces cas-là, d’autres solutions s’imposent. Cependant, si l’horloge sert uniquement à indiquer l’heure (et n’est pas, par exemple, un chronomètre), on pourrait certainement faire valoir que les secondes ne sont pas nécessaires. Dans ce cas, les supprimer de votre interface utilisateur pourrait être la meilleure solution. Les minutes, quant à elles, ne changent pas assez souvent pour poser un problème avec VoiceOver.
REMARQUE : Il peut être tentant de configurer l'étiquette d'accessibilité de l'horloge de manière à ce que VoiceOver ne lise que les heures et les minutes, en laissant les secondes accessibles aux utilisateurs voyants. Il s'agit là d'un cas où des informations textuelles sont masquées à VoiceOver, ce qui n'est pas conforme aux principes d'accessibilité. Pour respecter les directives WCAG 2.0, toutes les informations doivent être accessibles à
Caractéristique « Mises à jour fréquentes »
Lorsque le trait« UIAccessibilityTraitUpdatesFrequently »est appliqué, VoiceOver effectue des requêtes périodiques pour détecter les mises à jour, au lieu d’annoncer chaque modification. Si un élément est constamment mis à jour et que VoiceOver n’arrive pas à suivre le rythme des mises à jour lorsqu’il est actif, le trait « Updates Frequently » peut s’avérer utile. Il s’agit de la solution privilégiée pour notre exemple d’horloge, si des modifications de l’interface utilisateur ou de l’expérience utilisateur ne sont pas envisageables.
Bouton Marche/Arrêt
Qu'en est-il du problème des publicités défilantes ? Imaginons que je crée une bannière publicitaire qui s'actualise toutes les 10 secondes. VoiceOver se positionne sur la barre de progression et annonce « Barre de progression terminée ». Si l’utilisateur de VoiceOver souhaite lire un long paragraphe, VoiceOver risque, au milieu du paragraphe, de déplacer le focus vers la barre de progression parce qu’elle a terminé un nouveau cycle. Cela rendrait le paragraphe inaccessible aux utilisateurs de VoiceOver. Pour remédier à cela, l’ajout d’un bouton « Démarrer/Arrêter », permettant à l’utilisateur d’interrompre la progression de la barre afin d’accéder à d’autres éléments de la page, pourrait résoudre le problème.
Bonnes pratiques
En cas de doute, il n’y a aucun inconvénient à appliquer le trait «Mises à jour fréquentes ». Si ce trait est appliqué à un élément dont les mises à jour ne sont pas suffisamment fréquentes pour avoir une incidence notable, le comportement restera tout de même raisonnable. En revanche, si l’élément faisant l’objet de mises à jour fréquentes contient du contenu susceptible d’intéresser l’utilisateur, il convient de prévoir un bouton « Pause » ou « Arrêt ». Les applications mobiles ont généralement un objectif très précis, et un contenu mis à jour de manière dynamique peut être source de distraction. Repenser votre interface utilisateur (UI) et votre expérience utilisateur (UX) pourrait s'avérer être la meilleure solution globale.
Merci de votre lecture ! Si vous avez trouvé cet article utile et que vous souhaitez en savoir plus sur l'accessibilité, consultez nos autres tutoriels sur le sujet dans nos articles de blog et sur notre application « Deque University » pour iOS, disponible sur l'App Store !
En savoir plus…
- En savoir plus sur les articles consacrés aux meilleures pratiques de l'université «Deque ».
- Inscrivez-vous à un webinaire sur l'accessibilité mobile.
- Découvrez comment les produits «Deque » peuvent vous aider à garantir l'accessibilité totale de vos applications et sites web.
