Smashing Podcast Épisode 4 Avec Heydon Pickering : Que sont les composants inclusifs ?

Aujourd'hui, je parle à Heydon Pickering de son nouveau livre, Inclusive Components . Heydon est connu pour son travail et ses écrits sur l'accessibilité - alors que signifie réellement "conception inclusive" et où les composants entrent-ils en jeu ? Heydon explique tout cela et plus encore dans cet épisode. Vous pouvez écouter ci-dessous ou vous abonner partout où vous obtenez vos podcasts.

Afficher les remarques

• Le livre Inclusive Components de Smashing Magazine
• Le projet de Heydon Every Layout avec Andy Bell
• Site web de Heydon Heydonworks
• Heydon sur Twitter

Transcription

Drew McLellan : Il est consultant indépendant en accessibilité Web, concepteur d'interface et écrivain. Son travail se concentre sur la conception d'une expérience utilisateur accessible, ainsi que sur la rédaction et l'édition pour Smashing Magazine. Il est l'auteur du livre acclamé sur la conception d'applications Web accessibles, Apps For All, et vient de publier un nouveau livre, Inclusive Components, sur la façon de créer des interfaces Web accessibles, encore une fois, avec Smashing Magazine. Il est donc clairement un expert en matière de design accessible, mais saviez-vous qu'il a été le premier humain de sexe masculin à sauter le pont du port de Sydney dans un hors-bord ? Mes amis Smashing, veuillez accueillir Heydon Pickering. Salut Heydon. Comment vas-tu?

Heydon Pickering : Je suis fracassant. Je suis sur la marque.

Drew : Je voulais vous parler aujourd'hui du sujet de votre nouveau livre, Inclusive Components.

Heydon : Oui.

Drew : Évidemment juste un titre en deux mots, mais j'ai l'impression que chacun de ces mots fait beaucoup de travail. En commençant par la fin, comme il est évidemment logique de le faire, les composants, s'agit-il d'une sorte de conception basée sur les composants ? Qu'est-ce que c'est?

Heydon : Oui, donc je suppose que cela fait un moment maintenant que les gens, les développeurs frontaux, les concepteurs et tous ceux qui collaborent à la création d'interfaces, ont commencé à penser aux choses en termes de composants et à diviser les choses en morceaux digestibles et réutilisables. Et je suppose que si vous n'êtes pas familier avec cette façon de travailler pour une raison quelconque, c'est vraiment un peu comme les composants électroniques. Mon père est ingénieur en électronique. Il travaille dans le genre de monde analogique des circuits imprimés et de la soudure et tout ce genre de choses.

Heydon : En fait, il a fabriqué des composants, de très petits composants, qui ont été utilisés pour réguler le courant entrant dans les électroaimants au CERN. Et il avait beaucoup confiance en moi quand j'étais enfant, parce qu'il m'a fait souder certains des morceaux pour eux. Je pense que ce lot a maintenant été retiré, alors ne vous inquiétez plus de ma mauvaise soudure, ma pauvre soudure d'adolescent, étant plus impliquée dans le CERN. Mais oui, je pense que c'est analogue à… Oh, il y a trop d'analogues là-dedans.

Heydon : C'est analogue aux circuits imprimés analogiques en ce sens que l'idée est que vous avez des responsabilités uniques pour les pièces ou composants individuels et, ensemble, ils font le circuit et, ensemble, ils augmentent le courant dans le cas d'un circuit ou, je suppose, l'interface ou le résultat de quelque manière que ce soit, dans un système de conception ou dans une interface telle qu'elle se manifeste à travers un système de conception. Et donc, Composants inclusifs parce que je voulais aborder le fait que, même si, je veux dire, l'accessibilité a tendance à être généralement laissée pour compte lorsque nous faisons avancer ce que nous faisons dans différents domaines, et je voulais apporter l'accessibilité et, dans un sens plus large sens, conception inclusive pour porter sur ce genre de nouvelle façon de penser et de fabriquer des choses en utilisant des composants ou des modules ou tout ce que vous voulez les appeler.

Heydon : Donc, l'idée était à la fois d'apporter l'accessibilité aux systèmes de conception, mais du même coup, de penser de manière systémique lorsqu'il s'agit d'essayer d'aborder l'accessibilité. Pensez à résoudre un type de problème en un seul endroit en termes d'accessibilité et à vous assurer qu'il se propage simplement autour du modèle [inaudible 00:03:16] du système de conception dans son ensemble.

Drew : D'un point de vue pratique, à quoi cela ressemble-t-il réellement de travailler de manière basée sur les composants ? Que pourrait être un exemple de composant ?

Heydon : Donc, il y a différentes manières de concevoir et de coder des composants. J'ai tendance à entrer directement dans le vif du sujet, au-delà des éléments conceptuels et à réfléchir à la manière dont je pourrais organiser le code. En fait, je me suis beaucoup concentré sur les éléments personnalisés, ou s'il ne s'agit pas d'éléments personnalisés, alors sur des éléments normaux, mais avec une sorte de comportement JavaScript qui leur est attaché d'une manière isolée et composable. J'aime beaucoup l'idée de composants interopérables. Et par là, je veux dire qu'ils peuvent être utilisés dans différents cadres, systèmes, approches et piles techniques. Et les éléments personnalisés sont agréables car ils sont natifs. Vous pouvez les définir en un seul endroit et ensuite ils pourraient être utilisés, par exemple, dans une application de réaction ou ils pourraient être utilisés dans une application de vue ou ils pourraient être utilisés dans une application angulaire, ou n'importe quel type de technologie de gestion d'état plus large que vous êtes en utilisant.

