在上篇的 不能永遠忽略的 Accessibility (上) 中了解到了真正的 Accessibility 的是什么以及為什么要關注它，同樣，想必你也看到了它那些看了也不知道具體該怎么做的規范吧，那對于一個前端工程師來說，究竟我們需要怎么做呢，今天就來說說圍繞 WCAG 2.0 的規范我們可以怎么做。

HTML 語義化

• 標題，段落，列表等內容的保持良好的結構
  正確地使用各個語義化的標簽，不僅是自身代碼質量的提高，對閱讀你代碼的人，也會有極大的幫助，同樣對于開發成本，網站的SEO來說都是有好處的。
  對于 Accessibility 來說，良好的標題，段落，列表結構也會提高輔助設備對用戶的良好體驗，比如屏幕閱讀器在閱讀到相對于的語義化標簽的時候，是會自動地將對于標簽讀給用戶聽的。

• 盡量使用語義化的標簽
  可能平時大家很少關注一個叫 Accessibility tree 的東西，翻譯過來叫無障礙樹，當你選中一段 DOM 的時候，在 Devtools 里面都可以看到，瀏覽器實際呈現給屏幕閱讀器的就是這個結構 (瀏覽器獲取 DOM 樹，并將其修改成適用于輔助技術的形式) 將DOM 樹變成無障礙樹，所以良好的使用語義化標簽，能讓輔助設備更合理地將你網站的內容轉化成 Accessibility tree，從而解讀給用戶。
  

所以確保頁面中的重要元素具有正確的無障礙角色、狀態和屬性并確保指定無障礙名稱和說明，瀏覽器便可讓輔助技術獲取該信息以打造自定義體驗，這一點很重要。

• 為任何非文本內容提供文本替代項
  圖像是大多數網頁的重要組成部分，當然也是對弱視用戶造成阻礙的一個特定因素，特別是那些瀏覽圖片的網站，這時候添加文本替代性是非常重要的，舉個簡單的 ??

<img src="/160204193356-01-cat-500.jpg" alt="一只目光洶洶凝視遠方的貓”>

alt 允許指定在圖像不可用時（例如圖像加載失敗、被網絡爬蟲訪問或被屏幕閱讀器讀取時）使用的簡單字符串，alt 不同于 title 或任何類型的字幕，因為它只在圖像不可用時使用。

另一方面，描述圖像并不總是有用。
例如，假定在一個包含文本“搜索”的搜索按鈕內有一幅放大鏡圖像。如果其中不包含文本，您肯定會指定“搜索”作為這幅圖像的 alt 值。 但由于文本處于可見狀態，屏幕閱讀器將拾取并朗讀“搜索”一詞；因此，圖像上完全相同的 alt 值就成了多余的內容, 如果將 alt 省略，我們聽到的很可能不是替代文本，而是圖像文件名, ，只需使用空的 alt 屬性就可讓屏幕閱讀器將圖像整個跳過。

<img src="magnifying-glass.jpg" alt=“”>

所有圖像都應有 alt 屬性，但它們無需都包含文本。 重要的圖像應使用描述性替代文本簡潔地說明圖像內容，而裝飾性圖像應使用空的 alt 屬性，即 alt=“”

• 表單輸入有關聯的文本標簽
  • 將 input 元素置于 label 元素內
  • 使用 label 的 for 屬性并引用元素的 id
    推薦使用后者，舉個簡單的 ??

<input id="promo" type="checkbox"></input>

<label for="promo">This is a checkbox</label>

屏幕閱讀器便可報告元素角色為 checkbox，處于 checked 狀態，名稱為“This is a checkbox”。

• DOM 順序和視覺順序保持一致
  一般我們設計的時候，往往考慮的都是視覺可見得用戶，那其實對于只能使用屏幕閱讀器瀏覽網站的用戶，這時候如果 DOM 結果不一致的話，就會造成用戶的疑惑。

關于 Focus

大家應該都發現過我們在使用 Tab/ Shift Tab 鍵或者上下左右鍵的時候，也可以和網頁進行交互，這種設計不僅方便與一般人的操作，其實對不能使用鼠標的用戶來說是不必可少的設計。

同樣，我們應該也見到過不同的瀏覽器會有不同的樣式，Chrome 通常使用藍色邊框突出顯示聚焦的元素，而 Firefox 則是使用虛線邊框，每個瀏覽器都有自己默認的 Outline 樣式。

但是，又會發現很多網站是沒有這些交互的，這就是在網頁設計以及實現的時候禁用了這寫功能或者說沒有使用合理的標簽。

Web AIM 檢查清單才會在其第 2.1.1 節中指出，所有頁面功能應該都能使用鍵盤來執行

關于 Outline，官網上是這樣說的

禁止設置 outline 為 none， 在不提供替代項的情況下

