Que sont les composants inclusifs? éclatant

Dans cet épisode de Smashing Podcast, Drew McLellan s'est entretenu avec Heydon Pickering au sujet de son nouveau livre, Inclusive Components . Heydon est connu pour son travail et ses écrits sur l'accessibilité, alors qu'est-ce que la conception inclusive et où les composants entrent-ils en jeu? Heydon a tout cela et plus dans cet épisode. Vous pouvez écouter ci-dessous ou vous abonner dès que vous recevez vos podcasts.

Afficher les notes

Transcription

Drew McLellan: Il est consultant indépendant en accessibilité Web, concepteur d’interface et rédacteur. Ses travaux portent sur la conception d'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, qui explique comment créer des interfaces Web accessibles avec Smashing Magazine. Donc, il est clairement un expert en matière de conception accessible, mais saviez-vous qu’il était le premier homme à sauter le pont du port de Sydney en vedette rapide? Mes amis Smashing, s'il vous plaît accueillir Heydon Pickering. Salut Heydon. Comment allez-vous?

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

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

Heydon: Oui.

Drew: De toute évidence, il ne s'agit que d'un titre de deux mots, mais j'ai l'impression que chacun de ces mots soulève beaucoup de problèmes. À partir de la fin, comme il est évidemment logique de le faire, composants, s’agit-il d’une sorte de conception à base de composants?

Heydon: Ouais, alors je suppose que cela fait longtemps maintenant que les gens, les développeurs front-end, les concepteurs et tous ceux qui collaborent à la création d'interfaces, ont commencé à réfléchir aux choses en termes de composants et de division. 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 un peu comme des composants électroniques. Mon père est un ingénieur en électronique. Il travaille dans le monde analogique des cartes de circuit imprimé et de la soudure, etc.

Heydon: En fait, il a fabriqué des composants, de très petits composants, qui ont été utilisés pour réguler le courant entrant. électroaimants au CERN. Et il avait beaucoup confiance en moi en tant qu'enfant, car il m'a obligé à souder une partie de la pièce pour eux. Je pense que ce lot est maintenant à la retraite, alors ne vous inquiétez plus de ma mauvaise soudure, de ma pauvre soudure d’adolescence, de ma participation au CERN. Mais oui, je pense que cela est analogue à… Oh, il y a trop d'analogues là-dedans.

Heydon: C'est analogue aux cartes de circuits analogiques en ce que l'idée est que vous avez des responsabilités uniques pour des pièces individuelles ou des composants et , ils font le circuit et, ensemble, ils augmentent le courant dans le cas d’un circuit ou, je suppose, de l’interface ou du résultat de quelque manière que ce soit, dans un système de conception ou dans une interface manifestée par un système de conception. Et oui, Inclusive Components parce que je voulais aborder le fait que, bien que je veux dire, l'accessibilité ait tendance à être laissée pour compte lorsque nous avançons dans ce que nous faisons dans différents domaines, et je voulais apporter l'accessibilité et, plus largement sens, conception inclusive à porter sur ce genre de nouvelle façon de penser et de faire des choses en utilisant des composants ou des modules ou quoi que vous vouliez les appeler.

Heydon: L’idée était donc d’apporter l’accessibilité aux systèmes de conception, mais Dans le même ordre d'idées, réfléchissez systématiquement à la question de l'accessibilité. Pensez à résoudre un type de problème au même endroit en termes d’accessibilité et en veillant à ce que le système de conception dans son ensemble se propage [inaudible 00:03:16] dans son ensemble.

Drew: En un sens pratique, que cela ressemble-t-il réellement à fonctionner de manière composante? Quel pourrait être un exemple de composant?

Heydon: Il existe donc différentes manières de concevoir et de coder des composants. J'ai tendance à aller droit au but, à dépasser le concept théorique et à réfléchir à la manière dont je pourrais organiser le code. En fait, j’ai commencé à me concentrer beaucoup sur les éléments personnalisés, ou s’ils ne le sont pas, sur les éléments normaux, mais avec une sorte de comportement JavaScript qui leur est associé de manière isolée et par composants. 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 intéressants car ils sont natifs. Vous pouvez les définir à un 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 d'affichage ou ils pourraient être utilisés dans une application angulaire, ou quelque type de technologie de gestion d'état plus grande que vous utilisez. using.

