Catégories
Astuces et Design

Nous avons besoin de mesures de performances Web plus inclusives

Ces derniers temps, le monde de l’outillage de performance Web a connu une grande dynamique et notre capacité à identifier et à corriger les goulots d’étranglement qui affectent les utilisateurs réels n’a jamais été aussi bonne. Peut-être que le résultat le plus important de cet élan a été d'identifier les mesures de chargement de page particulières qui importent le plus aux utilisateurs réels. Parmi celles-ci, les mesures «perçues» par l'utilisateur comme First Contentful Paint et Largest Contentful Paint — des mesures qui marquent des moments significatifs dans l'expérience de chargement de page visuelle lorsque le contenu est visible (mais pas encore interactif) et peut être digéré par les utilisateurs – obtenez un excellent beaucoup d'attention.

Ces mesures sont souvent présentées comme des mesures de convivialité ou de sens, mais elles ne sont pas nécessairement significatives pour tout le monde. En particulier, les utilisateurs qui s'appuient sur une technologie d'assistance (comme un lecteur d'écran) peuvent ne pas percevoir les étapes du processus de chargement de page tant que le DOM n'est pas terminé, ni même plus tard selon la façon dont JavaScript peut bloquer ce processus. De plus, une page peut ne pas être utilisable par A.T. jusqu'à ce qu'il devienne entièrement interactif, car de nombreuses applications offrent souvent une interactivité accessible via JavaScript externe. Comme d'autres domaines de performance, la livraison et l'application JavaScript peuvent jouer un rôle important dans la rapidité avec laquelle une page devient accessible, et Marcy Sutton a fait un excellent travail pour faire la lumière sur les impacts de cette relation (voir Comment React.js impacte l'accessibilité et l'accessibilité et Performance et une discussion fascinante liée à partir de ce dernier post sur le calendrier de l'arbre d'accessibilité). Pourtant, aussi bien que cette intersection puisse être comprise, ces métriques de synchronisation ne sont généralement pas exposées dans nos outils de performance Web. Comme l'a tweeté Léonie Watson, "Il serait bon que les outils de performance puissent mesurer le temps de création de l'arborescence d'accessibilité et / ou le temps de la première requête d'API d'accessibilité".

Dans notre effort continu pour des pratiques qui produisent des expériences inclusives et accessibles par défaut, nous avons également besoin que nos mesures de performance soient inclusives.

Quelques réflexions sur ce que cela pourrait ressembler:

  • Il serait utile d'avoir un aperçu du moment où la technologie d'assistance est en mesure d'interagir avec et de communiquer le contenu de la page, afin que nous puissions savoir quand une page est «prête» pour tous les utilisateurs, et pas seulement pour certains. Si possible, cette mesure pourrait prendre en compte les mesures existantes qui représentent déjà la «disponibilité» de la page, plutôt que de simplement ajouter une nouvelle mesure «accessible-prête». En d'autres termes, si la page n'est pas encore prête pour tout le monde, elle n'est pas encore prête.
  • Il serait intéressant de savoir quelles mesures existantes ne sont pas pertinentes pour les technologies d'assistance, par exemple, si une mesure particulière se produit avant que l'arborescence d'accessibilité ne soit exposée.
  • Je me demande également s'il pourrait être intéressant de mesurer «jank» et la stabilité dans le processus pour arriver à un arbre d'accessibilité utilisable. Par exemple, dans un scénario react / vue / etc rendu côté serveur, l'arborescence d'accessibilité est-elle initialement créée dans un sens puis «hydratée» dans un état très différent? Dans l'affirmative, cela revient-il à dire que les mesures de stabilité de la mise en page que nous suivons déjà, qui perturbent l'expérience visuelle de l'utilisateur?
  • Enfin, comment les mesures telles que le délai de première entrée se traduisent-elles en temps d'interaction que quelqu'un éprouve lors de l'utilisation de la technologie d'assistance? Une application est-elle incapable de répondre à l'interaction assez rapidement pour communiquer de manière significative ce qui se passe à l'utilisateur?

Nous devrions vouloir savoir si nos modèles sont optimisés pour les cas d'utilisation visuels au détriment des autres, en particulier lorsque bon nombre de ces modèles excellent dans les applications de plus en plus lentes. sembler comme s'ils se chargeaient rapidement, ce qui pourrait peut-être améliorer les performances du monde réel pour beaucoup.

Dans le but d'approfondir cette conversation, j'ai déposé une demande de fonctionnalité pour l'équipe de Lighthouse et également avec WebPageTest pour examen. Plusieurs personnes ayant une connaissance approfondie de ce sujet ont déjà donné leur avis et leur soutien. Si vous pouvez ajouter des informations ou même simplement affirmer que cela ressemble à quelque chose dont nous avons besoin, faites-le!

Voici ces problèmes:

Tous les articles du blog

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *