如何將無障礙設計納入團隊的程序。
讓網站更容易存取可能會是一項艱鉅的任務。如果您是第一次接觸無障礙設計，可能會因為這個主題的廣泛性，而不知道該從何處著手。畢竟，為了滿足各種能力需求，我們必須考慮各種問題。
請記住，無障礙設計需要集結眾人的力量。每個人都扮演要角。本文將說明各個主要領域 (專案經理、使用者體驗設計師和開發人員) 的標準，協助他們在工作流程中納入無障礙最佳做法。
專案經理
任何專案經理的首要目標，都是盡量在每個里程碑中納入無障礙性工作，確保這項工作與效能和使用者體驗等其他主題同樣重要。以下是幾項檢查清單項目，請在處理程序時留意。
- 為團隊提供無障礙訓練。
- 找出網站或應用程式中的關鍵使用者旅程。
- 嘗試將無障礙檢查清單納入團隊程序。
- 盡可能透過使用者研究評估網站或應用程式。
無障礙訓練
網路上有許多免費的實用資源，可協助您瞭解網路無障礙設計。請團隊撥出時間研究這個主題，這樣就能更輕鬆地在過程初期納入無障礙設計。
Google 提供的部分資源包括：
Google 網頁無障礙設計課程：為期數週的互動式訓練課程。
無障礙功能基礎知識：無障礙功能指南和最佳做法。
Material Design 指南：無障礙設計：一組包容設計的 UX 最佳做法。
找出關鍵使用者歷程
每個應用程式都有使用者需要採取的主要動作。舉例來說，如果您正在建構電子商務應用程式，則每位使用者都必須能夠將商品加入購物車。
有些動作可能較不重要，也許只會偶爾執行。舉例來說，變更虛擬化身相片是一項不錯的功能，但可能不是每項體驗都需要。
找出應用程式中的主要和次要動作，有助於您將可用於優先處理無障礙功能的工作。日後，您可以將這些動作與無障礙檢查清單結合，以便追蹤進度並避免回歸。
納入無障礙檢查清單
無障礙設計的範圍相當廣泛，因此建議您列出一份檢查清單，列出需要考量的重點項目，確保您已涵蓋所有基礎。
市面上有許多無障礙檢查清單，以下列舉幾個業界範例：
有了檢查清單，您就可以查看主要和次要動作，開始篩選仍待完成的工作。您可以針對這個程序採取相當明確的策略，甚至建立主要和次要動作的矩陣，並針對這些程序中的每個步驟，判斷是否有任何缺少無障礙性位元。
使用使用者研究進行評估
與實際使用者面對面，觀察他們嘗試使用應用程式的過程，是瞭解使用者體驗的最佳方式。如果您要將無障礙功能加到現有體驗，這個程序有助於快速找出需要改善的部分。如果您要開始新專案，早期使用者研究可協助您避免花費過多時間開發難以使用的功能。
盡可能納入來自不同使用者族群的意見回饋。請考量主要使用鍵盤瀏覽，或仰賴螢幕閱讀器或螢幕放大鏡等輔助技術的使用者。
使用者體驗設計師
由於人類設計時往往會受到自身偏見的影響，如果您沒有身心障礙，也沒有身心障礙的同事，那麼您可能無意間只為部分使用者設計。在進行設計時，請問自己：「有哪些類型的使用者可能會依賴這項設計？」以下是一些可讓流程更具包容性的技巧。
- 內容具有足夠的色彩對比。
- 定義分頁順序。
- 控制項具有可供存取的標籤。
- 您可以透過多種方式與 UI 互動。
內容具有良好的色彩對比
大多數網站的主要目標，是透過文字或圖片向使用者傳達資訊。不過，如果這類內容對比度偏低，部分使用者 (尤其是視障人士) 可能就無法順利閱讀。這可能會對使用者體驗造成負面影響。為解決這個問題，請確保所有文字和圖片都有足夠的色彩對比。
對比度是透過比較前景和背景顏色的亮度來測量。對於較小的文字 (小於 18 pt 或 14 pt 的粗體文字)，建議使用 4.5:1 的最低對比率。如果是較大的文字，則可將此比率調整為 3:1。
在下圖中，左側的文字符合這些對比度下限，而右側的文字對比度偏低。
有許多工具可用來測量色彩對比度，例如 Google 的 Material Color Tool、Lea Verou 的 Contrast Ratio app 和 Deque 的 aXe。
定義分頁順序
分頁順序是指使用者按下分頁鍵時，元素獲得焦點的順序。對於主要使用鍵盤瀏覽的使用者，Tab 鍵是他們瀏覽畫面上所有內容的主要方式。就像滑鼠游標一樣。
理想的分頁順序應遵循閱讀順序，從頁面頂端流向底部，並將較重要的項目放在順序較前的位置。如此一來，使用鍵盤的使用者就能更有效率地快速存取這些項目。
上方的模擬介面已標上編號，以顯示分頁順序。建立類似的模擬畫面，有助於識別所需的分頁順序。接著，您可以將這個檔案與開發人員和品質確保測試人員分享，確保對方能正確實作及測試。
控制項具有可供存取的標籤
對於螢幕閱讀器等輔助技術使用者而言，標籤可提供原本僅以視覺方式呈現的資訊。舉例來說，如果搜尋按鈕只是放大鏡圖示，可以加上「搜尋」的無障礙標籤，以補足缺少的視覺提示。
以下提供幾個簡單的建議，供您在設計無障礙標籤時參考：
- 簡潔扼要：長篇大論的說明可能會讓使用者感到厭煩。
- 請勿加入控制項類型或狀態，如果控制項的程式碼編寫正確，螢幕閱讀器就會自動朗讀。
- 使用主動動詞 - 使用「搜尋」，而非「放大鏡」。
建議您建立模擬內容，並為所有控制項加上標籤。您可以將這份資訊分享給開發團隊和品管團隊，以便進行實作和測試。
多種與 UI 互動及瞭解 UI 的方式
我們很容易假設所有使用者主要都是使用滑鼠與網頁互動。設計時，請考量使用者如何使用鍵盤與控制項互動。
請規劃重點狀態！也就是說，當使用者以 Tab 鍵或按下方向鍵將焦點移至控制項時，該控制項會呈現什麼樣貌。建議您盡早規劃這些狀態，而非在後續設計中勉強加入這些狀態。
最後，您必須確保使用者在任何互動點都能透過多種方式瞭解內容。請盡量不要只使用顏色來傳達資訊，因為色覺障礙的使用者可能會錯過這些細微的提示。最常見的例子是無效的文字欄位。除了使用紅色底線表示問題，也建議加入一些說明文字。這樣一來，您就能涵蓋更多情況，並提高使用者發現問題的機率。
開發人員
開發人員的角色是將焦點管理和語意結合，打造出完善的使用者體驗。以下是開發人員在處理網站或應用程式時，應留意的一些事項：
- 分頁順序符合邏輯。
- 焦點已正確管理且可見。
- 互動式元素支援鍵盤。
- 視需要套用 ARIA 角色和屬性。
- 元素已正確標示。
- 自動化測試。
邏輯分頁順序
input、button 和 select 等原生元素會免費加入分頁順序，並可透過鍵盤自動取得焦點。但並非所有元素都會收到相同的行為！具體來說，div 和 span 等一般元素並未納入分頁順序。也就是說，如果您使用 div 建立互動控制項，就必須額外進行作業，讓鍵盤可存取該控制項。
兩個選項如下：
- 為控制項提供
tabindex="0"。這至少可讓按鍵可聚焦，但您可能需要額外進行作業，才能支援按鍵操作。 - 盡可能使用
button而非div或span來處理任何類似按鈕的控制項。原生button元素非常容易設定樣式，而且可免費取得鍵盤支援。
管理焦點
變更網頁內容時，請務必透過移動焦點來引導使用者的注意力。開啟模態對話方塊時，就是使用這項技巧的經典範例。如果使用者依靠鍵盤按下按鈕開啟對話方塊，但焦點「未」移至對話方塊元素，那麼他們唯一的行動方式就是在整個網站中按 Tab 鍵，直到找到新的控制項為止。只要在新內容出現時立即將焦點移至該內容，就能提升這些使用者的使用效率。
互動元素的鍵盤支援
如果您要建構自訂控制項 (例如輪轉介面或下拉式選單)，就需要進行額外作業來新增鍵盤支援功能。ARIA 編寫實作指南是一項實用資源，可識別各種 UI 模式，以及這些模式應支援的鍵盤操作類型。
如要進一步瞭解如何為元素新增鍵盤支援功能，請參閱 Google 無障礙設計基礎知識說明文件中的「roving tabindex」一節。
視需要套用 ARIA 角色和屬性
自訂控制項不僅需要適當的鍵盤支援，也需要適當的語意。畢竟，div 在語意上只是一般分組容器。如果您使用 div 做為下拉式選單的基礎，就必須仰賴 ARIA 來加入額外的語意，以便將控制項類型傳達至輔助技術。這時，您可以參考 ARIA 製作實務指南，瞭解應使用哪些角色、狀態和屬性。另外，ARIA 指南中的許多說明也附有範例程式碼！
標示元素
如要標示原生輸入內容，您可以使用 MDN 所述的內建 <label> 元素。這不僅有助於您在畫面上建立視覺提示，還可在無障礙樹狀結構中為輸入內容提供無障礙名稱。輔助技術 (例如螢幕閱讀器) 會接收這個名稱，並向使用者朗讀。
很抱歉，<label> 不支援為自訂控制項 (例如使用自訂元素或簡單的 div 和 span 建立的控制項) 提供可存取的名稱。針對這類控制項，您必須使用 aria-label 和 aria-labelledby 屬性。
自動化測試
懶惰有時是好事，尤其是在測試方面。盡可能自動化無障礙測試，以免您必須手動執行所有操作。目前有許多優質的業界測試工具，可讓您輕鬆快速檢查常見的無障礙問題：
Deque systems 開發的 aXe 可做為 Chrome 擴充功能和 Node 模組 (適合持續整合環境) 使用。這部短片說明瞭幾種將 aXe 納入開發程序的方法。
Lighthouse 是 Google 的開放原始碼專案，可用來稽核漸進式網頁應用程式的效能。除了檢查 PWA 是否支援 Service Worker 和 Web 應用程式資訊清單等項目，Lighthouse 也會執行一系列最佳做法測試，包括無障礙設計問題的測試。
結論
無障礙設計需要集結眾人的力量。每個人都扮演要角。本指南列出了幾項重點項目，每位團隊成員都能利用這些項目快速掌握主題，並希望能改善應用程式的整體體驗。
如要進一步瞭解無障礙工具，請務必參閱免費的 Udacity 課程，並瀏覽 web.dev 提供的無障礙說明文件。