Heydon: Donc, pour moi, généralement, un composant sera probablement un élément personnalisé. J'ai récemment travaillé sur un projet moins axé sur l'accessibilité, bien que j'aie essayé de le rendre aussi accessible que possible, appelé Every Layout, et qu'il s'agisse d'essayer d'isoler des algorithmes très spécifiques. Mise en page CSS. Et ils sont définis comme des éléments personnalisés et se déploient, utilisent leur propre CSS et fonctionnent comme des primitives dans un système plus vaste.

Drew: Je veux dire, concrètement, nous Parlez-vous un composant 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 à onglet. Ainsi, l’idée avec Inclusive Components était de prendre le concept d’un composant avec, espérons-le, un seul but, comme une entrée de texte, puis de réfléchir à toutes les choses qui pourraient faire trébucher différents types de personnes et d’éviter leur. Évitez les gens, évitez les problèmes.

Heydon: Cela semble être le moyen le plus simple d'aborder un processus de conception inclusif pour moi, c'est d'identifier en quelque sorte les éléments d'exclusion potentiels. de quelque chose et essayer de les contourner. Donc, avec une saisie de texte, avec une étiquette, vous pouvez vous inquiéter de différentes choses. Donc, vous devez savoir si elle est étiquetée correctement ou non. Vous utilisez donc un élément label et cet élément label pointe-t-il sur le champ de texte à l'aide d'un attribut for, de sorte que les deux éléments soient associés par programme, de sorte que lorsqu'un utilisateur de lecteur d'écran focalise l'entrée, il entend réellement l'étiquette annoncée? C'est donc une chose à comprendre.

Heydon: Ensuite, à un niveau plus visuel, en s'assurant que l'étiquette est clairement associée à ce champ et non à un autre, c'est une question d'espace. et ce genre de choses. En outre, si vous veillez à ce que l’étiquette ne soit pas, vous ne ferez pas comme si vous placiez l’étiquette sous leur entrée de formulaire, car cela risquait d’être obscurci lorsque vous utilisez un clavier virtuel, par exemple. Donc, cela prend en compte ce genre de choses.

Heydon: Assurez-vous que l'entrée a un style de focus, donc lorsque vous la focalisez avec un clavier, que vous soyez un utilisateur de clavier habituel qui utilise des claviers pour naviguer ou non, assurez-vous que le style de focus fait clairement apparaître les informations sur lesquelles vous vous concentrez. S'assurer que, je veux dire, des choses comme l'auto-complétion, l'inquiétude à ce sujet, si l'auto-complétion est appropriée et utile dans le contexte ou non. Et beaucoup de ces choses traitent directement du handicap, mais beaucoup sont plus larges en termes de facilité d'utilisation et de rendre les choses aussi compréhensibles que possible.

Heydon: Assez souvent, il y a une sorte de ligne très fine ou peut-être une ligne floue entre ce qui concerne le genre de facilité d'utilisation pour tout le monde et ce qui concerne le handicap. Et puis, pour rendre encore plus difficile la définition des handicaps cognitifs. Donc, si quelque chose n'est pas très utilisable pour quelqu'un qui n'a pas de déficience cognitive, alors il sera encore plus difficile de travailler et d'être capable de l'utiliser pour quelqu'un qui a ce genre de défis.

Heydon: Nous essayons donc simplement de penser à toutes ces choses au même endroit. Et vraiment, le livre n’est que le mien, c’est ma façon de penser à mesure que j’aborde chacune de ces choses. Alors je l'ai fait comme un blog pour commencer. Et chaque modèle ou chaque composant est un article de blog et le texte me dit simplement: «Alors, abordons maintenant ce problème potentiel. Comment allons-nous à ce sujet? D'accord, nous avons coché cette case. Je pense que tout va bien là-bas. »Et, en aucun cas, j'essaie de dire que ce sont parfaits et que j'ai tout pensé, parce que ce n'est pas possible.

