無障礙設計

之前整理「色彩對比度」相關內容時，連帶學習了「無障礙設計」的知識，這次一起整理分享出來。

一共分視覺、聽覺、行動、認知四個方面來闡述。

什麼是「無障礙設計」，為什麼它這麼重要？

在這個多樣化的世界上，並不是所有人都能毫無障礙、順利地使用各種產品。

優秀的無障礙設計，不僅能讓殘疾人用戶正常地與產品交互；還會為普通人提供更好的使用體驗。

舉個例子，住宅樓入口設置的坡道，本是方便使用輪椅的用戶出入。但實際使用中，多數老人、推自行車的人，甚至正常人都更願意走坡道而非樓梯，因為走坡道更省力。

所以坡道的設計，不僅解決了殘疾人出入的問題，也為正常人提供了更好的體驗。

無障礙設計不是創新的阻礙

無障礙設計並不會強迫設計師把設計變醜，變無聊，變雜亂。相反，若能在考慮各種設計限制時，也同時考慮「無障礙設計規範」，會通過一些限定激發出新想法，促使設計師做出為所有人所用的更好產品。

我們要努力為所有人設計——包括盲人，色盲患者，視力低下患者；聽覺失聰或有聽覺障礙的人；有認知障礙的患者；為年長、年幼的人設計；為有明確目的的人、只是閑逛的人、單純只為享受好的用戶體驗的人而設計。

做無障礙設計時，主要考慮以下 4 個主要方面：

1. 視覺無障礙設計（visual）
2. 聽覺無障礙設計（hearing）
3. 行動無障礙設計（mobility）
4. 認知無障礙設計（cognition）。

1. 視覺無障礙設計

「視覺障礙」包括：從難以區分顏色到完全失明。

設計要點：

• 確保文字、可交互控制項和背景的對比度（contrast ratio threshold），滿足最低標準。
• 別只用顏色傳達信息（using solely color） ，讓文字字型大小可調（ resizable）。
• 確保界面上所有的控制項都可藉助輔助技術（assistive technologies）使用，如屏幕閱讀器，放大鏡和盲文顯示器（screen readers, magnifiers and braille displays）。 這就意味著必須讓 accessibility APIs 可以通過程序確定每個控制項的角色、狀態、價值、標題。

詳細闡述關鍵點：

1.1 確保文字和背景的顏色有足夠高的對比度

根據According to the WCAG, 標準，文字和背景色的對比度至少是4.5:1；如果是大於等於24 px/ 19 px bold 的文字，對比度至少是3:1 。這項規範可以幫助視力障礙用戶更好地使用互聯網產品。

這是一個滿足對比度標準的好案例：

Input 是常被人忽略的一個方面。下圖7個 input 的例子，只有「Search Twitter」的對比度足夠高，滿足「無障礙設計標準」讓人看得清。

我在另一篇文章《色彩無障礙設計（Color Accessibility）之「對比度」的探索》中有詳細闡述關於對比度方面的知識，包括概念介紹、實施方法、推薦工具。

1.2 別只依靠顏色傳達信息

不能單單只依靠顏色傳達諸如「 狀態指示、區分視覺控制項、實時響應」等信息。如果只用顏色區分，可能會讓一些用戶不方便、甚至不能分辨2中顏色的區別。這些用戶包括色盲患者（1/12 的男性，1/200 的女性）、視力低下患者（1/30 的人）、甚至盲人（1/188 的人）。

推薦的做法是：同時使用多種視覺線索傳達重要信息；只使用顏色強調或補充已經能看明白的信息。

舉個例子，下面的 input 中，視力正常用戶能輕易分清 Email 是錯誤狀態，但色盲用戶就完全看不出。

解決辦法有很多種，比如：同時使用「顏色區分+標籤+說明」，來表明哪個是錯誤狀態。

辦法是無盡的，原則是唯一的：別只用顏色區分。

Facebook 的 input 是個很好的例子：

同時使用了 3 種視覺線索區分錯誤狀態：

1. 紅色邊框；
2. 嘆號 icon ；
3. tooltip 提示，解釋為什麼出現錯誤。

