与 Heydon Pickering 合作的 Smashing Podcast 第 4 集：什么是包容性组件？

今天，我与 Heydon Pickering 就他的新书Inclusive Components进行了交谈。 Heydon 以其关于可访问性的工作和写作而闻名——那么“包容性设计”的真正含义是什么？组件在哪里发挥作用？ 海顿在这一集中解释了所有这些以及更多内容。 您可以在下面收听，或在任何获得播客的地方订阅。

显示注释

• Smashing Magazine 的Inclusive Components一书
• Heydon 与 Andy Bell 合作的Every Layout项目
• Heydon 的网站 Heydonworks
• 海顿在推特上

成绩单

Drew McLellan：他是一名自由网页可访问性顾问、界面设计师和作家。 他的工作重点是无障碍用户体验设计，以及 Smashing Magazine 的写作和编辑。 他是广受好评的关于可访问 Web 应用程序设计的书籍 Apps For All 的作者，并且刚刚与 Smashing Magazine 一起发布了一本新书 Inclusive Components，所有关于如何构建可访问 Web 界面的内容。 所以他显然是无障碍设计方面的专家，但你知道他是第一个乘坐快艇跳过悉尼海港大桥的男性吗？ 我的 Smashing 朋友，请欢迎 Heydon Pickering。 嗨，海登。 你好吗？

海顿·皮克林：我太棒了。 我在品牌。

Drew：我今天想和您谈谈您的新书《包容性组件》的主题。

海顿：是的。

德鲁：显然只是一个两个词的标题，但我觉得每个词都做了很多繁重的工作。 从最后开始，显然是合乎逻辑的，组件，这是关于基于组件的设计吗？ 那是什么？

Heydon：是的，所以我想现在已经有一段时间了，因为人们、前端开发人员、设计师和所有合作制作界面的人开始从组件的角度来思考事物，并将事物分成可消化和可重复使用的小块。 而且我想如果你不熟悉这种工作方式，无论出于何种原因，它真的有点像电子元件。 我的父亲是一名电子工程师。 他在电路板和焊料之类的模拟世界中工作。

Heydon：事实上，他已经制造了一些组件，非常小的组件，用于调节 CERN 进入电磁体的电流。 他小时候对我很有信心，因为他让我为他们实际焊接了一些零件。 我认为那批现在已经退役了，所以不用担心我的焊接不好，我的青少年焊接不好，不再参与欧洲核子研究中心。 但是，是的，我认为它类似于......哦，那里有太多的类似物。

Heydon：这类似于模拟电路板，其想法是您对单个零件或组件负有单一责任，它们一起构成电路，并且它们一起增加电路中的电流，或者，我猜，界面或结果以任何方式，在设计系统中或在通过设计系统表现的界面中。 所以，包容性组件，因为我想解决这样一个事实，虽然，我的意思是，当我们推进我们在不同领域所做的事情时，可访问性确实往往会被抛在后面，我想带来可访问性，并且在更广泛的范围内感觉，包容性设计与这种新的思维方式有关，并使用组件或模块或任何你想称呼它们的东西来制作东西。

Heydon：所以这个想法是为设计系统带来可访问性，但出于同样的原因，在尝试解决可访问性问题时要系统地思考。 考虑在可访问性方面在一个地方解决一种问题，并确保它简单地在整个设计系统的模式 [听不清 00:03:16] 中传播。

Drew：从某种实际意义上说，以基于组件的方式工作实际上是什么样的？ 组件的示例可能是什么？

Heydon：所以，有不同的方式来构思和编码组件。 我倾向于直接进入它的本质，超越概念性的东西，思考我如何组织代码。 实际上，我已经非常关注自定义元素，或者如果不是自定义元素，那么就是普通元素，但以一种孤立的、组件化的方式附加了一种 JavaScript 行为。 我真的很喜欢可互操作的组件的想法。 我的意思是，它们可以在不同的框架、系统、方法和技术堆栈中使用。 自定义元素在这方面很好，因为它们是原生的。 你可以在一个地方定义它们，然后它们可以用在一个反应​​应用程序中，或者它们可以用在一个视图应用程序中，或者它们可以用在一个角度应用程序中，或者你所使用的任何类型的更大的状态管理技术使用。