Drew: Il en va de même pour la prise d'un composant. Une approche basée sur la façon dont vous travaillez sur les différentes parties d’une interface, je suppose, vous permet d’approfondir cet élément et de vous assurer de l’optimiser de manière optimale pour le rendre accessible à tout le monde. . Y a-t-il un danger à le faire et à le faire sur un grand nombre de composants différents, puis à les regrouper tous sur une page? Y a-t-il un danger que vous puissiez créer des problèmes dont vous n'étiez pas au courant, car vous les testiez individuellement et non ensemble?

Heydon: C'est un très bon point, et j'allais en parler plus tôt. réellement. Je suis content que vous ayez dit ça. Donc, à bien des égards, je pense que nous avons, philosophiquement, décidé de séparer les choses en composantes individuelles. Et il est bon de le faire, car s’il est isolé, il est plus facile de faire un test et de le traiter comme une seule chose. Et vous pouvez en quelque sorte, en ce qui concerne notre façon de travailler, rendre les choses plus faciles à gérer. Nous devons également prendre en compte le fait que ces éléments doivent en fin de compte partager le même espace et s'unir dans un système plus vaste.

Heydon: Et je ne pense pas, en fait, assez de nos efforts et la pensée y va assez curieusement. Je pense que nous intégrons davantage les choses pour rendre notre vie d'ingénieur plus facile, de sorte que nous sachions sur quoi nous travaillons à quelle heure. Et puis, nous négligeons souvent le fait que ces éléments vont vivre dans des systèmes dynamiques et qu'ils doivent…

Heydon: Je veux dire, le projet Every Layout, bien qu'il s'agisse davantage de design visuel et de layout, consiste à essayer de créer ces petites primitives CSS, ces petites primitives de mise en page, de manière à ce qu'elles puissent s'autogérer de manière algorithmique. C’est pour que vous puissiez les extraire d’une colonne étroite et les placer ensuite dans une colonne large. Ce sera ensuite le code lui-même qui déterminera le nombre d’éléments au même niveau 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 se connaisse et qui est intelligent, je pense.

Heydon: Il ya toujours des choses que vous pouvez oublier. Alors peut-être que vous faites une interface à onglets, vous avez une rangée d'onglets, vous choisissez entre l'onglet et l'onglet correspond à un panneau d'onglets, ce qui ouvre quelque chose. Et puis, quelqu'un arrivera et dira: «Eh bien, si je veux insérer une interface de tabulation dans une interface de tabulation ou un autre composant dans une interface de tap?»

Heydon: Bien sûr, je veux dire, il s’agit en partie de savoir si cela serait possible, mais oui, vous devez choisir si vous voulez rendre les choses aussi souples que possible pour pouvoir trier imbriquez les choses de manière complexe, ou écrivez simplement des règles strictes qui disent: «Vous ne pouvez pas insérer quelque chose ici parce que le niveau de complexité en termes de code serait probablement trop élevé, mais aussi éventuellement en termes de capacité de l'utilisateur. percevoir et utiliser la chose. "Je suis tout à fait partisan d'écrire des règles qui disent:" N'embarrassez pas une multitude de fonctionnalités complexes à l'intérieur de lui-même ", car il est tout simplement improbable que les gens puissent s'y retrouver, vraiment .

Drew: Est-il possible de prendre une approche entièrement algorithmique ou automatique Une approche novatrice de la conception pour l’accessibilité?

Heydon: Je ne crois pas. Nous avons donc des outils automatisés et je ne veux en aucun cas les dénigrer. Je pense qu'ils sont très utiles, mais je les utilise comme un système d'alerte précoce pour tenter de donner une idée des zones à problèmes. Donc, si je faisais un audit pour une organisation qui voulait des conseils sur la façon de rendre leurs produits plus accessibles. Donc, c’est un bon moyen de financement là où se posent les problèmes, mais je veux dire, vous pouvez avoir une interface techniquement accessible à 100%, peut-être, selon certains outils, même un bon outil pour juger, par exemple, contre WCAG , les directives d’accessibilité au contenu Web, ou une autre spécification d’acceptation. Et, même si toutes les cases sont cochées à 100%, elles peuvent toujours être totalement inutilisables pour différentes raisons.

