與 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. 可以試試嗎？” 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.