Heydon：所以对我来说，通常一个组件可能是一个自定义元素。 我最近在一个项目上工作，该项目不太关注可访问性，尽管我试图使其尽可能易于访问，称为 Every Layout，这一切都是为了尝试隔离非常特定类型的算法CSS 布局。 它们被定义为自定义元素，它们可以自行部署并运行自己的 CSS，并在更大的系统中像原语一样工作。

Drew：我的意思是，实际上，我们所说的组件可能类似于表单域？

Heydon：是的，所以它可以像输入一样简单。 比如说，就像一个文本输入，或者它可能是一个复杂的东西，比如一个选项卡界面。 因此，包容性组件的想法是采用一个组件的概念，希望它具有单一目的，例如文本输入，然后考虑所有可能绊倒不同类型的人并尝试避免的不同事物他们。 不回避人，回避问题。 与其说包括人，不如说是尽量不武断地排除人。

Heydon：对我来说，这似乎是实现包容性设计过程的最简单方法，即识别某事物的潜在排他性元素并尝试绕过它们。 因此，对于文本输入和标签，您可能需要担心许多不同的事情。 因此，您首先要知道它是否实际上已正确标记。 那么您是否使用标签元素，并且该标签元素是否使用 for 属性指向文本字段，以便以编程方式关联这两个内容，以便当屏幕阅读器用户关注输入时，他们实际上听到了正在宣布的标签？ 所以这是一回事。

Heydon：然后，在某种更直观的层面上，确保标签清楚地与该字段相关联，而不是与不同的字段相关联，这是一个空白和这类东西的问题。 此外，确保标签不是，你不会做一些花哨的事情，比如将标签放在他们的表单输入下面，因为当你，例如，当虚拟键盘出现时，它可能会变得模糊。 所以，它正在考虑这些事情。

Heydon：确保输入本身具有焦点样式，因此当您使用键盘对其进行对焦时，无论您是使用键盘导航的习惯键盘用户还是其他方式，请确保从焦点样式中清楚地知道那是您关注的输入。 确保，我的意思是，诸如自动完成之类的事情，担心自动完成在上下文中是否合适和有用，或者是否不是。 很多这些东西直接解决了残疾问题，但其中很多在可用性方面更广泛，只是让事情尽可能容易理解。

Heydon：很多时候，在解决每个人的可用性问题和解决残障问题之间存在一种非常细微的界限，或者可能是模糊的界限。 然后，更难以确定的是认知障碍。 因此，如果某些东西对于没有认知障碍的人来说不是很有用，那么它将会更加难以锻炼并能够用于那些确实有这些挑战的人。

Heydon：所以它只是试图在一个地方考虑​​所有这些事情。 真的，这本书只是我的，这是我在接近每一本书时的思考过程。 所以我一开始是把它作为一个博客来做的。 每个模式或每个组件都是一篇博客文章，文字只是我想说的，“所以，现在让我们解决这个潜在的问题。 我们该怎么做呢？ 好的，我们已经检查过了。 我认为我们在那里还好。” 而且，我绝不是想说这些是完美的，我已经想到了一切，因为那是不可能的。

Drew：我想，采用基于组件的方法来处理界面的各个部分也是如此，它可以让您深入研究该特定项目，并确保您以最佳方式对其进行了真正的优化可以让每个人都可以访问它。 在许多不同的组件上这样做，然后将它们全部放在一个页面上，这样做有危险吗？ 是否存在由于您单独而不是一起测试而产生您没有意识到的问题的危险？

Heydon：这是一个非常好的观点，实际上我会更早地提出这一点。 我很高兴你这么说。 所以，在很多方面，我认为从哲学上讲，我们已经决定需要将事物分成这些单独的组件。 这样做是有好处的，因为如果它是孤立的，那么就更容易进行测试并将其视为一个单一的东西。 就我们的工作方式而言，你可以让事情变得更容易管理。 我们还必须考虑这样一个事实，即这些东西最终必须共享同一个空间并连接到一个更大的系统中。

Heydon：而且我认为，实际上，我们的努力和思考还不够多，有趣的是。 我认为我们将事物更多地组件化以使我们作为工程师的生活更轻松，以便我们知道我们在什么时间工作。 而且，但是，我们经常忽略这样一个事实，即这些东西将生活在动态系统中，而且它们必须……