1.3 注意表單的設計

近幾年，表單輸入框的形式有了不小轉變。現代風格的表單設計傾向於往極簡主義發展，拋棄了傳統表單的一些基本屬性，比如清晰的邊框，明顯的標籤——這大大降低了使用體驗。

下圖是傳統輸入框樣式，界限明晰，標籤清楚。中間可填充顏色也可不填充。

清晰的表單邊框對於有認知障礙、視力低下的用戶非常重要。清晰的視覺線索，會讓他們很容易弄清楚輸入框在哪，面積有多大。

下圖是一個很流行的筆記app的輸入框。

上面這個界面中，點擊「searching your notebooks」的任意一處，都可以開始搜索。

下面這個界面中，有 2 個 input field， 如果我想 「 tell your story」，我該點哪？

答案是只有點擊藍框框里，才能輸入文字。點擊藍框以外的區域，沒任何反應。

下圖這個筆記輸入界面的例子，也沒有傳統的輸入框。但標題是限定在2條水平線內的，並且用戶可以點擊下面的任意處開始輸入筆記內容。

1.4 沒標籤的輸入框

Text label 能告訴用戶輸入框的目的，placeholder 沒這麼大作用。

不推薦 placeholder 代替 text label 的輸入框，輸入內容時placeholder消失，會讓用戶忘記輸入目的。

推薦把 lable 拿到輸入框外側，時刻提醒用戶自己輸入的是什麼。

1.5 可以用屏幕閱讀器順利使用你的 UI 控制項嗎？

這這主要針對：使用 Dragon NaturallySpeaking 等語音識別工具的視覺障礙用戶。（有數據顯示大概 1–2% 的用戶會使用 屏幕閱讀器（screen reader）

舉個例子，如果你的「menu」只呈現一個圖像icon，像這樣：

為了說明這是一個「菜單按鈕」，它需要一個「文字替代方案」，比如「menu」來傳達和圖像相同的信息。可以使用 aria-label attribute, aria-labelledby attribute，或者直接寫上「菜單」。 WebAIM Quick Reference 里提供了一些 general technical tips。

（aria-label 是一個 HTML attribute，用來告訴讀屏軟體某個元素是什麼，提升 Web Accessibility）

任何圖像形式的 UI 控制項，都需要為圖像提供一個「文字替代方案」。

1.6 別讓用戶到處 hover 才能找到答案

這主要針對：

• 使用 Dragon NaturallySpeaking 等語音識別工具的視覺障礙用戶。
• 有行動障礙的用戶，包括視力正常的 keyboard-only user；

鍵盤用戶和諸如 Dragon 這樣的輔助技術，依靠的是屏幕上可見的交互組件。如果一個鏈接或按鈕在屏幕上不可見，則不可能口頭告知「clidked」。如果一個 keyboard-only user 在一個頁面上看不到按鈕，怎麼才能通過一個空白區域導航去想去的地方？

下圖是使用 Dragon Naturally Speaking 的 Gmail 截圖，疊了一層有數字編號的超鏈接。用戶可以說出數字，並與相應的鏈接交互。如果一個鏈接默認不顯示，只有 hover 時才顯示，那可能就只能在空白處顯示一個數字。

這種「hover 後才顯示」的可操作控制項的做法很受歡迎。它可以作為計算機科學家艾倫·凱（Alan Kay）所提出的成熟的可用性啟發法（well-established usability heuristic）的解決方案。

Simple things should be simple, complex things should be possible.

- Alan Kay

這種啟發法（heuristic）說得對，但所謂的複雜性應該對所有用戶（包括殘疾人）都是可能的。

不幸的是，對於無障礙設計，許多人都認為應該符合如下說法（這不是 Alan Kay 說的）：

Primary things should be visible, secondary things should be shown on hover.

盡量在設計中採用更有包容性的做法，比如：