Heydon : Donc, pour moi, un composant sera généralement un élément personnalisé. J'ai récemment travaillé sur un projet qui n'est pas tellement axé sur l'accessibilité, même si j'ai essayé de le rendre aussi accessible que possible, appelé Every Layout, et il s'agit en quelque sorte d'essayer d'isoler des types d'algorithmes très spécifiques pour Mise en page CSS. Et ils sont définis comme des éléments personnalisés et en quelque sorte ils se déploient et exécutent leur propre CSS et fonctionnent comme des primitives similaires au sein du système plus large.

Drew : Je veux dire, en termes pratiques, nous parlons d'un composant qui pourrait être quelque chose comme un champ de formulaire ?

Heydon : Ouais, donc ça pourrait être quelque chose d'aussi simple qu'une entrée. Dites, comme une entrée de texte ou cela pourrait être quelque chose de complexe comme une interface à onglets. Et donc, l'idée avec Inclusive Components était de prendre le concept d'un composant avec son objectif, espérons-le, unique, comme une entrée de texte, puis de penser à toutes les différentes choses qui pourraient faire trébucher différents types de personnes et essayer d'éviter leur. Ne pas éviter les gens, éviter les problèmes. Il ne s'agit pas tant d'inclure les gens, il s'agit d'essayer de ne pas exclure arbitrairement les gens.

Heydon : Cela me semble être la façon la plus simple d'aborder un processus de conception inclusif, c'est en quelque sorte d'identifier les éléments d'exclusion potentiels de quelque chose et d'essayer de les contourner. Ainsi, avec une entrée de texte, avec une étiquette, vous avez un certain nombre de choses différentes dont vous voudrez peut-être vous inquiéter. Ainsi, vous auriez si oui ou non il est correctement étiqueté pour commencer. Utilisez-vous donc un élément d'étiquette et cet élément d'étiquette pointe-t-il vers le champ de texte à l'aide d'un attribut for afin que les deux choses soient associées par programme afin que lorsqu'un utilisateur de lecteur d'écran concentre l'entrée, il entende réellement l'étiquette annoncée ? C'est donc une chose à faire.

Heydon : Ensuite, à un niveau plus visuel, s'assurer que l'étiquette est clairement associée à ce domaine et non à un domaine différent, et c'est une question d'espace blanc et ce genre de choses. De plus, en vous assurant que l'étiquette ne l'est pas, vous ne faites pas quelque chose d'extraordinaire comme mettre l'étiquette sous leur entrée de formulaire, car alors, par exemple, lorsqu'un clavier virtuel apparaît, cela peut devenir obscur. Donc, il prend en considération ce genre de choses.

Heydon : S'assurer que l'entrée elle-même a un style de mise au point, donc lorsque vous la faites la mise au point avec un clavier, que vous soyez un utilisateur habituel du clavier qui utilise des claviers pour naviguer ou autrement, assurez-vous qu'il ressort clairement du style de mise au point que c'est le l'entrée sur laquelle vous vous concentrez. S'assurer que, je veux dire, des choses comme la saisie semi-automatique, s'en soucier, si la saisie semi-automatique est appropriée et utile dans le contexte ou non. Et beaucoup de ces choses traitent directement du handicap, mais beaucoup d'entre elles sont en quelque sorte plus larges en termes de convivialité et rendent simplement les choses aussi compréhensibles que possible.

Heydon : Assez souvent, il y a une sorte de ligne fine ou peut-être une ligne floue entre ce qui concerne la convivialité pour tout le monde et ce qui concerne le handicap. Et puis, pour le rendre encore plus difficile à cerner, les troubles cognitifs. Donc, si quelque chose n'est pas très utilisable pour quelqu'un qui n'a pas de handicap cognitif, alors ça va être encore plus difficile à travailler et à pouvoir utiliser pour quelqu'un qui a ce genre de défis.

Heydon : Donc, il s'agit simplement d'essayer de penser à toutes ces choses au même endroit. Et vraiment, le livre est juste mon, c'est mon processus de pensée alors que j'aborde chacun d'entre eux. Donc je l'ai fait comme un blog pour commencer. Et chaque motif ou chaque composant est un article de blog et le texte est juste moi qui dit : « Alors, abordons maintenant ce problème potentiel. Comment s'y prend-on? D'accord, nous avons coché celui-là. Je pense que nous sommes bien là-bas. Et, en aucun cas, je n'essaie de dire que ceux-ci sont parfaits et que j'ai pensé à tout, car ce n'est pas possible.