Heydon：我的意思是，Every Layout 项目，虽然它更多的是关于视觉设计和布局，但都是关于尝试制作这些小的 CSS 原语，这些小的布局原语，以便它们可以通过算法进行自我管理。 这样您就可以将它们从窄列中取出，然后将它们放在宽列中，然后代码本身将确定应该有多少并排的项目，或者是否应该以其他方式重新配置自己。 因为我们不能经常干预，我认为它必须是一个有自知之明和智能的系统。

Heydon：总有一些你可以忘记的事情。 所以也许你做一个标签界面，你有一行标签，你在标签之间选择，标签对应一个标签面板，打开一些东西。 然后，有人会过来，他们会说，“好吧，如果我想把一个选项卡界面放在一个选项卡界面里面，或者把其他组件放在一个点击界面里面呢？”

Heydon：当然，我的意思是，这在一定程度上是一个技术问题，这是否可行，但是，是的，你必须做出选择，是否要让事情变得尽可能灵活，这样才能做到可能以复杂的方式将事物叠加在一起，或者只是编写硬规则，说“你不能把东西放在这里，因为代码的复杂程度可能太高了，但也可能在用户如何感知和使用这个东西。” 我完全赞成编写这样的规则：“不要在自身内部嵌套大量复杂的功能”，因为人们不太可能真正理解它。

Drew：是否可以采用完全算法或自动化的方法来设计可访问性？

海顿：我不这么认为。 不。所以我们有自动化工具，我不想以任何方式贬低自动化工具。 我认为它们非常有用，但我将它们用作一种早期预警系统来尝试了解问题区域的位置。 因此，如果我正在为一个想要就如何使他们的产品更容易获得的建议的组织进行审计。 因此，在有问题的地方，这是一种很好的融资方式，但我的意思是，你可以拥有一个技术上 100% 可访问的界面，也许，根据某些工具，甚至是判断它的好工具，例如，针对 WCAG 、Web 内容可访问性指南或其他一些接受规范。 而且，即使它是 100% 选中的所有框，它仍然可能由于各种原因完全无法使用。

Heydon：例如，回到我们之前所说的，它可能太复杂了。 您可以通过链接压倒某人，而他们无法通过它，然后就变成了，这是一种非常默契且难以确定的事情，但这势必会疏远人们。 但你也可以得到，很容易得到误报之类的东西。 前几天我有件事，前几天我说，那是前一个月，我在一个组织工作，当然他们希望有一个 100% 可访问的灯塔学校，并且有一个 iframe 动态放置在那里通过分析脚本或其他东西。 你知道它是某种稍微粗略的代码，它只是被夹在页面中以完成类似的任务。

Heydon：现在我建议根本不使用分析，我建议他们至少支持不跟踪协议，以便人们可以选择退出。 不幸的是，该协议有点，不再真正起作用，因为它从未真正得到正确支持。 但是这个 iframe，它说它上面没有标题。 所以这个想法是，如果你有一个 iframe，它应该有一个 title 属性，因为这是识别 iframe 对屏幕阅读器用户的用途的最佳方式。 但这是一个也设置为不显示的 iframe，因此屏幕阅读器一开始甚至无法察觉，因为不显示，就像它在屏幕阅读器中以视觉方式隐藏内容一样，它基本上会将其从接口，因此不会以任何方式遇到或宣布。

Heydon：所以这是一个误报。 我的意思是，它要求我识别一个最初不存在的 iframe。 因此，在自动化测试中总会出现这类错误和问题。 但归根结底，它是关于了解，尽管我猜这只是程序员不喜欢认为他们参与其中并且觉得有点恶心的事情，但它是关于人类行为和关于人们如何理解事物，而仅拥有一组二进制或布尔类型的规则是一件非常困难的事情。

Heydon：所以，我的意思是，我前段时间在咨询这个问题时与一位开发人员交谈过，他们一直说，“好吧，只要我们有自动化测试，我们就很好，不是吗？ 只是，然后我们就可以继续前进。” 我说，“你仍然需要手动测试。 没有任何自动化测试可以真正告诉您通过键盘使用界面是否以某种方式是不可能的。” 您可以寻找一些离散的东西，但整体体验仍然需要人类来判断。 是的。