• 將輔助操作（secondary action）放置在菜單內，或非模態對話框 (non-modal dialog) 內，而不是只有 hover 才能觸發；
• 適當減輕次要圖標（secondary icon）的對比度，並在 hover 時加強對比度；
• 在 hover 時，採用更加明顯的、或比 normal 尺寸更大的形狀顯示；
• 一個意義明確的圖標（info icon）是比一片空白（ white space） 更好的觸發「填寫內容」的 hover 方式。

案例1：Linkedin 「我的」個人主頁

下面是Linkedin的一個例子。 以下是作者的個人資料頁面中的屏幕截圖。

下面是滑鼠 hover 時的效果：

立刻出現了一些視覺提示，告訴我可以分別編輯這張card上的許多信息，包括姓名、職位、之前工作、教育經歷、個人頭像照片。

當我在某一項上 hover 時，那一項就變成藍色，告訴我它準備好被點擊了。

這種做法不太符合「無障礙設計」原則。

下面，是為滿足「無障礙設計」做的一個改進方案。我在每一項後面都放上更小的鉛筆圖標，他們一直顯示。

當我在某一項上 hover 時，整條項目變藍。

也許，多數設計師看到我的修改方案時，都會問：這會不會太重了啊？（「That』s kind of heavy, isn』t it?」）

也許是的。但這只是這個問題的其中一種解決辦法。

更進一步說，這隻存在於我自己的 porfile page。一個人會花多少時間看自己的 LinkedIn profile？這種所謂的「感覺重」，和是全局的無障礙設計是同等重要的嗎？如果我們不喜歡加鉛筆圖標這種解決辦法，我們還可以想出其他什麼解決方案呢？

案例2：Evernote 筆記列表

下面是另一個例子，Evernote。這是筆記列表。只有 hover 時，才會顯示 4 個操作圖標。

在這個案例中，我希望 4 個圖標常駐顯示在每條筆記 card 上。也許圖標可以是綠色，hover 時反色。

這個解決方案也許還是會被評價「太重了」！

但請記住，我們並不只為設計師而設計，我們是為各種各樣的、有著不同需求、不同條件、不同電腦使用方式的用戶而做設計的。

1.7 移動、閃爍的內容是否是可停止的？

界面上一直移動、滾動、閃爍超過5秒的內容，都應該可以被暫停、停止，或隱藏。

一般的，對於閃爍內容，每秒閃爍次數不宜超過3次。

1.8 盲人用戶如何使用只能聊天機器人（Chatbot）

這篇文章探討了這一問題：We need to talk about Accessibility on Chatbots，by：

Caio Calado（2017.6.30）

文章首先提出問題：How would a blind person use a chatbot? How would he or she interact wit it?

然後親身測驗了Google』s Allo、 Slack、 Facebook、 VoiceOver 等產品在 iOS 上的 chatbot，效果並不盡如人意。

進而提出：

If we want chatbots to be used by billions of people around the world, we need to make them accessible for everyone.

As an UX designer, I need to design in order to solve people』s needs and pains, not only and just for users』 goals.

如今，尤其像 Facebook 、 Google 、Twitter 等這樣的用戶遍布全球的公司，越來越關注無障礙設計，Caio Calado相信這一切在不久的將來終將會被改善，他說：

I don』t know how, but if anything… I am here to help as well.

2 聽覺無障礙設計

「聽覺障礙」包括：聽不清/聽不到到界面發出的聲音。

設計要點：

• 讓文本內容容易被理解，適當使用「文字替代」（ text alternatives ）
• 確保界面上的所有空間，在沒有聲音時（without sound），仍可正常使用。

3 行動無障礙設計

「行動障礙」包括：不能操作滑鼠、鍵盤、或觸屏。

設計要點：

• 確保所有界面控制項交互都可只通過鍵盤完成（ functionally accessible from a keyboard ）或者只使用滑鼠；
• 確保界面控制項被輔助技術（assistive technologies）正確標記；這些用戶可能會使用諸如語音控制軟體（voice control software）和物理切換控制（physical switch controls）等技術，這些技術一般使用與屏幕閱讀器（screen reader）等其他輔助技術相同的API。

3.1 提供可用鍵盤控制的「獲得焦點」顯示狀態

