文章翻譯自 Spotify R&D | Engineering 部落格文章
前言：
為了避免針對 Accessibility 翻譯上的出入，本文內主要有兩種翻譯：「可訪問性」以及「無障礙」，分別用於下列情境：
- 「可訪問性」：用於描述功能或元件或期待的結果。
- 「無障礙」：用於描述概念。
角色概述以及名詞解釋：
- Encore：Spotify 設計系統團隊名稱。
- Tamas：無障礙專家(視障工程師)。
- Rose：Spotify 設計系統團隊 — 工程師。
- Arielle：Spotify 設計系統團隊 — 產品經理。
- Rebecca：Spotify 設計系統團隊 — 工程師。
【長文預告】以下正文開始…
在 Encore 團隊（Spotify 的設計系統）中，我們最喜歡與其他小組合作，原因有兩個：
- 他們有很棒的小組名稱。
- 他們有很棒的人。最近我們和「曼達洛人」小組進行了合作，他們負責 Spotify的無障礙設計，名字非常恰當，因為無障礙是「道路」。( 這裡應該是意味著「曼達洛人」(註 1) 小組正在開拓無障礙道路 )。
這個專案的目標是讓任何小組都能在他們的元件中盡可能地使用開箱即用的無障礙功能，若無法達成的話，至少提供實現完全無障礙體驗的最佳指導。實際上，這意味著盡可能使用建立於系統內的無障礙性元件，而當有例外或無法達成時也盡量提供指引文件。稍後您將會更多地了解這兩個極端之間的緊張關係，以及為什麼我們不能總是在元件級別強制執行無障礙性。
最近，我主持了一場關於我們的內部網頁無障礙專家 Tamas（他是視障工程師）與Encore 工程師 Rose 以及我自己（Arielle，Encore 的產品經理）之間的對話，談論了我們最近合作提升設計系統無障礙性的專案。
我們討論了這個合作的獨特之處，以及其他團隊可以從這個經驗中得到什麼啟示，特別是那些正在開發設計系統的團隊。以下是我們討論的文字紀錄。
Arielle (Encore 產品經理)：
在合作過程中，有哪些方法讓你們能夠一起工作？還有，第一次合作時，有什麼驚喜嗎？
Rose (Encore 工程師)：
我們在使用工具上花了一些時間進行迭代，Tamas向我解釋哪些是無障礙的，哪些不是。因為老實說，我只是假設所有的軟體是可用的，尤其是那些我們正在使用的付費的現成軟體。這些工具被如此多的人使用，所以它們理應且必須是無障礙的！但似乎並不是我所欲想的那樣，我的意思是，它們中「有一些方面」是無障礙的沒錯…
Tamas (無障礙專家)：
對，因此一開始，我們僅使用「問答」文件，這是我開始勾勒出實際情況的一種很好的方式。一直到我看到進度追蹤試算表，我覺得試算表很詳細地描述了現狀，我才想：「好的，這對目前哪些 ticket 是開啟的有很詳細的區分。」，至少是好的開始。
但我知道，作為一個工程師，我獨自提交 PR （Pull Request） 並不容易，因為我沒有整個文化和 Encore 團隊 PR 如何運作的整體情境。這可能需要更深入的探究。因此，如何與團隊更好地合作成了一個棘手的問題。
我初次的搭檔會議（註 2）是與 Rebecca（另一位 Encore 工程師）進行的。我們坐下來進行了約一個小時的會議，瞭解了一些情境和不同的程式碼，瞭解它如何撰寫，以及可能的不同結果。當事情真的有一些進展，接著有其他的工程師想來與我交流。。後來我開始可以查看 PR，並直接在聊天對話中與開發人員合作解決問題。使用這些可能是由成立僅四五年的小型新創公司創建的工具確實很困難。
Rose (Encore 工程師)：
能多談談你們的搭檔經驗嗎？主要是透過對話進行的嗎？
Tamas (無障礙專家)：
我們會通過聊天貼上程式碼片段。然後會將聊天記錄貼到我的 VS Code 中，我可以分享螢幕並說：「這是否與你正在寫的程式碼類似？」這確實創造了一種搭檔效果。但當我面試工作時會遇到困難，因為通常必須進行完整的搭檔開發會議，而且我無法追蹤 [面試官] 的游標。如果他們在我的程式碼中稍微修改了內容，我就會感到迷失方向。
有一些研究正在探索更新的方法，例如使用聲音提示和立體聲定位來指示某人在文件中的位置。在 Google 文件中真的很有用，因為我能夠使用這個附加元件。透過區分聲音大小，我可以隨時知道他們距離我的游標有多遠。
你可以將某人設定為吉他手、小號手、鼓手，讓不同的協作者扮演不同音效。這真的讓你有了一個即時獲得回饋的選項，螢幕閱讀器無法提供這類的功能，因為不能隨時觸發活動提醒。因此我認為解決這些不是那麼簡單。
Arielle (Encore 產品經理)：
我想接著你剛剛說的話再延伸討論，就是…這不是非黑即白的問題，對我來說這是這個專案的收穫之一。我之前一直以為無障礙只有合乎規範與否的問題，但實際上有很多灰色地帶，我們也有自己設計元件的極限。有時候，也只能相信產品團隊能夠按照寫在文件中的指引去執行，是嗎？
Rose (Encore 工程師)：
是的，因此設計系統的無障礙比產品的無障礙更具挑戰性，需要評估我們的程式碼並找出如何從情境中考慮問題。很多時候，純然地合乎規定並不能考慮到像 tab index 是有效的數字但在某處使用卻沒有意義這樣的問題。這是在設計系統中遇到的挑戰，因為所有東西都是模組化和零散的，而且我們的程式庫中所有元件都是無狀態的。我認為最具挑戰性的問題，都是與互動性有關的。
另一個值得關注的部分是，符合規範是有其重要性和必要性的，但要真正做到無障礙，我們會更傾向將其視為是使用者體驗。我們想像的不總是一般人認為的典型使用者，我們只是想提供最好的體驗。因此，這不是能透過自動掃描來測試的。
你不會把設計放到自動掃描中，然後說：「是的，這是最好的使用者導航佈局。」 Tamas 幫助我們瞭解可用的模式，比如，「也許透過 Tab 來進行所有互動的項目不是唯一選擇，或許某些情境中可以考慮左右方向鍵？」抑或使用某些類型的元素來說更標準的東西。
Tamas (無障礙專家)：
這是一個非常好的觀點 — 模組化的本質 — 你說得很對。這是最大的挑戰，當一個元件可以根據傳遞的屬性呈現多種形式時，很難預測它將如何被使用。我認為，我們仍然會在 Chip (Tag) 元件中遇到這個問題，因為它往往被用於各種零碎的事情。
我們會盡量設定更多預設值，以確保使用者無法對這個元件做出不對的行為。我們會嘗試預測可能出現的問題，使用語意化的 HTML 或角色，這些角色對應到正確的 HTML版本。有時因為樣式限制，無法使用語意化的 HTML，這通常是開發人員的另一個大問題。原生的 HTML 選項有時需要進行更多的樣式重新設計。甚至有時會有一些反彈聲音，例如：「我不想使用 button。我想使用 div，因為我不需要設置樣式，我可以用自己的樣式來刪除多餘的內容。」。
似乎蠻有道理的！但你也必須意識到，你需要為 space 鍵和 enter 鍵增加所有額外的監聽器。如果使用 button 角色，最終也可能仍需要使用原生的元素因而增加工作。即使是對於需要更多樣式化的元素，也存在維護額外程式碼的風險，這可能無意間會創造與使用原生標籤截然不同的體驗。
補充：MDN Web Docs 針對 Button 角色在無障礙設計的疑慮解說
但是對於 Encore 來說，最大的挑戰就是無法預測，不知道他們會如何使用這些元件，以及如何應用它們。我們能夠透過哪些措施來確保至少會有警示，來告訴使用者如果他們做了這些不好的事情，可能會對無障礙產生不良影響呢？
Rose (Encore 工程師)：
我越了解這個，越意識到在 Encore 中我們可以做些什麼，特別是我們的程式庫目前都是無狀態的，並且試圖在我們的元件上保持靈活。如果我們要為每個元件都預設構建可訪問性，那就得構建每個版本，這是不可擴展的。所以這是我覺得需要接受的事情。我希望每個人都能學習有關無障礙的知識，並對自己負責，而不是依賴 Encore 將其全部完成，或 「曼達洛人」小組（Spotify 無障礙負責小組）告訴他們何時做錯了。但另一方面，我意識到，如果我們只是期望每個人都這樣做，這並不會在所有地方發生，不會達到我們想要的品質。因此，我們需要盡可能地融入無障礙設計，這猶如一場平衡的遊戲。
Tamas (無障礙專家)：
這觀點很好，要在這方面達到平衡是很重要的。現在，我們必須將大量的指導文件紀錄下來並塑造這種文化。要讓大家熟悉這個話題需要一段時間，甚至不是只有在問到時才開始談論無障礙設計，而是要讓它成為日常對話的一部分。
這就是為什麼當我看到這些對話發生時感到非常興奮，對我來說，這表示大家正在提出正確的問題。隨著我們與 Fable Tech Labs （由肢體障礙人士為主的無障礙測試平台） 合作推出各種不同角色的無障礙課程，我認為這將加速這種文化的建立。希望隨著時間的推移能減少對指引文健的依賴，相關人士將了解元件可能被錯誤地使用，他們可是負責整個網站的健康狀態和維護無障礙設計的重要關鍵。
Arielle (Encore 產品經理)：
對於在其他公司工作且沒有你們兩位所擁有的專業知識或無法接觸到專業知識的設計師和工程師，你們會給他們什麼最好的建議來建立無障礙的體驗？
Rose (Encore 工程師)：
我只能開啟和關閉螢幕閱讀器，並進行一些其他小操作。如果你不習慣，這種感覺會很可怕。學習所有不同方式的使用者與您的產品互動的基礎知識，會讓問題顯得非常明顯。
要看程式碼並知道使用者體驗是很困難的，但如果你只是使用【螢幕閱讀器】，那就比較容易了。除非你有機會進行真正的使用者測試或擁有主題內容專家（Subject Matter Experts，簡稱 SME，意旨在某領域學有專精，掌握專業知識的人），否則就把自己是最終使用者，並意識到你不可能把所有東西都做得完美。就像所有設計一樣，都可以進一步測試和改進。開始進行漸進式的改進，不要期望這個過程有終點。這不是類似 todo，變得無障礙，就可以打勾了！而是要期望這已經成為工作流程的一部分。
Arielle (Encore 產品經理)：
我喜歡這個想法 — — 「永遠做不完」。我們在這個專案中談論過這個，指引文件總是會為更好而改變，我們總是會嘗試跟上，並且會不斷尋找改進體驗的方法，而且你必須更佳關注即將發布的改善建議（例如 WAI 發布的新規範等等）。至於你所提到的，Tamas，現在有更多工具可供人們使用，一定要善加利用。
Tamas (無障礙專家)：
對，很多我搜尋到的資訊，實際上是即時變動的知識。除了可以維護產品外，還可能有更新和更簡單的方法可以提高可用性。對於螢幕閱讀器，我的主要建議是：不需要成為專家就能測試並了解螢幕閱讀器輸出的基本流程和基本體驗，以及如何與之互動。
我認為最重要的是不要有概括而論或以偏概全的想法，例如：「所有鍵盤使用者都是專門使用螢幕閱讀器的用戶。」，不是這樣的。有許多人可能因為疲勞、關節炎和某些隱疾而被迫使用鍵盤，因為滑鼠需要非常精確的移動，對他們而言會變得痛苦。消除這些偏見並了解有不同的操作方式。現在有很多好的入門指南可以參考。甚至列印一張包含所有指引的小抄。
另外，Fable 最近發表的一篇回顧年度的文章，根據 Fable 的資料，使用螢幕閱讀器的使用者遇到的困難最多，這也是為什麼即使只關注這一個方面，它也是如此重要。WebAIM 成立已經很久了，他們有一個叫 WebAIM Million 的專案，記錄排名前一百萬的網站以及這些網站的無障礙體驗。缺少 alt 文字通常仍然是一個重要的問題，對比度也是一個重要的問題。因此，一些 Fable 的數據和 WebAIM Million 的數據之間存在明顯的模式。
透過回顧 2021 年和 2020 年的趨勢，你可以看到網站無障礙是如何演變或退步的。在某些情況下，情況並沒有真正改善多少。不正確的 ARIA (Accessible Rich Internet Applications) 實際上變得更糟，因為越來越多的網站使用 div 元素並使用錯誤的角色和錯誤的語意，而且他們並不知道應該應用哪些 ARIA 規則。
Rose (Encore 工程師)：
所以他們正在努力，但不一定是最有效的方式…
Tamas (無障礙專家)：
最大的建議是全面考慮，盡可能考慮多個使用者群體。如果預算有限，至少要有一位專家在團隊中，可以為其他人傳授知識和文件，並將資訊或知識傳承下去。我認為任何開發人員都可以進行基本的螢幕閱讀器 Tab 和方向鍵操作；這不需要 50 個指引，而是更像 10 或 15 個指引，但這確實只需要五分鐘的時間。正如你所說，當你直接這樣做時，它真的很有影響力，因為程式碼有時並不能給你全貌。
Rose (Encore 工程師)：
我記得直到我學到比較多之事後才更了解，嘗試透過在程式碼中加入更多屬性並不會更具可訪問性，相反地可能會變得更糟。這是一個有趣的學習過程。在關心無障礙，但不測試可訪問性或真正知道自己在做什麼之間是有一個危險地帶的，你的努力可能會讓情況變得更糟，我曾經陷入這種情況一段時間，現在希望能慢慢走出來。
另外，例如 CSS Grid，這讓我想到我們不能僅僅期望所有新技術都能夠輕易地符合無障礙設計，即使它是瀏覽器標準中的一部分。Flexbox 讓重新排列內容變得更容易，但同時也可能導致無障礙問題。你可能會認為使用 Flexbox 是很普遍的，因為它很大眾化，所以沒問題。這提醒開發人員，即使一個新的標準是大家都可以使用的，也不意味著它能促進無障礙實踐。
Tamas (無障礙專家)：
是的，這就是為什麼我反對使用一些廣受 Web 開發人員歡迎的功能或屬性。
Arielle (Encore 產品經理)：
這是一個非常棒的對話。我很喜歡。我想提一點：即使我在這個項目中是產品經理，我也從和一位視障工程師一起工作中學到了一些東西。你提到的試算表很有趣。我也意識到重要的是要說明你在談論什麼，而不只是指向你的螢幕與依賴游標，並假設其他人知道你在談論什麼。我記得和你一起工作時使用了更明確的語言，這對每個人都有益。
另一件我有注意到，在開始會議時進行的閒談，這是一個更具包容性的時刻。有一天我穿了一件綠色的襯衫，有人讚美了它。你說：「哦，那聽起來不錯」，然後我描述了那件襯衫。和你談論並且讓你參與到這個對話中，這是很美好的經歷。你在和我們合作時的同理心非常特別，你是一個非常獨特的人。
Rose (Encore 工程師)：
這真的很棒。你本來可以對我們更不耐煩，這也是可以理解的。但你很包容我們花時間去理解事情。所以，謝謝你。
Tamas (無障礙專家)：
聽到這些真的很感謝，因為有時候我會有點緊張，別人可以看到我，但我無法用同樣的感官感知他們。比如，我知道左邊陽光很強烈，我把百葉窗拉得比較密，以遮擋眩光。但是關注自己的視覺環境並確保自己不會穿著破爛的睡衣參加會議也很重要。我有一個應用程式可以提醒臉部是否在鏡頭視野的中心位置，這真的很有用。我對自己的視覺形象有一些概念，這絕對是一個我想參與其中，即使我不能像其他人一樣以同樣的方式看待自己樣貌的的世界。這些談話的過程真是太棒了，我喜歡這種開放的對話。
Arielle (Encore 產品經理)：
嗯，這真的很棒。感謝你們，Tamas 和 Rose。和你們兩個交談，回顧這個專案，真是太好了！
現在，我們的設計系統在無障礙方面的狀態要好得多，我們正在思考如何從一開始就包含無障礙考量的產品開發週期。在我們最新的兩個元件中，Tamas 幫助我們思考了所有需要預期的複雜互動，還有很多需要學習的呢！。
- 註 1：「曼達洛人」科幻作品星際大戰（Star Wars）系列中的一個族群，文中 The Way，引用「This is the way」台詞，通常是面對一般人無法解決的困境，基於信念去克服，也表示沒有其他退路，很能體現曼達洛人的經歷。」
- 註 2：Pair Programming，即「偕伴開發」，由兩個工程師搭檔，共同完成開發任務，可能一個人寫程式，另一個則審核程式，過程中有可能互換角色。「搭檔會議」(Pair Session) 目的是為了讓兩個工程師能夠討論，協調。
- 原文出處：Encore x Accessibility: A Balancing Act