HTML 默認的 focusable 元素，它們是自動插入到 Tab 鍵順序中，并且內置了鍵盤事件處理，默認支持 keyboard 功能，基本的都可以在 這里 找到。

所以，關于 Focus 我們可以做的有

• 不要 Remove 原生支持的 outline 樣式，除非你有更好看的樣式替代它
• 盡量使用原生支持的 focusable 的元素
• 如果有復雜的 UI, 需要使用非語義化的標簽但確實是和用戶有交互的時候，請為它加上 tabindex
• 可以自己寫一些 js 或者一些庫來區分鍵盤和鼠標或者觸摸事件，來實現不同的 outline 樣式，比如只想在使用鍵盤的時候有 outline，使用鼠標或者觸摸的時候去掉 outline，我覺得這是相對合理的設計，比如 Google 的 Accessibility 頁面。
• ......

設計樣式的時候

• 正確的 Tab 鍵順序，也就是設計出來的 Tab 鍵的順序需要遵循正常的視覺順序，從上至下，從左至右，比如這張圖。
  

Use WAI-ARIA

ARIA 全稱 Accessible Rich Internet Applications，可以修改現有元素的語義，也 可以向不存在原生語義的元素添加語義，在復雜的 UI 控件會涉及到非語義的 HTML，這時候通過增加瀏覽器和輔助技術可以識別和使用的進一步語義來讓用戶知道正在發生的事情。

它提供了一系列可以使用的 attribute 來達到該目的，常用的有

• role
  如果使用的是原生支持的語義化標簽，那本身就是有默認的 role的，比如 button 的 role 就是 button。如果我們使用 Div + style 來實現一個button，那就需要考慮加 role 了。
• aria-label
  舉個 ??，如果我們有一個按鈕，其上的 text 是個 x，代表關閉的意思，如果只是使用普通的標簽，這時候，輔助設備是無法識別這個 x 的含義表達給用戶的，這時候就需要添加 aria-label = 'close'，這時候屏幕閱讀器就會將這個 close 閱讀給用戶，但不會在視覺上有任何的影響。
• aria-labellby
  和 aria-label 的作用類似，只是當你想要的標簽文本已在其他元素中存在時，可以使用aria-labelledby，所有讀取的元素的 id 即可。
• aria-owns
  aria-owns 會將 DOM 中獨立的一個元素視為當前元素的子項 任何向 DOM 顯式隱藏的內容同樣不會包含在無障礙樹中。
• aria-hidden
  我們大概都知道，當網站彈出一個模態框的時候，我們幾乎是看不清除模態框以外的元素的，也是不能和其交互的，但對于使用屏幕閱讀器的用戶怎么辦呢，因為如果你不加任何 ARIA 標簽，他們默認還是會聽到每個元素的解讀，這時候你就需要使用 aria-hidden 來屏蔽掉除模態框以外的 DOM
• ......

對比度的設計

這張圖從左到右，我們能看到對比度越來越低，識別度也越來越低，如果我們使用了類似的對比度，有人統計過，大約 5% 用戶在訪問您的網站時無法獲得我們預想的體驗。
WCAG 2.0 對頁面上文字的對比度有一個最低的要求 4.5 : 1
所以保持一個合理的對比度，也是我們可以很容易就做到事情。

總結一些好的實踐

再簡單總結一些開發時可以用到的實踐，都可以在 WCAG 2.0 里面找到。

• 非交互式內容（例如，標題）應該避免可聚焦
• 防止存在于DOM但不可見的屏幕外內容時刻聚焦
• 檢查所有自定義控件以獲取 role 賦予其狀態的適當和任何所需的ARIA屬性
• 視覺隱藏內容，確保設置 aria-hidden=”true”
• 鏈接和按鈕等交互式元素需要hover 狀態
• 避免鍵盤陷阱
• 設計盡量簡潔簡約

手動測試是不是太累了

那開發做了這些之后，QA怎么去測試呢，或者說我們開發了一個網站之后怎么知道我們有哪些做的不合理的地方不利于 Accessibility呢，總結了一些工具。

Chrome 插件

• ax 可以測試網站的 Accessibility 現狀，并指出哪里需要改進以及建議的方法
• WAVE 作用同上，只是提示方式有些區別
• Nocoffee 可以模擬一些有視力問題的用戶，從他們的視角來看看你的網站

手動測試站點的可訪問性可能是乏味且容易出錯的，自動化流程當然是最好的。

自動化測試工具

• pa11y
  ThoughtWorks 在2017年3月的技術雷達，具體使用可參考《無障礙性測試工具 Pa11y》

明明可以做的更好

整理了一些相關的視頻，感觸頗多，他們都可以這么努力，更何況我們呢。

• 他們可以用眼上網
• 蘋果公司無障礙主題視頻
• 幫助盲人探索世界

最后我想認真地打出這幾個我們常說的幾個字 — 人人平等。
我想，我們真的可以做的更好。