Drew : Il en va de même pour l'adoption d'une approche basée sur les composants de la façon dont vous travaillez sur des parties individuelles d'une interface, je suppose, cela vous permet d'aller très loin sur cet élément particulier et de vous assurer que vous l'avez vraiment fortement optimisé de la meilleure façon dont vous peut pour qu'il soit accessible à tous. Y a-t-il un danger à faire cela et à le faire sur de nombreux composants différents, puis à les rassembler tous sur une page ? Existe-t-il un danger que vous puissiez créer des problèmes dont vous n'étiez pas conscient parce que vous les testez individuellement et non ensemble ?

Heydon : C'est un très bon point, et j'allais en parler plus tôt en fait. Je suis content que tu dises ça. Donc, à bien des égards, je pense que nous avons, philosophiquement, décidé que nous devions séparer les choses en ces composants individuels. Et il y a une vertu à faire cela, parce que si c'est isolé, il est plus facile de tester et de traiter comme une seule chose. Et vous pouvez en quelque sorte, en termes de façon dont nous travaillons, cela rend les choses plus faciles à gérer. Nous devons également tenir compte du fait que ces choses doivent finalement partager le même espace et se regrouper dans un système plus vaste.

Heydon: Et je ne pense pas, en fait, que suffisamment d'efforts et de réflexion soient consacrés à cela, assez curieusement. Je pense que nous composons davantage les choses pour nous faciliter la vie en tant qu'ingénieurs, afin que nous sachions sur quoi nous travaillons à quel moment. Et, mais ensuite, nous négligeons souvent le fait que ces choses vivront dans des systèmes dynamiques et qu'elles doivent être…

Heydon : Je veux dire, le projet Every Layout, bien qu'il s'agisse davantage de conception visuelle et de mise en page, consiste à essayer de créer ces petites primitives CSS, ces petites primitives de mise en page, de manière à ce qu'elles puissent s'auto-gérer de manière algorithmique. C'est pour que vous puissiez les sortir d'une colonne étroite et les mettre ensuite dans une colonne large, puis ce sera, le code lui-même déterminera combien d'éléments il devrait y avoir ou s'il doit se reconfigurer d'une autre manière. Parce que nous ne pouvons pas nous permettre d'intervenir constamment, et il faut que ce soit un système qui soit en quelque sorte conscient de lui-même et intelligent, je pense.

Heydon : Il y a toujours des choses que vous pouvez oublier. Alors peut-être que vous créez une interface à onglets, vous avez une rangée d'onglets, vous choisissez entre l'onglet et l'onglet correspond à un panneau d'onglets, qui ouvre quelque chose. Et puis, quelqu'un viendra et dira: "Eh bien, et si je veux mettre une interface à onglets dans une interface à onglets, ou un autre composant à l'intérieur d'une interface tactile?"

Heydon : Et bien sûr, je veux dire, c'est en partie une question technique de savoir si cela serait possible, mais oui, vous devez décider si vous allez rendre les choses aussi flexibles que possible afin que ce soit possible d'imbriquer les choses de manière complexe, ou simplement d'écrire des règles strictes qui disent : "Vous ne pouvez pas mettre quelque chose à l'intérieur parce que le niveau de complexité en termes de code serait probablement trop élevé, mais aussi peut-être en termes de comment l'utilisateur peut percevoir et utiliser la chose. Je suis tout à fait d'accord pour écrire des règles qui disent : « N'imbriquez pas des tas de fonctionnalités complexes à l'intérieur d'elles-mêmes », parce qu'il est tout simplement peu probable que les gens soient capables de s'y retrouver, vraiment.

Drew : Est-il possible d'adopter une approche entièrement algorithmique ou automatisée de la conception pour l'accessibilité ?

Heydon : Je ne crois pas. Non. Nous avons donc des outils automatisés et je ne veux en aucun cas dénigrer les outils automatisés. Je pense qu'ils sont très utiles, mais je les utilise comme un système d'alerte précoce pour essayer d'avoir une idée de l'endroit où se situent les problèmes. Donc, si je faisais un audit pour une organisation qui voulait des conseils sur la façon de rendre ses produits plus accessibles. C'est donc un bon moyen de financement là où se trouvent les zones à problèmes, mais je veux dire, vous pouvez avoir une interface qui est techniquement accessible à 100 %, peut-être, selon certains outils, même un bon outil pour le juger, disons, par rapport aux WCAG , les consignes d'accessibilité du contenu Web ou toute autre spécification d'acceptation. Et, même s'il s'agit d'une sorte de 100% de toutes les cases cochées, il peut toujours être totalement inutilisable pour diverses raisons.

Heydon : Par exemple, pour revenir à ce que nous disions auparavant, cela peut être tout simplement trop complexe. Vous pouvez simplement submerger quelqu'un avec des liens et il n'y a tout simplement aucun moyen qu'il puisse passer à travers, puis cela devient, c'est une sorte de chose tacite et difficile à cerner, mais cela ne fera qu'aliéner les gens. Mais il y a aussi, vous pouvez obtenir, il est très facile d'obtenir des faux positifs et des choses comme ça. J'ai eu un truc l'autre jour, j'ai dit l'autre jour, c'était l'autre mois, je travaillais pour une organisation et bien sûr ils voulaient avoir une école phare 100% accessible et il y avait une iframe qui y était déposée dynamiquement par un script analytique ou quelque chose. Vous savez le genre de chose où c'est une sorte de code un peu grossier, qui est juste en quelque sorte inséré dans la page pour faire une tâche comme ça.