Drew：有时使用自动化工具的危险是他们孤立地查看项目，或者他们孤立地查看一个界面而没有看到更广泛的上下文。

海顿：是的。

Drew：当然，使用 Lighthouse 进行性能审计，有时我作为开发人员可能会决定包含，可能有比该页面上使用的更多的 CSS，严格来说，我下载了太多 CSS，但实际上，我知道一旦加载了该文件，当用户浏览到下一页时，他们已经获得了 CSS。 因此，这是一种跨多个页面进行的优化，该工具在孤立地查看一个页面时将其视为错误。

海顿：是的，绝对的。 您正在提前思考并做出判断，直到我们使用高级人工智能来预测这一点，然后是的，您确实需要人类来观察它并经历它并继续……我的意思是，所以自动化测试应该正如我所说，建立一种早期预警系统、诊断系统，但也应该有，如果你对你的组织真正关心并让事情更具包容性和更容易获得感兴趣，那么还需要培训. 需要有问答。

Heydon：所以我会写脚本，“当你用键盘与这个组件交互时，它应该是这样工作的”，或者，“当你用屏幕阅读器与它交互而不是实际单步执行时，它应该是这样工作的它。 所以，当你这样做时，这应该发生。 当你这样做时，这应该发生。 当你这样做时，它应该会出现”，或者诸如此类的东西。 因此，正如您所说，自动化工具并没有意识到这一点。 他们只会看到，“哦，这里没有替代文字。” 实际上，在很多情况下，也许它不应该有替代文本。 而且，它不能判断你是否写好替代文本。 所以我认为没有所有替代文本的图像可能比具有误导性或只是糟糕的替代文本的图像更好。 这又是一个判断电话，不是吗？

Drew：从历史上看，在以一种可访问的方式构建事物时，我一直在努力解决的一件事就是让我对最佳实践的了解保持最新，因为每次我参考任何文档或任何类型的建议时，它看起来我在做什么，并认为我在做正确的事，建议已经继续，现在我应该做其他事情。 这是一个熟悉的故事，适用于网络工作的所有领域。 但我认为，当然，可访问性问题是危险的，如果你没有遵循最佳实践，如果你在界面中留下一些现在不是好的实践的东西，这可能会对你的用户产生负面影响大大地。 构建界面或站点的基于组件的方法是否有任何帮助？

Heydon：我认为纯粹是从某种意义上说，因为你有一个组件，那么当然，在所有情况下，不仅仅是在可访问性方面，这个想法是你将这个组件定义在一个地方，然后在不同的地方使用地方，至少当方面或浏览器支持或任何它发生变化并且您想要更新组件时，您只需要在一个地方执行它，然后无论在哪里使用它，都会感觉到增强或更改。 所以从这方面来说，我认为将事物分成组件肯定更有用。

Heydon：但是，是的，正如我所说，这不仅会影响可访问性，还会影响任何变化。 但是，我不确定它到底有多少变化……我的意思是，在 HTML 可访问性方面几乎不会发生重大变化，这显然是一个非常狭窄的领域。 但就代码质量或代码的工作方式而言，HTML 规范中引入了一些东西，显然，非常缓慢，而不是那么慢，但在 ARIA 规范中也相当缓慢。 然后，ARIA 的大部分内容只是反映了底层基线 HTML 中的内容。

Heydon：我认为，比技术更重要的是，对这些事物的感知和理解往往会随着时间而改变。 我的意思是，最近在 WebAIM 调查中，他们发现使用 ARIA 的网站比不使用它的网站更难以访问。 因此，为了帮助人们使网站更易于访问而专门设计的这项技术正在使情况变得更糟。 所以真的，这只是知识差距，而不是技术差距或技术缺陷。 不幸的是，人们只是采用并滥用该技术，因为他们并没有真正理解它的工作原理。 希望我的一些文章能对此有所帮助。 无论如何，在某些领域。

德鲁：但是一种结构良好的基于​​组件的系统可以让你，一旦你意识到某些东西已经过时或者你做出了错误的决定并且你现在知道得更好，会让你更容易进入并修复它在您的应用程序中。

