Un problème d'accessibilité courant que j'ai remarqué dans les applications Android est l'imbrication d'éléments actifs les uns dans les autres. Je souhaite expliquer, à l'aide d'une démonstration, pourquoi cela nuit à l'accessibilité et quelles personnes cela pourrait concerner. Je vais également vous montrer où repérer ce problème dans les outils de développement, comment le corriger et comment respecter les bonnes pratiques en matière d'accessibilité. N'hésitez pas à suivre la vidéo ci-dessous si vous le souhaitez :
Présentation générale
Dans cet article de blog, nous aborderons les thèmes suivants :
- Imbrication d'éléments dans un seul conteneur pouvant faire l'objet d'un focus
- Quand l'imbrication d'éléments n'est pas une bonne idée
- Quand est-il judicieux d'imbriquer des éléments ?
Pour commencer
Penchons-nous de plus près sur l'accessibilité via TalkBack et sur une infraction courante que je constate concernant les éléments actifs imbriqués dans les applications Android. Nous aborderons les bonnes pratiques et verrons comment Deque a développé une règle permettant d'analyser et de détecter automatiquement ce problème. Commençons : j'ai ici un émulateur. L'un des aspects intéressants de l'écosystème d'accessibilité Android, c'est que les émulateurs fonctionnent pratiquement exactement comme les appareils.
Je présente cet exemple sur un émulateur, car c’est un peu plus pratique pour une démonstration. Pour commencer, vous verrez qu’une notification contextuelle s’affiche en bas de l’écran, indiquant « interrupteur de blocage ». C’est le texte qui serait lu à voix haute par TalkBack si j’avais l’appareil en main. À présent, je passe d’un commutateur à l’autre. Si je sors de ce commutateur et que je clique ici en utilisant le geste « toucher pour explorer », je sélectionne une autre vue qui regroupe ces deux commutateurs. C’est justement ce problème fondamental dont je souhaite parler.
Pourquoi l'imbrication d'éléments actifs est-elle néfaste ?
Lorsque des éléments sont imbriqués les uns dans les autres, il devient très difficile de comprendre ce que l’on cherche à faire en tant qu’utilisateur d’un lecteur d’écran. Imaginez que vous soyez aveugle et que vous parcouriez cette application en utilisant les différents moyens de navigation à votre disposition. Par exemple, si j’utilise la navigation tactile, je tombe sur des éléments imbriqués les uns dans les autres. Cela prête à confusion, car lorsque je fais glisser mon doigt sur l’écran, je peux finir par toucher plusieurs cibles tactiles au sein d’une même cible. L’autre problème qui se pose dans ce cas concerne la navigation à l’aide des onglets.
Ma navigation par tabulation et ma navigation par glissement finissent en réalité par être différentes, car certains éléments sont sélectionnables, tandis que d’autres sont sélectionnables dans le cadre de l’accessibilité. Ma navigation par glissement et ma navigation au clavier correspondent à des types de cibles tactiles différents. Lorsque j’appuie sur la flèche droite, cela déclenche des actions différentes de celles qui se produisent lorsque j’appuie sur la touche Tab.
Pour résoudre ce problème, nous devons a) être en mesure d’identifier ce dysfonctionnement et b) comprendre exactement pourquoi il se produit. Qu’est-ce qui est à l’origine de ces cibles tactiles multiples ? Quels autres problèmes pourrions-nous rencontrer en dehors du focus TalkBack ? C’est en examinant ces questions que nous comprenons le cœur du problème.
Correction des éléments actifs imbriqués inaccessibles
Voyons maintenant comment utiliser les outils d’accessibilité pour identifier ce problème. Remarquez que je partage ici un écran sur lequel je peux afficher le focus et, en faisant défiler la capture d’écran, je vois les différentes zones de focus d’accessibilité. Si vous ouvrez les outils de développement, vous pouvez commencer à analyser ces contrôles. Examinons de plus près les propriétés d’accessibilité de l’un de ces contrôles : il y a plusieurs boutons dans une disposition linéaire. Lorsque nous passons la souris sur ces boutons, nous avons :
- importantPourL'Accessibilité = true
- clickable = true
Nous avons ici deux vues sur lesquelles on peut cliquer : ces deux boutons sont cliquables, tout comme la mise en page linéaire. Ils sont tous cliquables et peuvent recevoir le focus, et c’est précisément pour cette raison qu’ils sont pris en compte dans le cadre de l’accessibilité. Lorsque nous examinons le texte, nous constatons que le texte est masqué, mais que les propriétés « focusable » et « clickable » sont définies sur « true ». Cela prête à confusion au regard de ce dont nous avons parlé plus haut, car non seulement nous allons vouloir essayer d’activer l’un de ces contrôles, mais en plus, lorsque nous plaçons le focus sur ce grand rectangle, nous l’activons.
Conséquences de l'imbrication d'éléments actifs
Mais que signifie exactement « activer un ensemble d’éléments » ? C’est un concept qui prête à confusion, et comme vous pouvez le voir, nous avons mis en évidence cette situation d’inaccessibilité dans la démo ci-contre, mais ce phénomène peut en réalité se produire dans de nombreux contextes différents. Je constate notamment ce problème dans certaines bibliothèques hybrides qui peuvent s’appuyer sur une vue Web. Lorsque la vue Web devient cliquable et contient également d’autres éléments cliquables, la situation est très déroutante pour un utilisateur de TalkBack qui entend qu’il peut interagir avec un élément qui est lui-même composé d’autres éléments interactifs.
Un autre cas où cela pose des problèmes d’accessibilité concerne la commande par commutateur. Si vous utilisez ce type de commande et que vous parcourez les éléments actifs à l’écran, vous vous retrouvez au minimum avec une cible superflue, ce qui est frustrant si votre balayage comporte un délai d’une seconde. Parallèlement, vous risquez d’activer par inadvertance un élément que vous ne souhaitiez pas activer ou dont le comportement est indéfini. Ce que nous voulons faire, c’est intervenir pour rendre cet élément inactivable. Dans ce cas précis, la solution consisterait à rendre ce contour non sélectionnable.
Bonnes pratiques
Pourquoi cette application hybride intègre-t-elle une vue Web et est-elle cliquable, pour commencer ? Nous ne voulons absolument pas que cet élément soit cliquable. Il s’agit ici d’une correction similaire : nous avons un contrôle informatif et un élément informatif. Les propriétés « clickable » et « focusable » sont définies sur « false », ce qui est parfait. Nous avons ici un commutateur qui va être cliquable et pouvant recevoir le focus, ainsi qu’une disposition linéaire qui est cliquable et pouvant recevoir le focus. Nous avons également défini une taille de cible tactile suffisamment grande pour cet élément. Cependant, nous n’avons tout simplement plus besoin d’interagir avec ce commutateur, n’est-ce pas ? Dans TalkBack, lorsque j’essaie de cliquer sur ces éléments, je clique sur le contrôle mineur, c’est-à-dire le contrôle informatif, et je ne peux pas lui attribuer le focus individuellement, mais je peux attribuer le focus individuellement au commutateur TalkBack.
C'est une bonne pratique, car je dispose d'une grande zone tactile ; en gros, cela revient à dire : « Tiens, toutes les fonctionnalités que tu peux obtenir en rendant cette mise en page linéaire interactive sont regroupées dans ce contrôle ». Nous allons maintenant examiner un bon exemple illustrant ce principe, dans lequel nous avons cette action de passage. Cet exemple de passage devrait indiquer : « Toutes les informations sont disponibles sur ce bouton », ou, idéalement, nous pourrions regrouper toutes ces informations en un seul élément. Dans l’exemple présenté ici, nous pourrions dire : « Toutes les informations transmises par ce bouton sont disponibles dans ce rectangle », puis proposer l’action du bouton sur cette grande mise en page.
Cela permet d'obtenir une grande zone tactile pratique sans même avoir à mettre en focus les contrôles individuellement, ce qui constitue une bonne pratique. Dans notre cas, c'est un peu plus fastidieux à coder dans l'émulateur ; nous avons opté pour la version la plus simple, qui consiste à associer les deux à une étiquette. De cette façon, dans le contrôle « switch », vous ne mettez en focus que le « switch ». Dans TalkBack, vous pouvez accéder aux deux contrôles individuellement ; c'est la manière la plus simple de le coder. Au final, nous finissons par associer ces deux éléments à l’attribut « for », mais si vous souhaitez aller plus loin, vous pouvez regrouper ces deux éléments en une seule cible accessible.
Conclusion
L'imbrication d'éléments peut offrir une expérience utilisateur plus fluide. Elle limite le nombre total de cibles pouvant recevoir le focus à l'écran pour les utilisateurs de lecteurs d'écran, ce qui est une bonne chose. Cependant, si deux éléments permettent d'effectuer une action, ils DOIVENT être distincts. Même si chaque cible finit par recevoir son propre focus, l'imbrication d'éléments actifs au sein d'une seule cible prête à confusion et entraîne un comportement indéfini si un utilisateur tente d'activer une telle cible. De plus, l’imbrication excessive de contrôles informatifs peut entraîner des annonces trop longues et nuire à la clarté structurelle de votre application. Veillez à ce que les contrôles distincts restent séparés et n’imbriquez des éléments que lorsque vous avez besoin de créer des relations entre des groupes de contrôles. Enfin, n’imbriquez qu’un seul contrôle actif dans chaque groupe pouvant recevoir le focus.