Heydon: Par exemple, revenons à ce que nous disions auparavant, mais cela peut être entièrement. trop compliqué. Vous pouvez simplement submerger quelqu'un de liens et il est tout simplement impossible pour eux de passer au travers. C’est alors qu’il s’agit d’une chose très tacite et difficile à cerner, mais c’est forcé d’aliéner les gens. Mais vous pouvez aussi comprendre qu’il est très facile d’obtenir des faux positifs, etc. L’autre jour, j’avais dit quelque chose, 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 de phare accessible à 100% et il y avait un iframe qui y était tombé de manière dynamique. par un script analytique ou quelque chose. Vous connaissez le genre de choses où il s’agit d’une sorte de code légèrement grossier, qui est simplement inséré dans la page pour effectuer une tâche de ce type.

Heydon: Je recommanderais maintenant de ne pas utiliser l’analyse du tout, et Je leur ai recommandé de prendre en charge au moins le protocole «ne pas suivre» afin que les gens puissent choisir de ne pas participer. Malheureusement, ce protocole ne fonctionne plus vraiment car il n’a jamais été pris en charge correctement. Mais cette iframe disait qu’elle ne portait pas de titre. L’idée est donc que si vous avez un iframe, il devrait avoir un attribut title car c’est le meilleur moyen de longue date d’identifier son utilité à un utilisateur de lecteur d’écran. Mais il s’agissait d’un iframe qui était également configuré pour ne rien afficher. Il n’était donc même pas perceptible pour un lecteur d’écran car aucun affichage, tout comme il dissimule visuellement des éléments dans un lecteur d’écran, le supprime essentiellement du interface, donc elle ne sera ni rencontrée ni annoncée de quelque manière que ce soit.

Heydon: Il s’agissait donc d’un faux positif. Je veux dire, il me demandait d'identifier un iframe qui n'était pas là pour être perçu en premier lieu. Il y aura donc 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 une chose à laquelle les programmeurs, je suppose, n'aiment pas vraiment penser qu’ils sont impliqués et qu’ils trouvent cela un peu difficile, mais il s’agit du comportement humain et de la comment les gens comprennent les choses et c’est très difficile d’avoir un ensemble de règles binaires ou booléennes.

Heydon: Je veux dire, j’ai parlé à un développeur quand j’étais Il y a quelque temps, il y a eu des consultations à ce sujet et ils ont continué à dire: «Tant que nous avons des tests automatisés, nous allons bien, n'est-ce pas? C’est juste, alors nous pourrons simplement aller de l’avant. »Et j’ai dit:« Vous devez encore tester manuellement. Il n'y a pas de test automatisé qui puisse vraiment vous dire si utiliser l'interface avec le clavier est impossible d'une manière ou d'une autre. "Il y a une sorte de choses discrètes que vous pouvez rechercher, mais l'expérience globale doit encore être jugée par un être humain. .

Drew: Parfois, les outils automatisés présentent un danger: ils examinent des éléments de manière isolée ou une interface de manière isolée et ne voient pas le contexte plus large

Heydon: Oui. [19659009] Drew: En ce qui concerne l’utilisation de phare pour les audits de performance, il peut arriver que je prenne la décision en tant que développeur d’inclure, il peut y avoir beaucoup plus de CSS que celui utilisé sur cette page, et à vrai dire, je télécharge trop CSS, mais en réalité, je sais qu’une fois le fichier chargé, au moment où l’utilisateur passe à la page suivante, il dispose déjà du CSS. Donc, c’est une optimisation qui est faite sur plusieurs pages, l’outil, regardant une page séparément, est une erreur.

Heydon: Oui, absolument. Vous pensez à l'avenir et vous faites appel au jugement, et jusqu'à ce que nous ayons une intelligence artificielle avancée pour anticiper cela, alors oui, vous avez vraiment besoin que des êtres humains l'examinent, le parcourent et s'en vont… Je veux dire, 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 exister une formation si vous êtes intéressé par une organisation qui se soucie réellement de vous et qui rend les choses plus inclusives et plus accessibles. . Il faut qu'il y ait des questions.

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 elle avec un lecteur d’écran et ne la parcourez pas réellement. Donc, lorsque vous faites cela, cela devrait arriver. Quand vous faites cela, cela devrait arriver. Quand vous faites cela, cela devrait apparaître », ou ce genre de choses. Ainsi, et comme vous le dites, les outils automatisés n’en sont pas conscients. Ils se contentent de voir: «Oh, il n’ya pas d’autre texte ici.» Et en fait, dans de nombreux cas, il ne devrait peut-être pas y avoir d’autre texte. Et aussi, il ne peut pas juger si vous avez bien écrit le texte alternatif ou non. Donc, je pense qu'une image sans tout texte alternatif est probablement meilleure qu'une image avec un texte alternatif trompeur ou simplement mauvais.

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