Heydon : Maintenant, je recommanderais de ne pas utiliser d'analyses du tout, et je leur ai recommandé d'au moins prendre en charge le protocole de non-suivi afin que les gens puissent se retirer. Malheureusement, ce protocole ne fonctionne plus vraiment parce qu'il n'a jamais été correctement pris en charge. Mais cet iframe, il disait qu'il n'y avait pas de titre dessus. Donc, l'idée est que si vous avez un iframe, il devrait avoir un attribut de titre car c'est le meilleur moyen d'identifier depuis longtemps à quoi sert l'iframe pour un utilisateur de lecteur d'écran. Mais c'était un iframe qui était également configuré pour n'en afficher aucun, donc il n'était même pas perceptible par un lecteur d'écran en premier lieu car n'en afficher aucun, tout comme il cache les choses visuellement dans un lecteur d'écran, il le supprimera essentiellement du interface, de sorte qu'il ne sera pas rencontré ou annoncé de quelque manière que ce soit.

Heydon : C'était donc un faux positif. Je veux dire, il me demandait d'identifier une iframe qui n'était pas là pour être perçue en premier lieu. Donc, il y aura toujours ce genre d'erreurs et de problèmes dans les tests automatisés. Mais en fin de compte, il s'agit de savoir, même si c'est juste une sorte de chose dans laquelle les programmeurs, je suppose, n'aiment pas vraiment penser qu'ils sont impliqués et ils trouvent cela un peu dégueulasse, mais il s'agit de comportement humain et de comment les gens comprennent les choses et c'est très difficile d'avoir un ensemble de règles binaires ou booléennes.

Heydon : Donc, je veux dire, j'ai parlé à un développeur lorsque je consultais à ce sujet il y a quelque temps et ils n'arrêtaient pas de dire : « Eh bien, tant que nous avons des tests automatisés, tout va bien, n'est-ce pas ? C'est juste, alors nous pouvons simplement avancer. Et j'ai dit: «Vous devez toujours tester manuellement. Il n'y a pas de test automatisé qui puisse vraiment vous dire si l'utilisation de l'interface au clavier est impossible d'une manière ou d'une autre. Il y a des sortes de choses discrètes que vous pouvez rechercher, mais l'expérience globale est toujours quelque chose qui doit être jugée par l'être humain. Ouais.

Drew : Parfois, le danger avec les outils automatisés est qu'ils examinent les éléments de manière isolée ou qu'ils examinent une interface de manière isolée et ne voient pas le contexte plus large.

Heydon : Oui.

Drew : Certainement qu'avec l'utilisation de Lighthouse pour les audits de performance, je peux parfois prendre la décision en tant que développeur d'inclure, il peut y avoir beaucoup plus de CSS que ce qui est utilisé sur cette page et à proprement parler, je télécharge trop de CSS, mais en fait , je sais qu'une fois ce fichier chargé, au moment où l'utilisateur accède à la page suivante, il a déjà le CSS. Il s'agit donc d'une optimisation effectuée sur plusieurs pages que l'outil, en examinant une page de manière isolée, considère comme une erreur.

Heydon : Oui, absolument. Vous pensez à l'avenir et vous faites un jugement, et jusqu'à ce que nous arrivions à l'IA avancée pour anticiper cela, alors oui, vous avez vraiment besoin d'êtres humains qui l'examinent et le traversent et vont… Je veux dire, donc les tests automatisés devraient être en place, comme je l'ai dit, une sorte de système d'alerte précoce, de système de diagnostic, mais il devrait également y avoir, si vous souhaitez que votre organisation soit vraiment attentionnée et rende les choses plus inclusives et plus accessibles, il doit également y avoir une formation . Il doit y avoir des questions et réponses.

Heydon : J'écrirais donc des scripts pour "Voici comment cela devrait fonctionner lorsque vous interagissez avec ce composant avec un clavier" ou "Voici comment cela devrait fonctionner lorsque vous interagissez avec un lecteur d'écran et que vous ne parcourez pas réellement ce. Donc, lorsque vous faites cela, cela devrait arriver. Lorsque vous faites cela, cela devrait arriver. Lorsque vous faites cela, cela devrait apparaître », ou ce genre de choses. Donc, et le genre de trucs de voyage, comme vous le dites, les outils automatisés n'en sont pas conscients. Ils voient juste, "Oh, il n'y a pas de texte alternatif ici." Et en fait, dans de nombreux cas, il ne devrait peut-être pas y avoir de texte alternatif. Et aussi, il ne peut pas juger si vous avez bien écrit le texte alternatif ou non. Je pense donc qu'une image sans tout texte alternatif est probablement meilleure qu'une image avec un texte alternatif trompeur ou simplement mauvais. Et c'est encore une question de jugement, n'est-ce pas ?