有些用戶在使用web 產品時，不方便使用滑鼠，如果 web 產品可以僅通過鍵盤操作，會為其帶來更好的使用體驗。

設計師可以設計一種符合本網站風格、同時能提供明顯視覺線索的「獲得焦點」狀態指示，而不是僅僅使用瀏覽器的默認樣式。

Focus highlighting 應該只被用於頁面中的可交互元素，如輸入框、按鈕等。

但問題是許多網站並沒有自己設計一種「獲取焦點」狀態的視覺樣式，這對於以使用鍵盤為主要瀏覽方式的用戶來說，體驗很不好。主要因為效果太丑，而非不滿足「無障礙設計規範」。

下面例子是 BBC 的，用「blue bar」指示哪一個tab是當前的「獲取焦點」狀態。

下面是 Twitter 的例子，採用了3中方式結合的辦法，顯示「獲取焦點」狀態：

1. 默認藍框框
2. icon由灰變綠
3. tooltip

提供了充足的視覺指示。

3.2 彈窗

使用彈窗時注意，焦點元素要在彈窗內，而非在彈窗背後。

左邊錯誤做法：用戶沒法與彈窗交互；

右邊正確做法：焦點落在2個按鈕上，用戶可選擇相應操作，或者關閉彈窗。

3.3 hover 時的焦點狀態

如果一個元素需要hover 才能顯示更多操作，那麼當鍵盤控制焦點落在該元素上時，要顯示出hover 觸發的更多操作。(可以和前文 「1.6 別讓用戶到處 hover 才能找到答案」結合著看)

好範例：facebook。

keyboard only users 把焦點落在 「like」上時，會顯示出 hover 時展示的更多表情。

反例：Product Hunt。焦點落在「share」「save」控制項上時，不顯示任何hover觸發的更多操作。

下面是正誤兩種做法的比較：

左邊錯誤做法：Focus states 完全忽視 hover actions，直接跳到下一個 focus element。

右邊正確做法：Focus states 允許用戶與hover 觸發的動作交互。

還有一個比較好的例子是 Gmail：

每個條目在「焦點狀態」時：

• 都有特定的、明顯的狀態區分（左側的 blue bar）；
• hover 時的更多操作，在「焦點狀態」時自動顯示；
• 只有可操作控制項有「焦點狀態」。

3.4 快捷直達內容的操作

對於僅用鍵盤的用戶，如果每次都讓他們依次選中每個控制項才能到達內容，使用起來是很痛苦的。

比如這個blogging 平台：

比較好的做法是在最開始，提供一個捷徑，讓焦點直接跳轉至內容。

比如 AirBnB 這樣：

左邊：獲得焦點之前的普通狀態。

右邊：激活「獲得焦點」在最開始提供一個選項，直接跳轉至內容，無需依次路過每一個tab菜單。

3.5 重新獲得焦點的場景（re-focus）

當一個控制項從界面上被刪除後，焦點應該顯示在「周圍與被刪除相關」的控制項上。

不好的做法是刪除一個元素後，讓焦點從當前元素消失，回到頁面頂部。這樣的話，用戶得重新走一遍 focus 從頂部移動到當前位置的過程。

左邊錯誤做法：的刪除「1」後，焦點消失。

右邊正確做法：刪除「1」後，焦點顯示在「2」上。

3.6 保持使用的一致性

這是「無障礙設計」中一個很重要的問題。

詳細可參考 W3C』s Authoring Practices for Design Patterns有做詳細解釋。這是關於如何創建許多常見設計組件的「無障礙設計」指南，包括菜單、對話框、自動完成內容、樹形結構等。每種組件模式都有一套相應的 HTML 語言、鍵盤操作，和 ARIA 屬性。 ARIA 屬性說明了用戶如何使用鍵盤與屏幕上的組件交互。

自動完成輸入模式（autocomplete）：用戶在輸入框輸入一些內容，下面自動顯示一列經過篩選的相關結果。用戶可以用上下箭頭或者滑鼠定位或選擇列表中的一個項目。

