Co-auteur : Jessie Huff

L'empathie vous mènera presque toujours plus loin dans n'importe quelle entreprise, et l'expérience utilisateur n'est pas différente. Comprendre comment nos utilisateurs interagissent avec notre logiciel et quels outils ils utilisent nous donne un aperçu de la façon de mieux les aider. Certains d'entre nous ont l'habitude de consulter un site, de parcourir les titres, de faire défiler jusqu'à la partie souhaitée et de cliquer pour interagir avec les éléments de la page.

Si j'ai une déficience motrice, je peux utiliser un clavier pour interagir avec une page pour accéder à cet élément au lieu d'une souris. Je peux parcourir la page ou utiliser des raccourcis clavier pour obtenir rapidement les informations dont j'ai besoin. Je pourrais même être le type d'utilisateur qui va et vient entre les outils en fonction de mes besoins. Ou si je suis un utilisateur aveugle, je peux utiliser un lecteur d'écran pour m'aider à naviguer sur une page. Je peux utiliser les menus du lecteur d'écran pour obtenir rapidement les principales catégories de la page, telles que les titres, les points de repère, les contrôles de formulaire ou les liens. (Cependant, il est important de noter qu'il existe des tonnes de types d'utilisateurs qui correspondent à ces catégories, à toutes les catégories et à d'autres catégories que nous ne mentionnerons pas.) Ainsi, lorsque nous envisageons ces expériences, nous devons comprendre comment ces outils interagir avec un site Web.

Structuration de l'accessibilité

Le tout-puissant DOM, Document Object Model, est extrêmement important en matière de technologie d'assistance. Le clavier et le lecteur d'écran s'appuieront sur le DOM pour naviguer et interpréter ce qui se passe sur une page. Il traduit le contenu d'un document HTML en un objet standardisé auquel les langages de programmation fonctionnels comme JavaScript peuvent facilement accéder et modifier. Toutes les pages Web dynamiques reposent sur le DOM pour s'afficher et fonctionner correctement.

Chaque page Web a une structure que vous pouvez voir en utilisant l'outil d'inspection :

Le DOM ou la structure est ce qui sera utilisé par les technologies d'assistance pour interpréter ce qui se passe sur la page. Les technologies d'assistance telles que les lecteurs d'écran passeront par le DOM et essaieront d'interpréter les éléments utilisés, l'ordre de ces éléments et ce que ces éléments sont censés faire.

Disons que nous avons une interface utilisateur où vous pouvez ajouter du contenu - peut-être même des blogs comme celui-ci ! Sur cette page, nous avons un bouton flottant "ajouter" afin que les utilisateurs puissent facilement ajouter du contenu où qu'ils se trouvent sur la page. Eh bien, cela semble être un concept sympa, non ?

Supposons maintenant que j'utilise un clavier ou un lecteur d'écran. Je suis arrivé sur cette page, je suis prêt à ajouter ma voix à la conversation, et je cherche le bouton d'ajout. La façon dont le développeur a balisé ce code dans le DOM affectera tout. De nombreux développeurs afficheront le bouton en bas du DOM et repositionneront simplement visuellement l'élément pour donner l'impression qu'il flotte et vous suit lorsque vous faites défiler la page. Cependant, il est toujours au bas du DOM tout le temps.

Donc, en tant qu'utilisateur de clavier ou de lecteur d'écran, je navigue dans la page et, assez étrangement, je ne trouve pas le bouton d'ajout. Je vois des liens vers un article de blog après un article de blog sur la page principale, mais aucun endroit où je peux ajouter mon propre article de blog. Je commence à me demander si ce site ne permet pas réellement aux utilisateurs de publier leur contenu et si leur publicité était erronée. Cela fait quelques minutes que je parcours la page, et je me sens déjà ennuyé.

Ah, enfin, j'ai enfin trouvé le bouton d'ajout. Pourquoi diable ont-ils mis le bouton Ajouter tout en bas de la page ? Voulaient-ils vraiment me rendre fou et me faire travailler si dur juste pour contribuer ? La réponse honnête est que l'équipe n'avait probablement aucune idée de la difficulté à créer son interface utilisateur pour un bon pourcentage d'utilisateurs. Ils ont probablement vu le bouton flottant et pensé, "wow, ça a l'air cool" et ne se sont jamais vraiment assis et ont réfléchi à ces différents types d'expériences.