Drew : L'une des choses avec lesquelles j'ai eu du mal, historiquement, à construire des choses de manière accessible, c'est de maintenir à jour mes connaissances sur les meilleures pratiques, car chaque fois que je me réfère à une documentation ou à une sorte de recommandation, il semble être ce que je faisais et je pensais que je faisais la bonne chose, les recommandations ont évolué et maintenant je devrais faire autre chose. Et c'est une histoire familière avec tous les domaines de travail sur le Web. Mais je pense que le danger est, bien sûr, avec les problèmes d'accessibilité, c'est que, si vous ne suivez pas les meilleures pratiques, si vous laissez quelque chose dans votre interface qui n'est plus une bonne pratique, cela pourrait affecter négativement vos utilisateurs façon. Est-ce qu'une approche basée sur les composants pour créer une interface ou un site aide-t-elle d'une manière ou d'une autre ?

Heydon : Je pense purement dans le sens où, parce que vous avez un composant qui alors, l'idée bien sûr dans tous les cas et pas seulement en termes d'accessibilité, c'est que vous avez ce composant défini à un endroit qui sera ensuite utilisé dans différents endroits, au moins lorsque les aspects ou la prise en charge du navigateur ou quoi que ce soit changent et que vous souhaitez mettre à jour le composant, vous n'avez qu'à le faire à un endroit et ensuite partout où il est utilisé, cette amélioration ou ce changement se fera sentir. Donc, de ce point de vue, je pense qu'il est certainement plus utile de diviser les choses en composants.

Heydon : Mais alors, oui, comme je l'ai dit, cela n'affecte pas seulement l'accessibilité, cela peut affecter tout ce qui change. Mais ensuite, je ne sais pas vraiment combien de changements dans son… Je veux dire, il y aura peu de changements de rupture en termes d'accessibilité HTML, qui est, évidemment, un domaine très étroit. Mais en termes de qualité de code ou de fonctionnement du code, les choses sont introduites dans la spécification HTML, évidemment, très lentement et pas aussi lentement mais assez lentement dans la spécification ARIA également. Et puis, une grande partie d'ARIA ne fait que refléter ce qui se trouve dans le HTML de base sous-jacent de toute façon.

Heydon : Je pense que, plus que la technologie, la perception et la compréhension de ces choses ont tendance à changer avec le temps. Je veux dire, il y a eu récemment, dans l'enquête WebAIM récemment, ils ont identifié que les sites utilisant ARIA étaient plus inaccessibles que les sites qui ne l'utilisaient pas. Donc, cette technologie spécialement conçue pour aider les gens à rendre les sites Web plus accessibles ne faisait qu'empirer les choses. Donc, c'est vraiment, c'est juste un manque de connaissances, pas un fossé technologique ou une lacune technologique. Ce sont des gens qui prennent la technologie et l'utilisent à mauvais escient parce qu'ils ne comprennent pas vraiment comment elle est censée fonctionner, malheureusement. J'espère que certains de mes écrits pourront peut-être aider à cela. Dans certains domaines, en tout cas.

Drew : Mais une sorte de système basé sur des composants bien structuré vous permettrait, une fois que vous réalisez que quelque chose est obsolète ou que vous avez pris une mauvaise décision et que vous savez maintenant mieux, vous permettrait d'entrer plus facilement et de résoudre ce problème dans votre application.

Heydon : Ouais, exactement. Ouais, ouais, absolument. Je veux dire, tout est une question d'efficacité, n'est-ce pas, vraiment ? Et ce principe aride ou ce que vous avez, et voyez, c'est pourquoi je suppose que j'étais initialement très excité par cette opportunité, parce que les gens se plaignent toujours que rendre les choses accessibles est un travail supplémentaire et c'est dur et c'est bouleversant et tout ça. Et donc, c'était une sorte d'occasion de dire: «Eh bien, vous savez comment vous faites ce truc vraiment, efficacement en construisant ces systèmes de composants? Obtenez votre accessibilité là-dedans pour ce composant que vous créez, et vous n'aurez plus à vous soucier de l'accessibilité, à part le changement ou la mise à jour occasionnelle des spécifications, etc.

Heydon : Ou simplement, je veux dire, probablement la plupart du temps, l'itération sera simplement basée sur les commentaires des utilisateurs et les recherches en cours, que vous devriez évidemment, autant que possible, mener avec un groupe diversifié de personnes. Donc, vous devriez avoir des gens qui utilisent différents appareils et ont des habitudes de navigation différentes et utilisent différentes technologies d'assistance et ce genre de choses. Et vous savez, les choses doivent arriver tout le temps. Je pense que j'ai vraiment identifié un composant, je pense qu'il est vraiment solide, puis je fais un peu de recherche et je trouve que j'ai fait de très mauvaises hypothèses. Mais oui, avec un système de composants, vous n'avez qu'à le réparer en un seul endroit.

Drew : Un composant peut-il être totalement inclusif ou s'agit-il d'un spectre dans lequel vous travaillez de plus en plus vers l'inclusivité ?

Heydon : Oui, il serait possible qu'un composant soit, disons, sans erreur WCAC, il réponde à tous les critères WCAC, mais comme je l'ai dit, cela ne vous emmène que si loin et il pourrait encore être entièrement inutilisable ou impossible à comprendre même avec ces critères techniques remplis. Alors oui, c'est quelque chose dont je parle beaucoup. J'essaie de convaincre les gens que l'accessibilité est comme n'importe quel autre domaine du design, c'est juste une partie du processus de conception et rien ne peut être parfaitement conçu, tout comme rien ne peut être parfaitement accessible. Je pense que, malheureusement, beaucoup de gens y pensent simplement pour s'assurer qu'il est compatible avec les lecteurs d'écran, ce qui est évidemment une portée très étroite en termes d'accessibilité et d'inclusion en général.