海顿：是的，没错。 是的，是的，绝对的。 我的意思是，这一切都与效率有关，不是吗？ 这个枯燥的原则或者你有什么，看，这就是为什么我想我最初对这个机会感到非常兴奋，因为人们总是抱怨让事情变得可访问是额外的工作，这很困难，而且令人沮丧等等。 因此，这是一个机会说，“嗯，你知道你是如何真正地、有效地构建这些组件系统的吗？ 为您正在制作的那个组件获取可访问性，然后您不必再担心可访问性，除了偶尔的规范更改或更新或您拥有什么。”

Heydon：或者只是，我的意思是，可能大多数时候，迭代将简单地基于用户反馈和正在进行的研究，显然，你应该尽可能多地与不同的人一起进行。 所以，你应该让人们使用不同的设备，有不同的浏览习惯，使用不同的辅助技术等等。 而且你知道，事情一定会一直出现。 我想我真的确定了一个组件，认为它真的坚如磐石，然后我做了一些研究，我发现我做了一些非常糟糕的假设。 但是，是的，使用组件系统，您只需在一个地方修复它。

德鲁：一个组件是否可以完全包容，或者它是一个你正在努力实现包容性的频谱？

Heydon：是的，一个组件有可能是，假设 WCAC 没有错误，它符合所有 WCAC 标准，但正如我所说，这只需要你到目前为止，它仍然可能完全无法使用或即使满足了这些技术标准，也无法理解。 所以，是的，这是我经常谈论的事情。 我试图让人们相信可访问性就像任何其他设计领域一样，它只是设计过程的一部分，没有什么可以完美设计，就像没有什么可以完美访问一样。 我认为，不幸的是，很多人认为它只是为了确保它与屏幕阅读器兼容，这在可访问性和包容性方面显然是一个非常狭窄的范围。

Heydon：那么，会有一些人，比如我在 Paciello Group 共事过的一些好人，他们会说，“实际上，我想被称为一个易于理解的 UX 人。” 所以这不仅仅是关于这个方框打勾练习，它更多的是关于实际尝试让更多的人获得更好和更有价值的体验，并更多地朝着更广泛的原则和不那么二元的事物迈进。 但最终，仅此而已，WCAC 和其他此类标准只能真正确定真正的硬性因素，“这是错误的”，我想。

Drew：那么，如果我是一名开发人员，当我着手设计、规划和构建组件时，我应该做些什么不同的事情？ 在我的工作中我应该考虑什么以确保该组件最终尽可能具有包容性？

Heydon：所以，我的意思是，根据您正在构建的内容，需要满足不同的标准。 因此，例如，并非每个组件都将具有可访问的带有替代文本的图像，因为它可能根本不使用图像。 它可能只是基于文本的，或者你有什么。 有些可能不是交互式的。 因此，就具体要求而言，它会在组件之间发生变化，但希望我的一些写作和包容性组件一书可以帮助您做的是陷入或采用包容性思考的学科。

Heydon：所以，当你接触这些东西时，不要只是想，嗯，基本上只是摆脱“如果它对我有用，它可能对其他人也有用”的心态，因为事实并非如此你或我浏览事物的方式，我的意思是，我们可能会做完全不同的事情，只有我们两个，对吧？

德鲁：对。

Heydon：我们是西方白人，英语为第一语言的人。 所以，是的，就消费这个的人而言，多样性的数量，我的意思是表现的人也总是谈论这个，那些有兴趣倡导更好表现的人。 您习惯于在良好的网络上使用高规格设置，并且您的许多用户或许多潜在用户肯定不会这样做，并且可访问性也是如此。 基本上，这只是一个问题，真的，只是摆脱对自己的思考。 字面意思就是这样。 显然，还要尝试超越您的直接同事和同一社会群体中的人。

Heydon：所以希望这真的只是，“这就是我为这些东西解决的问题”，以及我当时的想法。 如果这对您有用或相关，您可以重复使用其中一些想法并准确应用我应用的内容。 希望这本书更多地是关于，“这是一个尝试包容性思考的人的案例研究。 看，他们正在考虑的事情，当你设计完全不同的东西时，也许只是采用相同的思维，并尝试对用户的多样性以及他们如何做事敞开心扉。”