Heydon: Je pense uniquement en ce sens que, parce que vous avez un composant dont l’idée bien sûr, dans tous les cas et pas seulement en termes d’accessibilité, c’est que vous avez défini ce composant à un endroit qui sera ensuite utilisé à des endroits différents, du moins lorsque les aspects ou la prise en charge du navigateur ou quoi que ce soit changent et que vous souhaitiez mettre à jour le logiciel. composant, vous ne devez le faire qu’à un seul endroit, puis l’amélioration ou le changement se fera sentir. Donc, de ce point de vue, je pense qu’il est certainement plus utile de diviser les éléments en composants.

Heydon: Mais alors, oui, comme je l’ai dit, cela n’affecte pas uniquement l’accessibilité, cela peut affecter tout ce qui change. Mais ensuite, je ne suis pas vraiment sûr de l’ampleur des changements dans son… Je veux dire, il y aura peu de changements de dernière minute en termes d’accessibilité HTML, ce qui, de toute évidence, est un domaine très étroit. Mais en ce qui concerne la qualité du code ou son fonctionnement, les éléments sont introduits dans la spécification HTML, bien évidemment, très lentement et pas aussi lentement mais assez lentement également dans la spécification ARIA. Et puis, une bonne partie de l’ARIA ne fait que refléter ce qui se trouve dans le HTML de base sous-jacent.

Heydon: Je pense que, plus encore que la technologie, la perception et la compréhension de ces choses ont tendance à changer avec le temps. L’enquête WebAIM a récemment révélé 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 rendait la situation encore pire. Donc, c’est vraiment un manque de connaissances, et non de manque de technologie. Ce sont simplement des personnes qui utilisent la technologie et en abusent parce qu’elles ne comprenaient pas vraiment comment elle était censée fonctionner, malheureusement. J'espère que certains de mes écrits pourront m'aider. De toute façon, dans certains domaines.

Drew: Mais une sorte de système à base de composants bien structuré vous le permettrait, une fois que vous réaliserez que quelque chose est obsolète ou que vous avez pris une mauvaise décision et que vous en savez plus maintenant. , vous permettrait plus facilement de résoudre ce problème dans votre application.

Heydon: Ouais, exactement. Oui, oui, absolument. Je veux dire, tout est question d’efficacité, n’est-ce pas? Et ce principe aride ou ce que vous avez et voyez, c’est la raison pour laquelle je suppose que j’étais initialement très enthousiaste à propos de cette opportunité, car les gens se plaignent toujours de rendre les choses accessibles, c’est un travail supplémentaire qui est difficile et qui dérange et tout le reste. Et c’était donc une sorte d’occasion de dire: «Eh bien, vous savez comment vous fabriquez ce matériel de manière vraiment efficace pour construire ces systèmes de composants? Obtenez votre accessibilité pour ce composant que vous fabriquez et vous n'aurez plus à vous soucier de l'accessibilité, hormis quelques modifications ou mises à jour occasionnelles des spécifications, ou autre chose du genre. ”

Heydon: Ou simplement, je veux dire, probablement la plupart du temps, l'itération sera simplement basée sur les commentaires des utilisateurs et sur la recherche en cours, que vous devriez évidemment, autant que possible, mener avec un groupe diversifié de personnes. Vous devriez donc trouver des personnes qui utilisent des appareils différents, qui ont des habitudes de navigation différentes, des technologies d'assistance différentes, etc. Et vous savez, les choses vont sûrement arriver tout le temps. Je pense que j’ai vraiment épinglé un composant, je le trouve vraiment solide, puis j’ai fait un peu de recherche et j’ai trouvé que j’avais fait de mauvaises hypothèses. Mais oui, avec un système de composants, il suffit de le réparer au même endroit.