Heydon : Alors, il y aura des gens qui, de bonnes personnes avec qui j'ai travaillé, comme au groupe Paciello, diront : "Eh bien, en fait, je veux être connu comme une personne UX accessible." Il ne s'agit donc pas seulement de cocher des cases, il s'agit plutôt d'essayer de rendre l'expérience meilleure et plus précieuse pour le plus grand nombre de personnes et d'aller davantage vers des principes plus larges et des choses moins binaires. Mais en fin de compte, c'est tout cela, et le WCAC et d'autres critères de ce genre ne peuvent vraiment identifier que le vrai truc, "C'est faux", je suppose.

Drew : Donc, si je suis développeur, que devrais-je faire différemment lorsque j'aborde la façon dont je conçois, planifie et crée un composant ? Y a-t-il quelque chose dont je devrais tenir compte dans mon travail pour m'assurer que cette composante finira par être aussi inclusive que possible?

Heydon : Donc, je veux dire, selon ce que vous construisez, il y aura différents critères à respecter. Ainsi, par exemple, tous les composants ne disposeront pas d'images accessibles avec un texte alternatif, car ils pourraient ne pas utiliser d'images du tout. Cela pourrait simplement être basé sur du texte ou quoi que ce soit d'autre. Certains peuvent ne pas être interactifs. Donc, en termes d'exigences spécifiques, cela changerait d'un composant à l'autre, mais j'espère que ce que certains de mes écrits et ce que le livre Inclusive Components vous aide à faire est de tomber dans ou d'adopter une discipline consistant à penser de manière inclusive.

Heydon : Donc, lorsque vous abordez ce genre de choses, pas seulement en pensant, eh bien, en gros, en sortant simplement de l'état d'esprit de "Si ça marche pour moi, ça marche probablement pour tout le monde", parce que ce n'est tout simplement pas le cas que le façon dont vous ou moi parcourons les choses, je veux dire, nous ferons probablement les choses complètement différemment, juste nous deux, n'est-ce pas ?

Drew : C'est vrai.

Heydon : Et nous sommes occidentaux, blancs, anglophones comme première langue. Et donc, oui, la quantité de diversité en termes de personnes qui consomment cela, je veux dire les gens de la performance en parlent toujours aussi, les gens qui sont intéressés à plaider pour de meilleures performances. Vous avez l'habitude d'utiliser une configuration de haute spécification sur un bon réseau et beaucoup de vos utilisateurs ou beaucoup de vos utilisateurs potentiels ne le seront certainement pas, et il en va de même pour l'accessibilité. C'est juste une question, fondamentalement, de ne plus penser à vous-même, vraiment. Littéralement juste ça. Et essayer, évidemment, d'aller au-delà de vos collègues immédiats et des personnes de votre même groupe social.

Heydon : Alors j'espère que c'est vraiment juste, « Voici ce que j'ai résolu pour ce truc », et ce à quoi je pensais à l'époque. Vous pouvez réutiliser certaines de ces idées et appliquer précisément ce que j'ai appliqué, si cela vous est utile ou pertinent. Avec un peu de chance, le livre parle plus simplement : « Voici une étude de cas d'une personne qui essaie de penser de manière inclusive. Vous voyez, le genre de choses auxquelles ils pensaient, lorsque vous concevez quelque chose de complètement différent, utilisez peut-être simplement le même type de pensée et essayez d'ouvrir votre esprit à la diversité des utilisateurs et à la façon dont ils s'y prennent.

Drew : Donc, le livre lui-même, comment avez-vous décidé de le structurer ? Cela semble très farouchement pratique, ce que j'aime bien dans un livre, mais comment l'avez-vous structuré ?

Heydon : Tout comme le livre précédent, c'était en fait Inclusive Design Patterns et j'ai eu beaucoup de mal avec ce livre, pour commencer, parce que j'ai essayé de l'organiser en termes de critères abstraits. J'ai donc commencé à écrire un chapitre consacré à l'accessibilité du clavier, mais c'était très difficile car je devais en quelque sorte, chaque fois que je parlais d'un type différent d'accessibilité au clavier ou de la chose à laquelle vous devez penser, alors je devait évoquer une sorte de composant, puis abandonner ce composant, puis passer à autre chose.

Heydon: Et donc, il était plus logique pour moi d'organiser les choses en termes de composants eux-mêmes. Ainsi, Inclusive Design Patterns fait cela et maintenant Inclusive Components n'est vraiment qu'une continuation, qui ne couvre que différents composants. C'est différent en ce sens qu'en termes de fonctionnalités, c'est un peu différent parce qu'il inclut également des exemples de code en direct et des trucs, ce que je n'ai pas tellement fait pour les livres précédents. Mais oui, c'est littéralement juste "Nous allons faire ce composant", qu'il s'agisse d'une interface tactile ou d'une section pliable ou d'un sélecteur de thème ou d'une carte flash de notification ou d'un grille-pain ou de tout ce qu'ils s'appellent, et puis juste tout s'organise alors autour de ce composant.