下面看下「自動完成輸入」的例子：

下面這種是前面加了 icon 的自動完成輸入顯示的列表：

下面是個混亂的自動完成模式案例：用戶不僅可以從過濾的列表中選擇一個項目，還可以通過點擊「鉛筆」或「垃圾桶」圖標來編輯或刪除每個列表項。 這兩個按鈕的添加讓「自動完成」輸入模式變得混亂。

問題主要因為：打亂了自動完成輸入模式的鍵盤使用行為。「選擇」+「操作」的雙重操作容易造成使用混淆，也不便於鍵盤控制。

相似的規則也適用於menu。

下面的2個例子中，右邊的才是真正的 menu，左邊的其實是個 non-modal dialog（非模態對話框）。（根據 W3C』s WAI）

Menu 是一種 為用戶提供一列選擇的 widget。如果我們為每一行加進多重操作（像左邊例子），那它就不再是 menu 了。這也會改變鍵盤的操作行為，從單純使用 arrow key，到 還需使用 tab key；同時也會改變鍵盤獲取焦點的處理方式，比如當 dropdown 收起後，鍵盤獲取焦點的顯示位置就不同。

若能弄清兩者區別，以及對用戶體驗的影響，非模態對話框也可以做到滿足「無障礙設計」標準。理解一個微小的設計變化，如何改變用戶交互模式，會幫助你為自己的產品選擇合適的交互模式。

4 認知無障礙設計

「認知障礙」意味著用戶可能需要輔助技術（assistive technologies）來幫助他們閱讀文本，因此文本替代方案（ text alternatives）的存在非常必要。

設計要點：

• 避免重複或閃爍的顯示方式，因為這可能會為認知障礙用戶造成使用不便（issues）；
• 給用戶留出充足的時間操作（ repetitive ）。

「無障礙設計」自查清單

Is your UI component accessible?

• Visual：界面上的控制項、文字的對比度是否滿足 WCAG 最低標準？界面去掉顏色後是否可以正常使用？ 確保你的 UI 組件可以被不能辨識顏色的用戶使用。 一個叫 SEE 的 Chrome 擴展程序可以模擬色盲用戶看到的界面，Daltonize extension 也有類似功能。
• Visual：界面組件可以在「高對比度模式」下工作嗎？現在時下常用的操作系統都支持高對比度模式。「High Contrast」是一個 Chrome extension ，可以模擬測試。
• Visual：可以用「屏幕閱讀器」使用所有 UI 控制項嗎？是否提供了所有可見文本信息的 文本替代方案（text alternatives ）？你用 ARIA 增加了語義信息嗎？（ semantic information）
• Hearing：你的用戶界面組件可以無聲地工作嗎？ 關閉揚聲器全工程使用測試下。
• Motion：所有 UI 控制項，是否可以只通過鍵盤操作？是否能避免用戶陷入「焦點陷阱」（focus traps）？能否對鍵盤操作做出合適響應？

最後

Web 的一大作用就是更好地實現了人與人之間的交流與合作，「無障礙設計」在其中扮演著重要的角色。

也許你覺得在你的設計中要考慮這些種種規則，限制了你的創造力。

但如果這些規範限制將你的創造力推向極限，你就很有可能會做出既美觀，同時還能滿足更廣泛人群使用的設計。如果關注點正確，你就會發現在任何挑戰面前，都可以去尋找一系列解決辦法，去滿足主管、營銷團隊、Dribbble followers、等所有用戶包括殘疾人的需求。

「Do the hard work so our users don』t have to」, 是 Gov.UK platform 最初的設計原則之一。

「英雄所見略同」的還有這段話：

Doing the hard work to make a service work well for everyone will make your service better? ?for everyone.

- Tom Loosemore, Group Director of Digital Services, The Co-Op

也許你目前沒有足夠的時間和預算來做「無障礙設計」，但只要你把「無障礙設計」當做你日常工作要考慮的標準的一部分，你就會驚喜地發現，你其實能夠滿足很多無障礙設計標準。