Nous voyons le monde à travers notre propre objectif, ce qui rend parfois difficile de réaliser que l'objectif de quelqu'un d'autre pourrait être totalement différent. Il n'est pas facile de réfléchir à chaque expérience, mais nous devrions certainement essayer d'en savoir plus sur les différents utilisateurs et leurs expériences. Sinon, nous pourrions manquer d'aider nos formidables clients, sans compter que nous avons la capacité de leur rendre la vie beaucoup plus difficile si nous ne le faisons pas. Ainsi, lorsqu'un autre designer vient vers vous avec une idée super cool, nouvelle et époustouflante, arrêtez-vous et réfléchissez à la manière dont différents types d'utilisateurs interagiraient avec lui. Si vous allez avoir un bouton "Ajouter" sur votre page, où dans le flux est-il le plus logique pour les utilisateurs de le découvrir ? Si vous êtes développeur, posez des questions au concepteur sur ces différentes interactions utilisateur. Tout le monde devrait être sur la même page en ce qui concerne les interactions attendues.

Maintenant que nous en comprenons un peu plus sur les différents types d'expériences utilisateur et sur l'importance de l'ordre de vos éléments, discutons plus en détail des détails techniques.

Approches de PatternFly pour ajouter au DOM

Lorsque vous utilisez un système de conception comme PatternFly, les possibilités sont presque infinies en termes d'interactions que vous pouvez créer. Certaines de ces possibilités peuvent être plus avantageuses que d'autres, et certaines peuvent créer des problèmes inattendus pour les utilisateurs. C'est pourquoi il est important de considérer les implications de votre approche de ces interactions.

Avant de passer en revue les approches de PatternFly, commençons par un bref aperçu de la propriété menuAppendTo React utilisée dans plusieurs composants PatternFly. Alors que ce qui est réellement ajouté peut dépendre du composant - sur une liste déroulante, seul un menu déroulant ouvert sera ajouté plutôt que la bascule, tandis qu'un modal entier serait ajouté - la propriété fait essentiellement la même chose : elle ajoute le composant au spécifié conteneur dans le DOM.

Avec la propriété menuAppendTo, il y a de la place pour ajouter un composant n'importe où dans le DOM, mais tout se résume à deux types d'ajout de base : un ordre DOM "non naturel" et un ordre DOM plus naturel.

Un ordre DOM "non naturel"

Un ordre DOM non naturel fait référence au moment où la place d'un élément dans le DOM ne correspond pas à son ordre de tabulation visuel ou attendu. L'exemple le plus courant consiste à ajouter du contenu rendu dynamiquement au corps du document. Certains composants PatternFly qui peuvent souvent être ajoutés au corps du document sont des composants de type liste déroulante tels que la liste déroulante ou la sélection, les info-bulles et les modaux, pour n'en nommer que quelques-uns.