Heydon : Donc c'est : « C'est ce que nous faisons et ce sont les choses que nous devrions considérer pendant que nous le faisons pour être plus inclusifs », parce que c'est comme ça que je travaille et c'est comme ça que les autres travaillent. Et dès que j'ai commencé à le faire comme ça, c'était vraiment moi qui travaillais et écrivais des notes pendant que je travaillais. Et donc, la chose s'est en quelque sorte écrite d'elle-même, et ensuite tout l'effort consistait vraiment à s'assurer que je faisais un travail décent pour rendre ces choses non inaccessibles, je suppose.

Drew : Oui, je veux dire que la table des matières se lit presque comme de la documentation ou comme un manuel d'auto-assistance ou quelque chose comme ça. Directement avec le chapitre un, basculez les boutons. Si vous souhaitez implémenter des boutons à bascule, allez à ce chapitre, lisez-le et vous obtiendrez tout ce que vous devez savoir sur la façon de le faire, ce qui est une approche que j'aime beaucoup. Je vois des choses comme des sections pliables, une interface à onglets, des commutateurs de thème, des tableaux de données, des tas de trucs réels et pratiques que nous construisons tous chaque jour et je pense que nous pourrions tous, probablement, construire mieux.

Heydon : Ouais, c'était tout à fait l'idée parce qu'il ne s'agissait pas seulement de fabriquer mes composants, c'était un cas, et vous en avez parlé là, ce que je suis content que vous ayez fait, c'est-à-dire qu'il s'agissait d'identifier des éléments communs modèles que nous utilisons tous. Donc, je veux dire, il y a des interfaces d'onglets partout et elles sont toutes implémentées différemment et elles sont toutes implémentées, différemment, très mal. Je veux dire, j'ai implémenté des interfaces d'onglets terribles et j'ai appris un peu à quel point elles étaient mauvaises pour les gens, puis j'ai essayé de les rendre un peu meilleures et un peu meilleures et un peu meilleures. J'ai probablement créé 15 ou 16 versions différentes d'interfaces d'onglets à mon époque, faisant ce genre de choses depuis des années maintenant.

Heydon : Et vous savez, ils s'améliorent un peu, espérons-le, à chaque fois. Mais c'est juste une chose courante. C'était une chose commune que j'utilisais assez souvent entre différents sites Web, que j'utilise et que tout le monde utilise. Donc, une partie de l'idée était de dire : "Eh bien, en fait, faisons un système de conception, une sorte de système de conception accessible pour le Web." Maintenant, les gens vont se diversifier et ils vont faire leurs propres versions de ces choses, mais pour en quelque sorte réduire les éléments de base et l'accessibilité est une chose essentielle qui devrait être dans les choses. Cela ne devrait pas être un ajout, cela ne devrait pas être un choix, cela ne devrait pas être une fonctionnalité. Cela devrait être une chose essentielle. Et si vous associez ces éléments de base, alors oui, j'espère que les gens regarderont les chapitres et diront: «Oh, d'accord, j'ai fait ceux-là. J'ai vu ceux-là. Voyons comment le faire de la manière la plus inclusive possible », et j'espère qu'ils en retireront une certaine valeur.

Drew : Eh bien, ce que j'aime, c'est que je sais que j'ai eu, dans le passé, des fonctionnalités d'interface que j'avais besoin d'implémenter et je sais que ça va être délicat du point de vue de l'accessibilité. , disons une sorte de menu volant, un menu déroulant, quelque chose comme ça. Je pense: «D'accord, voici des dragons en termes d'accessibilité. Je dois m'assurer de bien faire les choses. Et donc, je recherche sur Google comment le faire, je trouve une source fiable disant : « Utilisez cette méthode », j'utilise cette méthode, je la mets en œuvre et je passe à autre chose, mais je n'ai en fait rien appris. Je n'ai pas appris pourquoi la solution était celle-là. Et ce que j'aime vraiment dans la façon dont vous abordez le sujet dans le livre, c'est que je peux faire deux choses à la fois. Je peux comprendre comment je devrais le faire et je peux comprendre pourquoi je devrais le faire comme ça parce que tout est très soigneusement expliqué. Donc, je pense que c'est vraiment réussi de ce point de vue.

Heydon : Oh, super. C'était ce que je cherchais. Alors c'est bien. But yeah, that seems to be my thing. I mean, I've been working with the BBC for some months and we've kind of made a thing a bit like Inclusive Components but for the BBC, so we've done this sort of technical implementation with a through the lens of accessibility version of their design language called GEL. And yeah, it explains the why as well as the how and it's not a pattern, really. The idea is that the individual departments at the BBC, because there's so many of them, because it's such a large organization, so there'll be BBC Sport, BBC Weather, BBC News, they're the ones who would be taking care of the kind of technical stack and making their pattern library. And what we've really provided is just, we've just tried to exemplify the best practices. So it was really much more of a learning resource than a simple plug and play pattern library. Ouais.

Drew: Was it difficult deciding what patterns to include in the book? Was there anything that you left out?