將問題分解為可實施的小任務，可以一步步接近終極目標。比如，使用「對比度測試工具」測試你的色板，進而選用對比度更科學的顏色；寫容易理解的文字；使用容易看清的字體；把內容規劃得清清楚楚，讓不同模塊之間一致連貫；盡量減少設計中的雜亂等分散注意力的東西；寫有用的說明文案……

改善所有你能改善的，影響團隊中的其他人，很快，你就會感覺到你的產品越來越好。不要低估自己所能做的改變。

Doing something is always better than doing nothing, every small change simply means your product is better optimised, with more people able to have a good experience with it.

- Ian Hamilton, Accessibility Specialist

-END-

參考文章：

• 7 Things Every Designer Needs to Know about Accessibility，by：Jesse Hausler，2015.4.16
• Designing accessible products，by：Adhithya，2017.4.14
• Tips for making accessibility a core design principle，by：Oliver Lindberg，2017.8.31
• Accessible UI Components For The Web，by：Addy Osmani，2016.7.23
• Accessible Interface Design，Part 1: On Designing With Accessible Color，by：Nick Babich，2016.4.8
• We need to talk about Accessibility on Chatbots，by：Caio Calado，2017.6.30，主要講：How would a blind person use a chatbot? How would he or she interact with it?
• PS: 對 Accessibility fundamentals 感興趣開發同學，可以去了解下 Udacity 的這門免費課程：Accessibility Tooling

相關規範、工具：

• WAI-ARIA Authoring Practices： W3C 規範的各種控制項的無障礙標準，值得參考。
• Accessibility testing tools：介紹一些無障礙相關測試工具。
• Anybody can be an A11y Slacker：the A11y Slackers channel is full of people from around the world who』ll try to help.

其他工具：

• The Web Accessibility Toolbar (free add on for Internet Explorer)
• The Color Contrast Analyser (free desktop application for windows and Mac)
• aViewer (free desktop application for windows )
• W3C Nu markup HTML conformance checker
• Firebug (free Firefox extension)
• Dom Inspector (free Firefox extension)
• Accprobe (free open source desktop application)
• Accessibility Inspector (free Mac appplication)
• UI Browser (NOT free Mac appplication)
• aXe?—?automated accessibility testing for your framework or browser of choice
• The Accessibility DevTools extension for Chrome provides a helpful audit for discovering accessibility issues, including issues within Shadow DOM. It』s powered by the Accessibility DevTools module and a CLI is available that also uses this work for continuous integration audits.
• Tenon.io?—?useful for testing common accessibility problems. Tenon has strong integration support across build tools, browsers (via extensions) and even text editors.
• You can examine the way that assistive technologies see web content by using Accessibility Inspector (Mac), or Windows Automation API Testing Tools and AccProbe (Windows). Additionally you can see the full accessibility tree that Chrome creates by navigating to chrome://accessibility.
• The best way to test for screen reader support on a Mac is using the VoiceOver utility. You can use ?F5 to enable/disable, Ctrl+Option ←→ to move through the page and Ctrl+Shift+Option + ↑↓ to move up/down tree. For more detailed instructions, see the full list of VoiceOver commands and the list of VoiceOver Web commands.
• tota11y is a useful visualiser for assistive technology issues built by Khan Academy. It』s a script that adds a button to your document that triggers several plugins for annotating things like insufficient contrast ratio and other a11y violations
• ally.js (by Rodney Rehm) is a library that tries to simplify adding a few accessibility features to your app. It helps query the DOM for all focusable or tabbable elements, traps focus to specific DOM sub-trees, helps determine how focus has changed and comes with several other helpers.
• On Windows, NVDA is a free, open source screen reader which is fully featured and rapidly gaining in popularity. However, note that it has a much steeper learning curve for sighted users than VoiceOver.
• ChromeLens helps develop for the visually impaired. It』s also got great support for visualising keyboard navigation paths http://chromelens.xyz/
• ChromeVox is a screen reader which is available as a Chrome extension, and built in on ChromeOS devices. However, it currently doesn』t read content in Shadow DOM.

推薦閱讀：