Drew: Un composant peut-il être totalement inclusif ou s'agit-il d'un spectre dans lequel vous ne faites que travailler de plus en plus vers l'inclusivité? ] Heydon: Oui, il serait possible pour un composant d’être exempte d’erreur de la part de la WCAC, il répond à tous les critères de la WCAC, mais comme je l’ai dit, cela ne vous mène jusqu’à présent et peut encore être totalement inutilisable ou impossible à comprendre même avec les critères techniques respectés. 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 de la conception, qu’elle fait partie du processus de conception et que rien ne peut être parfaitement conçu, comme rien ne peut être parfaitement accessible. Malheureusement, beaucoup de gens pensent à cela simplement pour s'assurer qu'il est compatible avec les lecteurs d'écran, ce qui est évidemment un domaine très étroit en termes d'accessibilité et d'inclusion en général.

Heydon: Il y aura donc des gens avec qui j'ai travaillé, comme le groupe Paciello, qui diraient: «En fait, je veux être connu en tant que personne accessible à l'UX.» Il ne s'agit donc pas uniquement de cela. case à cocher exercice, il s’agit plutôt d’essayer de rendre l’expérience meilleure et plus valable pour un plus grand nombre de personnes et de s’orienter davantage vers une sorte de principes plus larges et d’objets moins binaires. Mais finalement, c’est tout cela, et WCAC et d’autres critères de ce type ne peuvent vraiment identifier que ce qui est réellement et durement, je suppose.

Drew: Donc, si je suis un développeur, Que dois-je faire différemment lorsque j'aborde la façon dont je conçois, planifie et construis un composant? Y a-t-il quelque chose que je devrais envisager dans mon travail pour m'assurer que cet élément finira par être aussi inclusif que possible?

Heydon: Je veux dire, selon ce que vous construisez, il y a vont être différents critères qui doivent être remplies. Ainsi, par exemple, tous les composants ne pourront pas avoir une imagerie accessible avec un texte alternatif, car ils pourraient ne pas utiliser l’imagerie du tout. Cela pourrait simplement être basé sur du texte ou ce que vous avez. Certains pourraient ne pas être interactif. Donc, en termes d'exigences spécifiques, cela changerait d'un élément à l'autre, mais j'espère que certains de mes écrits et ce que le livre Inclusive Components vous aide à faire sont de tomber ou d'adopter une sorte de discipline consistant à simplement penser de manière inclusive. 19659008] Heydon: Ainsi, lorsque vous abordez ce sujet, vous ne vous contentez pas de penser, eh bien, vous sortez simplement de la mentalité suivante: «Si cela fonctionne pour moi, cela fonctionne probablement pour tout le monde», parce que c'est simplement pas le cas que la façon dont vous ou moi parcourons les choses, je veux dire, nous ferons probablement les choses complètement différemment, juste nous deux, non?

Drew: Exact.

Heydon: Et nous sommes occidentaux, blancs, anglais comme première langue. Et donc, oui, la diversité des personnes qui consomment ceci, je veux dire des personnes de performance parlent toujours de cela aussi, des personnes qui sont intéressées à plaider pour une meilleure performance. Vous êtes habitué à utiliser une configuration de haut niveau sur un bon réseau et nombre de vos utilisateurs, ou de nombreux utilisateurs potentiels, ne le seront certainement pas, tout comme l’accessibilité. En fait, il s’agit simplement de ne plus penser à vous-même. Littéralement juste ça. Et essayez, évidemment, d’aller au-delà de vos collègues immédiats et des personnes de votre même groupe social.

Heydon: Alors, espérons-le, c’est vraiment juste: «Voici ce que j’ai résolu pour ce genre de choses» et 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. Espérons que 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, quand vous concevez quelque chose de complètement différent, utilisez peut-être simplement le même genre de pensée et essayez d'ouvrir votre esprit à la diversité des utilisateurs et à la façon dont ils procèdent. 19659009] Drew: Le livre lui-même, comment avez-vous décidé de le structurer?

Heydon: De la même manière que le livre précédent, il s'agissait en fait de Inclusive Design Patterns et j'ai eu beaucoup de difficulté à le lire, pour commencer, parce que j’ai essayé de l’organiser en termes de critères abstraits. J'ai donc commencé par écrire un chapitre consacré à l'accessibilité au clavier, mais c'était très difficile, car à chaque fois je parlais d'un type différent d'accessibilité au clavier ou de ce à quoi vous devez penser.