Heydon: The only ones I really had problems with or second thoughts about were the ones where, the tab interface, for instance, I wasn't going to include, because I really hate tab interfaces, but then I had folks saying, “Could you please do a tab interface? Could you include a chapter of that?” Because I get asked to put them in my interface all the time by clients or whoever. So, I ended up doing one. But it's full of caveats. And the main caveat is, probably don't use a tab interface. Use maybe an accordion, it's a simpler interaction paradigm. It's easier to make responsive, it's easier to make compatible with screen readers, et cetera, et cetera.

Heydon: So I put all those caveats in. But yeah, and some of them were ones where I just thought, “Oh, I haven't written about this before and I could do with having sort of thought about it so that I could actually use it in my design work.” And others were people requesting, saying, “I know this is a gnarly one, I just don't know how to go about it. Could you give it a go?” And so I gave it a go as best as I could. That is going to be the last time I write a book about accessibility because I've done three now.

Heydon: So if anyone wants to know any more and if they think of any other components that they might want doing, just DM me on Twitter or something and I'll try and deal with it in that way rather than writing a whole article, because those articles are quite long and they take up quite a lot of time and I'm kind of doing other things at the moment. But I'm always happy to chat with anyone who has any questions about this stuff. They might be working on something similar to what I've covered and there was just something that they were unsure about or which I, for whatever reason, I hadn't made as clear as they'd liked it. Yeah, then just contact me because I'm always happy to talk about the stuff because it helps me to sort of ruminate over things and try to, it might challenge my assumptions and help me to do a better job as well.

Drew: So, the book, Inclusive Components, is available right now from Smashing Magazine, smashingmagazine.com/books, and I'd recommend everybody check it out.

Heydon: Thank you.

Drew: So I always like to ask people, I mean, Smashing is all about learning, right, with the books, the conferences, the magazine, we're all about learning. What is it that you've been learning lately?

Heydon: So, recently, well, a couple of years ago I made something, I made a drum machine using the web audio API called Beads and it's still available as a PWA, it's a progressive web app. If you Google search Beads GitHub or something like that, you should get the GitHub page which has it on there. But that was a alpha version and I'm now working on doing a much more advanced version of this. And it's a different kind of drum machine because it's polymetric, it has different, you can have different tracks of different lengths. So you can have a track which has seven beats and a track which has nine beats, a track which has four beats. And then, the rhythm evolves over time because of the changing syncopation. You've got these, it's multi-threaded.

Heydon: That was the main reason that I wanted to build it, because, as someone who's interested in kind of experimental music, that's something I wanted to play with. Obviously, I'm trying to make this drum machine as accessible as possible. And that's been interesting from the point of view now that I'm working with, I'm turning it into an Electron app. So, for those of you that know Electron allows you to kind of wrap a sandbox version of Chromium browser and create a desktop application but using web technology, which was really great because it makes things, for this projects anyways, because it gets around a lot of performance problems.

Heydon: But also, although I've been doing cross browser testing for 12 years now, it's really nice to have a break and just to design stuff for one browser. And it's got some, so there's a flag in Chromium. It's a, what's it called, an experimental web platform feature for focus visible. So I've been able to make this drum machine completely keyboard accessible with these really nice, big focus outlines without those appearing for mouse users, because focus visible uses this heuristic where it detects whether or not you're using a keyboard. So that's been nice, to be able to incorporate that.

Heydon: But the thing recently that I've been learning about, just I've, I guess, been learning about some of the more advanced things you can do with the web audio API itself. So I had this problem where I have, you can put multiple sounds on one track so you can load in an array of audio files and it places them one after the other, and by default they overlap, so they'll always play out out, the audio buffer will play until it finishes. So if the next sounds comes before the end of that, it just overlaps, which is fine. It's kind of like a reverb or something. But sometimes if you're doing an arpeggio, like a baseline or something, you don't want them to open up. That's not how a bass guitar works, right? If you're on the same string, you press the next note, the first one has to finish.

Heydon: So, I was stopping a note as the next one started and there was always an audible popping sound and it's not the web audio API having a problem or anything like that. It's just the human ear will hear a kind of a nasty popping sound where you kind of sever away from. You just cut it, stop it dead, it's going to sound nasty. And then, so I found that there's a function as part of the web audio API, which allows you to choose a point where you can taper off the sound. And so I was able to detect where the sounds should end because the other sound is beginning, then taper it off very quickly, but it is a taper, like a fade out, rather than a hard cut off thing.

Heydon: So I solved that problem after it annoying me for ages. So it's basically been web audio API stuff and messing around with sounds because I've always been into, as I say, into experimental music and messing about with that sort of stuff. And I'm trying to write a talk about this. And in the talk, I'm using Billy Jean by Michael Jackson because it's a very straight, fall to the floor rhythm and I'm going to kind of warp it in various different ways. So I've actually had to learn the parts for Billy Jean to kind of sequence that and stuff. So, weirdly enough, that was what I was doing before doing this podcast.

Drew: That sounds like a lot of fun. So if you, dear listener, would like to learn more about Heydon or hire him to consult on your projects, you can follow him on Twitter, where he's @heydonworks, or visit his website at heydonworks.com. Thanks for joining us, Heydon. Do you have any parting words?

Heydon: Goodbye.