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