德鲁：所以这本书本身，你是如何决定如何组织它的？ 它看起来非常实用，我喜欢在一本书中，但是你是如何组织它的？

Heydon：与上一本书非常相似，实际上是包容性设计模式，我从那本书开始遇到了很多麻烦，因为我试图按照抽象标准来组织它。 所以我开始写一个关于键盘可访问性的章节，但这非常困难，因为我不得不有点，每次我谈到不同类型的键盘可访问性或你必须考虑的事情时，然后我不得不变出某种组件，然后抛弃该组件，然后转移到其他东西上。

Heydon：因此，对我来说，根据组件本身来组织事物更有意义。 所以，包容性设计模式做到了这一点，现在包容性组件实际上只是一个延续，它只是涵盖了不同的组件。 不同之处在于，就功能而言，它有点不同，因为它还包括实时代码示例和东西，我在前几本书中没有做太多。 但是，是的，它实际上只是“我们要做这个组件”，无论是点击界面、可折叠部分、主题切换器、通知闪存卡、烤面包机或其他任何名称，然后就是所有内容然后围绕该组件进行组织。

Heydon：所以它是，“这就是我们正在做的事情，这些是我们在做这件事时应该考虑的事情，以使其更具包容性”，因为这就是我的工作方式，也是其他人的工作方式。 当我开始那样做时，实际上只有我在工作并在工作时写笔记。 所以，事情是自己写的，然后所有的努力实际上只是确保我做得很好，使这些东西不会无法访问，我猜。

Drew：是的，我的意思是目录读起来几乎像文档或自助手册之类的东西。 直接进入第一章，切换按钮。 如果您想实现一些切换按钮，请转到本章并阅读它，您将获得有关如何执行此操作所需的所有信息，这是我非常喜欢的一种方法。 我看到了诸如可折叠部分、选项卡式界面、主题切换、数据表、大量实际的、真正实用的东西，我们每天都在构建，我认为我们都可能会构建得更好。

Heydon：是的，这完全是我的想法，因为这不仅仅是关于我制作我的组件，它是一个案例，你已经触及了它，我很高兴你这样做了，这是为了识别常见的我们都使用的模式。 所以我的意思是，到处都有选项卡界面，它们的实现方式都不同，而且它们的实现方式各不相同，非常糟糕。 我的意思是，我已经实现了糟糕的选项卡界面，并且我已经了解到它们对人们有多糟糕，然后我试图让它们变得更好一点，更好一点，再好一点。 我可能已经制作了 15 或 16 个不同版本的选项卡界面，多年来一直在做这种事情。

Heydon：而且你知道，他们每次都会变得更好，希望如此。 但这只是一件普通的事情。 这是我经常在不同网站之间使用的常见东西，我使用并且每个人都使用。 所以，想法的一部分是说，“好吧，实际上，让我们做一个设计系统，一种可访问的网络设计系统。” 现在，人们将进行分支，他们将做他们自己的这些东西的版本，但是把核心的东西放下来，可访问性是应该存在的核心东西。 它不应该是一个附加组件，它不应该是一个非此即彼的/或，它不应该是一个功能。 应该是核心的东西。 如果你把核心内容配对，那么是的，希望人们会看这些章节然后说，“哦，好吧，我已经做了这些。 我见过那些。 让我们看看如何尽可能包容地做到这一点，”然后希望他们从中获得一些价值。

德鲁：嗯，我喜欢它的地方是，我当然知道我过去有一些需要实现的界面功能，而且我知道从可访问性的角度来看它会很棘手，比如说某种飞出菜单、下拉菜单之类的东西。 我想，“好吧，就可访问性而言，这里是龙。 我需要确保我做对了。” 所以，我用谷歌搜索如何做，我找到一个有信誉的来源说，“使用这个方法，”我使用那个方法，我实施它，然后我继续前进，但我实际上什么都没学到。 我还没有明白为什么解决方案是这样的。 我真正喜欢你在书中介绍的方式是我可以同时做两件事。 我可以弄清楚我应该怎么做，我可以弄清楚为什么我应该那样做，因为这一切都得到了非常仔细的解释。 所以，从这个角度来看，我认为它真的很成功。

海顿：哦，太好了。 这就是我想要的。 所以这很好。 但是，是的，这似乎是我的事。 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. 是的。

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.