Heydon: Il était donc plus logique pour moi d'organiser les choses en fonction des composants eux-mêmes. Donc, Inclusive Design Patterns fait cela et maintenant Inclusive Components n’est en réalité qu’une continuation, qui couvre seulement différents composants. C’est différent en ce qui concerne les fonctionnalités, c’est un peu différent, car il inclut également des exemples de code en direct et d’autres choses, ce que je n’ai pas beaucoup fait pour les livres précédents. Mais oui, il s’agit littéralement de «nous allons faire ce composant», qu’il s’agisse d’une interface tactile, d’une section réductible, d’un commutateur de thème, d’une carte flash de notification ou d’un grille-pain, peu importe le nom, et ainsi de suite. est ensuite organisé autour de cette composante.

Heydon: C’est donc: “C’est ce que nous faisons et c’est ce que nous devrions considérer en même temps que nous le faisons pour être plus inclusif”, car c travailler et c'est comme ça que les autres travaillent. Et dès que j'ai commencé à le faire comme ça, c'était vraiment juste moi qui travaillais et écrivais des notes pendant que je travaillais. Et donc, la chose a en quelque sorte été écrite, et tous les efforts ont été faits pour que je fasse un travail décent en rendant ces choses non inaccessibles, je suppose.

Drew: Oui, Je veux dire que la table des matières se lit vraiment presque comme de la documentation ou comme un manuel d’auto-assistance ou quelque chose du genre. Droit avec le chapitre un, boutons à bascule. Si vous souhaitez implémenter des boutons de basculement, consultez ce chapitre, lisez-le et vous obtiendrez tout ce dont vous avez besoin de savoir sur la façon de procéder, une approche que j’aime beaucoup. Je vois des choses comme des sections réductibles, une interface à onglets, des commutateurs de thèmes, des tableaux de données, une multitude de choses réelles et pratiques que nous construisons tous les jours et je pense que nous pourrions probablement tous construire mieux.

Heydon: Oui, c'était une idée totale, car il ne s'agissait pas uniquement de fabriquer mes composants. Il s'agissait d'un cas, et vous en avez parlé, ce que je suis heureux que vous ayez fait. modèles que nous utilisons tous. Donc, je veux dire, il y a des interfaces de tabulation partout et elles sont toutes implémentées différemment et très différemment. Je veux dire, j’ai implémenté des interfaces de tabulation terribles et que j’ai appris un peu à quel point elles étaient mauvaises pour les gens, puis j’ai essayé de les améliorer un peu plus et encore mieux. J'ai probablement créé 15 ou 16 versions différentes d'interfaces d'onglets depuis des années.

Heydon: Et vous savez, elles s'améliorent un peu, espérons-le, à chaque fois. But it is just a common thing. It was a common thing that I would use quite often between different websites, I use and everyone uses. So, part of the idea was to say, “Well, actually, let’s do a design system, kind of an accessible design system for the web.” Now, people are going to branch out and they’re going to do their own versions of these things, but to kind of get the core stuff down and the accessibility is a core thing that should be in things. It shouldn’t be an add on, it shouldn’t be an either/or, it shouldn’t be a feature. It should be a core thing. And if you get that core stuff paired down, then yeah, hopefully people would look at the chapters and go, “Oh, okay, I’ve made those. I’ve seen those. Let’s see how to do it as inclusively as possible,” and then hopefully they get some value from that.

Drew: Well, what I like about it is, certainly I know I’ve, in the past, I’ve had some interface features I’ve needed to implement and I know that it’s going to be tricky from an accessibility point of view, say some sort of a fly out menu, drop down menu, something like that. I think, “Okay, here be dragons in terms of accessibility. I need to make sure I do this right.” And so, I Google for how to do it, I find a reputable source saying, “Use this method,” I use that method, I implement it and I move on, but I actually haven’t learnt anything. I haven’t learnt why the solution was that. And what I really like about the way you go into it in the book is I can do two things at once. I can figure out how I should be doing it and I can figure out why I should be doing it like that because it’s all very carefully explained. So, I think it’s really successful from that point of view.

Heydon: Oh, great. That was what I was going for. So that’s good. 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. Yeah.

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.

(dm, ra, il)