Ajouter des choses dans un ordre DOM moins naturel peut certainement avoir sa place. Lors du rendu d'un modal, l'ajout au corps du document peut avoir du sens car il devrait être la seule chose qui peut recevoir le focus ou interagir avec les utilisateurs, de sorte que l'inconvénient habituel d'un ordre DOM non naturel ne s'applique pas nécessairement. Un composant comme une info-bulle pourrait être un autre cas où un ordre DOM non naturel a du sens puisque le contenu de l'info-bulle lui-même ne recevra jamais le focus (bien qu'il doive toujours être transmis aux utilisateurs de technologies d'assistance telles que les lecteurs d'écran). De même, les alertes toast qui "apparaissent" visuellement dans le coin supérieur droit de la page peuvent être ajoutées "de manière non naturelle" s'il n'y a pas de contenu interactif dans les alertes, comme des liens vers plus d'informations ou des boutons pour ignorer l'alerte.

Lorsque vous commencez à avoir une imbrication plus complexe de composants, comme une liste déroulante à l'intérieur d'un assistant à l'intérieur d'un modal, l'ajout de la liste déroulante au corps du document ou à la modale peut même aider à garantir que le menu déroulant apparaît au-dessus de tout autre contenu plutôt que d'être couvert. et coupé de rien.

Bien qu'il existe des cas d'utilisation, l'un des inconvénients de cette approche est qu'elle peut rendre les choses moins accessibles pour les utilisateurs qui naviguent et interagissent via le clavier ou les technologies d'assistance.

Si une bascule déroulante est rendue au milieu du DOM, alors que le menu déroulant est ajouté au corps du document, l'ordre de tabulation attendu et l'ordre de tabulation réel ne correspondront pas. Selon le nombre d'autres éléments focalisables entre la bascule et le menu dans le DOM, au lieu d'appuyer une fois sur la touche Tab pour accéder au menu déroulant, vous devrez peut-être appuyer dessus un nombre inconnu de fois, naviguant dans tout le reste de la page avant d'avoir finalement le focus placé à l'intérieur du menu déroulant.

De même, si vous fermez un menu déroulant via la touche Échap, vous pouvez vous attendre à ce que le fait d'appuyer sur Tab place le focus sur le prochain élément pouvant être sélectionné après la bascule de la liste déroulante. Ce qui reçoit réellement le focus est le prochain élément valide à partir duquel le menu déroulant a été ajouté à la fin du corps du document. S'il n'y a pas d'autres éléments focalisables, vous finirez par tabuler en haut de la fenêtre du navigateur.

Un autre inconvénient de cette approche est qu'elle peut obliger le consommateur à mettre en œuvre une gestion de la concentration pour éviter ces problèmes, en supposant que le composant ne le gère pas pour vous (ce qui ne sera pas immédiatement apparent).

Pourquoi un composant peut ne pas gérer la gestion du focus

Certains composants ont des cas d'utilisation et des interactions très simples. Un bouton, par exemple, sera généralement simplement quelque chose sur lequel vous cliquez et quelque chose se passe en réponse à ce clic.

Cependant, d'autres composants peuvent ne pas être aussi simples et les cas d'utilisation peuvent différer énormément selon qui les utilise et le contexte dans lequel ils sont utilisés. Bien que la mise en œuvre de la gestion du focus, ou d'une autre fonctionnalité, dans le composant lui-même puisse être utile pour le cas d'utilisation d'une personne, cela peut causer des problèmes ou être une expérience indésirable pour le cas d'utilisation de quelqu'un d'autre.

Un ordre DOM plus naturel

En ajoutant des composants dans le DOM d'une manière qui correspond mieux à leur ordre de tabulation visuel ou attendu, vous pouvez complètement éviter certains des problèmes lors de l'ajout dans un ordre DOM moins naturel.

En utilisant notre scénario déroulant de la section précédente, si un menu déroulant est visuellement "après" une bascule déroulante et que le menu doit recevoir le focus immédiatement après la bascule, alors le menu doit être ajouté de sorte qu'il vienne après la bascule dans le DOM, ou le plus près possible de celui-ci. Le principal avantage de cette approche est d'éviter d'avoir des éléments non liés et perceptibles entre deux éléments liés qui devraient recevoir l'attention après ou avant l'autre.

Un inconvénient de cette approche est qu'il peut encore y avoir une gestion de la mise au point à mettre en œuvre par le consommateur ou le composant lui-même, garantissant principalement que tout élément qui a déclenché le rendu dynamique du contenu recevra la mise au point une fois que ce contenu ne sera plus visible. Cependant, il s'agit d'une gestion du focus qui devrait être implémentée quel que soit l'endroit où vous ajoutez un composant.

L'avantage de cette approche - autre que l'amélioration de l'accessibilité - est que vous n'avez pas à vous soucier de la mise en œuvre d'une gestion beaucoup plus ciblée, car elle devrait être prise en charge par l'ordre DOM. Vous n'avez pas non plus à déterminer si le composant gère cette fonctionnalité pour vous ou s'il ne la gère que partiellement pour votre cas d'utilisation.

Recommandation de PatternFly pour menuAppendTo

La recommandation suivante est basée sur la v4 de PatternFly. Cependant, avec plus de composants composables introduits dans la prochaine v5 en 2023, dont certains conservent toujours la fonctionnalité menuAppendTo, la recommandation s'appliquerait toujours.

Dans la plupart des situations, PatternFly recommande l'approche de l'ordre DOM naturel. Pour plusieurs composants, cela peut être réalisé en passant un accessoire React "menuAppendTo" avec une valeur de "parent". Pour un contrôle plus précis de l'endroit où le contenu est ajouté, vous pouvez également transmettre une fonction qui renvoie un sélecteur de requête, bien que vous deviez toujours ajouter le plus près possible d'un ordre DOM naturel lorsque vous le faites.

Pour les situations où un ordre DOM naturel n'est pas aussi important - comme les modaux - ou où essayer de gérer le z-index ou le contexte d'empilement n'est pas facilement gérable - comme l'imbrication complexe de composants - l'approche de l'ordre DOM non naturel peut certainement être plus utile. Cette approche peut être réalisée en transmettant une fonction qui renvoie "document.body" ou un sélecteur de requête à la prop React "menuAppendTo". Idéalement, cela devrait être un dernier recours, surtout s'il est plus logique d'ajouter un élément à un endroit plus spécifique du DOM.

Tout comme l'accessibilité elle-même, il n'y a pas toujours une solution unique qui fonctionne pour chaque situation et résout chaque problème pour tout le monde. La recommandation de PatternFly n'est peut-être pas toujours le meilleur choix pour votre situation spécifique, mais il est important de comprendre les implications de l'approche que vous adoptez.

Vous avez une histoire à vous ? Écrivez avec nous ! Notre communauté se nourrit de voix diverses - écoutons la vôtre.