前端無障礙開發指南
作者 | 孫郁儼
The power of the Web is in its universality. Access by everyone regardless of disability is an essential aspect," said Tim Berners-Lee, W3C Director and inventor of the World Wide Web.
30年前，Tim Berners-Lee 在歐洲核子研究中心創建了第一個 Web 網頁，宣告了萬維網的誕生。自此，萬維網就承載著開放平等的愿景。
Accessibility——無障礙設計&信息無障礙（也簡稱為 A11y），雖然常常會被解釋為”為殘障人士服務“，但其無障礙設計的核心在于為所有人提供同等的體驗。我們每個人都有可能在某些時刻成為失能者，這稱為場景性殘疾（situational disability & temporary disability），比如受傷骨折后，暫時失去了部分活動能力。又比如被強光照射時，看不清楚事物，在嘈雜地鐵中的聽力產生障礙等等。
根據 W3C 組織的定義，Web accessibility 意味著每個人都可以感知、理解并與 Web 交互，甚至為 Web 做出貢獻。中國工信部也指出，信息無障礙是指通過信息化手段彌補身體機能、所處環境等存在的差異，使任何人（無論是健全人還是殘疾人，無論是年輕人還是老年人）都能平等、方便、安全地獲取、交互、使用信息。
但在萬物互聯的當下，盡管我們的衣食住行早已與網絡世界息息相關，互聯網并未成一個平等的，人人都可以訪問的世界。根據2022 年 The WebAIM Million 統計報告，在對 100萬 個網站首頁進行無障礙分析后，得到的結果卻差強人意：
- 在 100 萬個首頁中，一共檢測到 50,829,406 項非重復的無障礙錯誤，平均每個首頁有50.8個錯誤。
- 96.8% 的首頁檢測到了 WCAG 2 錯誤，未能達到 WCAG 2的標準，盡管現在最新的標準是WCAG 2.1
- 在殘障用戶的頁面訪問流程中，每交互 19 個首頁元素，就可能遇到一個無障礙錯誤
圖源：2022 年 The WebAIM Million 報告
在這些頁面無障礙錯誤中，96.5%的錯誤歸屬于以下五類：
- 頁面顏色對比度不達標，影響視力障礙用戶的訪問體驗。
- 未定義<img />標簽的alt屬性，影響輔助技術（Assistive technologies, ATs) 如屏幕閱讀器等設備獲取圖片信息。
- 空鏈接和空按鈕，指不包含不包含實際的文本的<a>標簽或 <button>標簽。這些標簽只包含一個圖像或一個文本的圖像，會導致使用 ATs 設備的用戶無法感知可交互元素的實際用途。
- 表單元素<input />標簽沒有對應的<label>標簽。</label><label>標簽對于 ATs 設備至關重要。沒有它，用戶將無法感知他們在與哪個 <input /> 標簽交互。
- <html>標簽沒有設置lang屬性。不同的語言類型在屏幕閱讀器中的發音是不同的，比如six單詞在法語和英文兩種類型的屏幕閱讀器中的發音就非常的不同。在</html><html>上定義lang屬性，會告知 ATs 設備當前頁面所使用的語言。
作為前端開發者，我們要如何把關頁面的無障礙功能呢？
在前端開發的視角中，每一個 Web 應用都可以拆解為 HTML、CSS 和 JavaScript。HTML 會經過 HTML Parser 將 HTML 結構轉換成 DOM Tree；CSS 會經過 CSS Parser 將 CSS 轉換成 CSSOM Tree。最終，瀏覽器根據 DOM Tree 和 CSSOM Tree 構建出最終的 Render Tree。
對于無障礙 Web 應用，除了包含 DOM 和 CSSOM 之外，將包含 AOM (Accessibility Tree，可訪問性樹)。AOM 可訪問性樹和 DOM 樹平行存在。簡單來說，可訪問性樹是 DOM 樹的一個子集。每個需要暴露給 ATs 輔助技術的 DOM 元素都對應一個在可訪問樹中存在的無障礙對象。定義 AOM 實現的標準是 WAI-ARIA(Web Accessibility Initiative – Accessible Rich Internet Application)，即可訪問的互聯網富應用標準，致力于解決應用的可訪問性問題，它與HTML5 標準同屬于 W3C 組織。Web 應用的 AOM 也并非遙不可及，打開 Chrome 瀏覽器的 Devtools，我們即可查看頁面的 AOM 結構。
在了解了無障礙的基本概念后，我們分別從 HTML、開發框架以及 CSS等角度，一起來看看無障礙頁面的實現方式吧。
編寫 HTML 時需要考慮的 Web Accessibility
就像瀏覽器引擎依賴 HTML 結構以構建頁面 UI 骨架，ATs 設備也依賴 HTML 結構來構建頁面的 AOM 可訪問性樹。所以語義化的 HTML 對于實現 Web 應用無障礙至關重要，因為原生的 HTML 標簽中包含了構建 AOM 的必要元數據。
參考上圖，ATs 設備完全可以正確地渲染滑動輸入框，即便我們沒有在HTML 標簽上添加 WAI-ARIA 屬性。但我們在開發時往往會忽略 HTML 元素的實際語意，而更多采用無語意的 <div> 和 <span> 標簽 （<div> 和 <span> 之外的近 104 個 HTML 標簽都具有語義信息）。因為這兩個標簽沒有默認樣式，足夠簡單，就像白紙一樣可以隨意畫上 CSS 樣式。但這樣的標簽，對于 ATs 設備來說，就是災難。
以上圖為例，對于 <button> FOO </button> 標簽，讀屏軟件將讀出 “Button, foo"，告知用戶當前元素是按鈕，包含文字 foo。但對于 <div class="button"> FOO </div> 標簽，讀屏軟件只能讀出 “foo”，并不能提示當前元素是一個可交互的按鈕。雖然我們也可以通過設置 WAI-ARIA 屬性為 HTML 標簽增添無障礙語意，比如 <div class="button" role="button"> FOO </div>，但這樣會平添許多額外的工作，也增加了出錯的機率：根據 The WebAIM Million 統計報告，包含 ARIA 的頁面比不使用 ARIA 的頁面，檢測出無障礙性錯誤的可能高 70%。
通過 HTML 提升頁面可訪問性
規則 1：結構和樣式分離
在社區中一直都有人在提倡 CSS裸奔日（CSS Naked Day），編寫 HTML 時不要基于 UI 視覺效果（CSS 樣式），而是基于 UI 的頁面結構，可以確保 HTML 的語義完善，增強頁面可訪問性。
相關瀏覽器插件：HeadingsMap - Chrome Web Store
規則 2：只在必要時使用 ARIA
WAI-ARIA 的全稱是 Accessible Rich Internet Applications，簡稱 ARIA，是 W3C規范之一。ARIA 允許 Web 開發者創建只有 ATs 技術（比如屏幕閱讀器）可以看到的內容（屬性），用以實現 HTML 無法達成的無障礙功能，比如：
- 增強交互式控件的可訪問性，比如下拉菜單、彈窗，滑塊等
- 為頁面結構定義有用的地標
- 定義動態更新的“活動區域”
- 改善鍵盤可訪問性和交互性
ARIA 表現為 HTML 的屬性，確定了元素的 ARIA 角色、狀態和屬性。這些信息幫助 ATs 技術更好地理解 Web 頁面，確保用戶與頁面元素的交互。一般情況下，ARIA 不會影響 Web 頁面的渲染，也不會影響鼠標或鍵盤用戶的行為，只有使用輔助技術的用戶才能感知到 ARIA。開發人員隨意使用 ARIA 所導致的問題，對于頁面無障礙功能往往是致命的，而且難以察覺。
但 ARIA 永遠無法替代語義化 HTML 標簽，NO ARIA is better than bad ARIA。請優先考慮語義最貼近的 HTML 標簽，只在必要時使用 ARIA。
相關瀏覽器插件：
- Visual ARIA - Chrome Web Store
- Landmark Navigation via Keyboard or Pop-up - Chrome Web Store
規則 3：提升表單結構的包容性
(1) 采用 <fieldset> 為表單項分類
當表單分為不同板塊時，我們可能會使用 <div> 元素實現表單項的樣式板塊劃分，但這樣的劃分并不利于無障礙設備獲得表單項信息，可以使用<fileset>進行替換。
(2) 正確使用 label，為 <input /> 標簽設置對應的 label
在實現表單時，我們往往會通過 placeholder 來提示當前表單項的填寫內容。這樣的設計會導致當 input 得到焦點時，placeholder 自動消失，造成用戶無法感知當前表單項的內容。我們可以使用 label 充當 placeholder，這樣的交互方式也稱為 Float Label Pattern
(3) 盡可能使用原生的表單元素
在制作表單組件時，我們往往會出于實現 UI 樣式的要求，采用 <div> 替代原生的表單元素。盡管這些表單組件在視覺和功能上滿足了 UI 要求，但它們并未實現原生表單元素的無障礙功能。
(4) 為表單元素設置原生的校驗屬性
required、minlength、pattern 等表單的原生校驗屬性，不但可以滿足正常的表單校驗需求，也具有更好的無障礙支持
規則 4：注意頁面的焦點管理，允許用戶僅通過鍵盤完成交互
很多行動不便的用戶依賴鍵盤操作，靠 Tab 鍵和方向鍵等瀏覽網。因此我們在構建 Web 應用的時候要注意：
- 確保頁面所有內容都可以通過鍵盤訪問
- 盡可能地提供鍵盤快捷鍵交互
- 避免設計只在鼠標 hover 時才會被激活的元素
一些 HTML 的原生標簽具備可聚焦屬性，也被稱為可聚焦元素。這些原生 HTML 元素，天然存在于頁面 Tab 鍵順序內，內置了鍵盤事件處理，可以通過 Tab 鍵聚焦，并且獲得焦點時有可見的焦點指示器（往往是顯眼的藍色框框）。但對于無法聚焦的元素，我們可以設置元素的 tabindexlace 屬性，使元素可聚焦。
如果想給當前元素生成快捷鍵的話，可以給元素設置 accesskey 屬性。但使用 accesskey也需注意以下問題：
- accesskey 值可能與系統或瀏覽器快捷鍵或輔助技術功能相沖突
- 當考慮頁面國際化時，某些 accesskey 值可能不會出現在一些鍵盤上
- 依賴于數值的 accesskey 可能會讓具有認知障礙的用戶感到困惑，因為數值和觸發的功能并沒有邏輯聯系
- 如果沒有告知用戶快捷鍵的存在，那么可以會造成用戶誤觸
相關瀏覽器插件：
- taba11y - Chrome Web Store
- NerdeFocus - Chrome Web Store
規則 5：定義文檔的語言類型
在 <html> 標簽元素上設置正確的 lang 屬性。如果你的頁面沒有顯式設置當前頁面所使用的語言，那么讀屏軟件將無法選擇匹配的語音配置文件和字符集，讀屏軟件讀出的頁面內容是亂碼。所以，為了確保頁面的內容正確，請務必為 </html><html> 元素指定有效的BCP 47語言。
規則 6：為 <img /> 添加 alt 屬性，明確鏈接和按鈕的信息
往往一張表情包圖片就可以抵千言萬語，但對于讀屏軟件來說，讀取 <img /> 標簽的有效信息，只能靠 alt 屬性。所以不要忘記為 <img /> 標簽添加描述性的 alt 屬性。如果圖片只是為了裝飾效果，那么可以考慮將 <img /> 標簽 替換為 CSS 背景圖。
與 <img />標簽類似，讀屏軟件對于 <a> 和 <button> 標簽的信息獲取，依賴于標簽包裹的文本。使用”閱讀更多“，甚至圖片作為這類標簽的包裹內容，并不能為用戶提供足夠的信息。如果不方便添加文本信息，也可以利用 aria-label 增強元素的語義信息：
<a href="post.php?post=632" aria-label="More on Using Meaningful Link Text">More...</a>使用前端框架需要考慮的 Web Accessibility
根據 2022 年 The WebAIM Million 統計報告，使用 JavaScript 框架的頁面比不使用框架的頁面存在更多的無障礙錯誤，其中 React 開發的頁面平均存在 50.8 個錯誤，Vue 開發的頁面存在 63.4 個錯誤。雖然統計結果不能說明框架導致了這些錯誤，但在使用框架進行 Web 開發時，常常會忽略使用 HTML 原生標簽，或者引入無障礙功能支持性不佳的組件庫，導致框架開發的 Web 應用可訪問性普遍較差。
提升前端框架的無障礙支持性
規則 1：使用語義化 HTML 標簽，完善 HTML 標簽的屬性
規則 2：在設計組件時考慮整體的 HTML 結構
維護層級明晰的 HTML 結構，對于 Web 應用的無障礙功能十分重要。因為 ATs 軟件，特別是讀屏軟件，不止是由上至下地展現頁面信息，更會基于頁面不同級別的標題或者文檔地標元素進行頁面導航。在將頁面拆分成不同組件后，保持 HTML 文檔結構層級會更加復雜。比如當一個組件包含 <h2> 標簽時，可能在一些位置該組件會破壞原有 HTML 文檔結構。
規則 3：避免使用無意義的 HTML 標簽
在使用 React、Vue 等框架時，我們往往需要將組件包裹在一個根元素中：
但這樣的處理在編譯后，會在造成元素結構的混亂：
<div> 標簽混在 <tr> 標簽中，會導致讀屏軟件無法正確解析 table ，造成用戶無法訪問表格內容。此時，我們應該使用 React 的 <fragment> 標簽（Vue 中可以使用 vue-fragment），確保根元素不存在于最終的 DOM 結構內：
