Web開發中最該知道卻從不重視的 —— Accessibility

• 作者：陳大魚頭
• github： KRISACHAN

什麼是Accessibility？

圖片來自WHAT DOES A11Y EVEN MEAN?

Accessibility，通常縮寫為 A11Y ，這縮寫取的是首字母 + 中間字母長度 + 結尾字母，譯為 “可訪問性”。這是一種讓儘可能多的人訪問我們所開發的網站的技術概念，通過這個概念，讓網際網路訪問公平變得可能。

A11Y是一件非常正確的事，在某些國家與地區，甚至提供無障礙站點已經成為了法律的一部分。

在MDN上有這麼一句話：“Web根本的目的是為了服務於所有人，而不是受限於軟硬體，語言，文化，位置以及身心狀態。”（原文：The Web is fundamentally designed to work for all people, whatever their hardware, software, language, culture, location, or physical or mental ability.）

Web Accessibility，譯為 “網頁親和力（又稱網路無障礙、網路可達性、網路可用性、網頁可訪問性）” 。

無論是一般人或者是身心障礙的朋友，都需要有規範的網站方可便捷地獲取資訊，無障礙網頁則是擴充對網頁的規範，以更嚴謹的態度及條件來設計網頁，使網頁內容落實“無障礙”讓不同程度或需求的使用者，可以順暢的獲取網站上的資訊。

意思就是，即使是部分有瀏覽障礙的使用者，也是我們在開發的時候所需要考慮的，那麼我們日常需要考慮的障礙型別有哪些呢？

我們所應該關注的障礙型別

根據W3C所處的Web內容無障礙指南（WACG） 所提到的，主要的障礙型別有以下四類：

• 視力障礙
• 聽力障礙
• 行動障礙
• 認知障礙

世界衛生組織(World Health Organization)的殘疾和健康(Disability and health)狀況說明書指出，“超過10億人，約佔世界人口的15%，患有某種形式的殘疾”，“1.1億至1.9億成年人在功能上存在重大困難。”

視力障礙（Visual impairments）

視力障礙，是指視力下降到一定程度，導致某種程度的問題無法通過通常的手段（例如眼鏡）解決。有些人還包括因無法接觸眼鏡或隱形眼鏡而導致視力下降的人。視力障礙可能會導致人們在日常日常活動（例如駕車，閱讀，社交和步行）中遇到困難。這部分的人通常會使用一些輔助的功能來閱讀螢幕，例如放大鏡，螢幕縮放以及螢幕閱讀器。常見的螢幕閱讀器有：

• 付費的產品：JAWS (Windows) 和 Dolphin Screen Reader (Windows)。
• 免費的產品：NVDA (Windows)，ChromeVox (Chrome, Windows and Mac OS X)和 Orca (Linux)。
• 內建的產品：VoiceOver (macOS, iPadOS, iOS)，Narrator (Microsoft Windows，ChromeVox (on Chrome OS)和 TalkBack (Android).

聽力障礙（Hearing impairments）

聽覺障礙又稱聽力缺損，指聽覺部分或完全喪失，而耳聾人士則是指完全沒有或幾乎沒有聽力者。聽力缺損可能發生在單耳或雙耳，有可能是暫時或永久性質。孩童的聽力問題可能影響語言學習，而對成人可能造成工作上的困難。對某些人而言，尤其是老年人口，聽力缺損可能造成孤獨感。

聽力障礙的人可能聽力水平低或甚至完全聽不見聲音，聽力受損的人可能會使用ATs(請參閱針對患有聽力、語音、言語或語言障礙的人的輔助裝置)，不過在Web中並沒有專門的ATs可以使用。

行動障礙（Mobility impairments）

行動障礙是指一個人不能使用他/她的一條或多條四肢，或缺乏行走、抓取或抬起物體的力量。輪椅、柺杖或助行器的使用可用於輔助行動。活動能力障礙可能由多種因素引起，如疾病、事故或先天性疾病，也可能是神經肌肉和骨科損傷所致。

聲控輪椅是提高行動障礙人士生活質量最重要的發明之一。聲控輪椅最初發明於1977年。

缺少手臂或者手指的障礙人士會嚴重影響使用鍵盤與滑鼠，但是在近些年，語音識別裝置跟軟體都有了極大的發展，也為這部分障礙人士提供了不少的便利。

認知障礙（Cognitive impairments）

認知障礙是一種範圍廣泛的殘疾型別，從能力最有限的智障人士到我們隨著年齡增長和思考和記憶困難而出現的所有人。 該範圍包括患有精神疾病的人，例如抑鬱症和精神分裂症。 它還包括有學習障礙的人，例如閱讀障礙和注意力缺陷多動障礙。 重要的是，儘管認知障礙的臨床定義存在很多差異，但與之相關的人們會遇到一系列常見的功能問題。 其中包括難以理解內容，記住如何完成任務以及因網頁佈局不一致而引起的混亂。

另外提一點，就是癲癇患者也屬於我們認知障礙者的範疇，我們在開發的時候，這部分人士也是我們需要考慮的。

在MDN上有為了認知障礙者總結的開發守則：

• 用多種方式展示內容，例如通過文字，語音或視訊；
• 編寫易於理解的內容，例如少用方言或者顏文字；
• 重要的內容要細心寫；
• 儘量減少干擾，例如一些沒什麼用的功能與廣告；
• 網頁佈局與導航要一致；
• 常規的元素樣式，例如帶下劃線的連結（未訪問時為藍色）和訪問時為紫色；
• 流程互動要具有進度以及步驟指示；
• 使用者許可權認證方式要簡單；
• 錯誤資訊要展示清楚；
• 表單要便於填寫與操作。

WCAG

Web內容可訪問性指南(WCAG)是由網際網路的主要國際標準組織全球資訊網聯盟(W3C)的Web可訪問性倡議(WAI)釋出的一系列Web可訪問性指南的一部分。它們是一組使Web內容更易於訪問的建議，主要針對殘疾人，但也適用於所有使用者代理，包括高度受限的裝置，如行動電話。WCAG2.0，於2008年12月釋出，並於2012年10月成為國際標準化組織標準，ISO/IEC 40500：2012。WCAG 2.1於2018年6月成為W3C推薦標準。

WCAG主要指南如下：

可感知性（Perceivable）

資訊和使用者介面元件必須以可感知的方式呈現給使用者。

• 為所有非文字內容提供替代文字，使其可以轉化為人們需要的其他形式，如大字型印刷、盲文、語音、符號或更簡單的語言。
• 為時基媒體提供替代。
• 建立可用不同方式呈現的內容（例如簡單的佈局），而不會丟失資訊或結構。
• 建立可用不同方式呈現的內容（例如簡單的佈局），而不會丟失資訊或結構。

可操作性（Operable）

使用者介面元件和導航必須可操作。

• 使所有功能都能通過鍵盤來操作。
• 為使用者提供足夠的時間用以閱讀和使用內容。
• 不要設計會導致癲癇發作的內容。
• 提供幫助使用者導航、查詢內容、並確定其位置的方法。

可理解性（Understandable）

資訊和使用者介面操作必須是可理解的。

• 使文字內容可讀，可理解。
• 讓網頁以可預見的方式呈現和操作。
• 幫助使用者避免和糾正錯誤。

魯棒性（Robust）

內容必須健壯到可信地被種類繁多的使用者代理(包括輔助技術)所解釋。

• 最大化相容當前和未來的使用者代理(包括輔助技術)。

WAI-ARIA

Web Accessibility Initiative –可訪問的富Internet應用程式（WAI-ARIA）是由全球資訊網聯盟（W3C）釋出的一項技術規範，該規範指定了如何增加網頁的可訪問性，尤其是動態內容以及使用該工具開發的使用者介面元件。 Ajax，HTML，JavaScript和相關技術。

前言

WAI-ARIA是A11Y應用規範，主要就是針對於上述的障礙型別以及WCAG要求的技術細則，運用好這些技術細則，那麼瀏覽障礙人士便能輕鬆訪問我們的應用。

在本文，我們討論下前端裡的WAI-ARIA規範，以下是規範裡的三個主要特徵：

角色（Roles）

WAI-ARIA角色是使用role屬性在元素上設定的，類似於role屬性[role]中定義的role屬性。

例子如下：

<li role="menuitem">Open file…</li>
複製程式碼

此分類中的role可選屬性如下：

如上圖，role 可選屬性有點多，但其實主要就分了四類：

1. 抽象角色（Abstract Roles）
2. 小部件角色（Widget Roles）
3. 檔案結構角色（Document Structure Roles）
4. 地標角色（Landmark Roles）

其主要作用為：

• 角色資訊描述。
• 相關角色的等級資訊。
• 角色上下文。
• 引用其他規範中的相關概念。
• 使用OWL（Web Ontology Language）提供允許語義繼承的型別層次結構。
• 每個角色支援的狀態和屬性。

狀態與屬性（States and Properties）

WAI-ARIA提供了可訪問性狀態和屬性的集合，這些狀態和屬性用於支援各種作業系統平臺上的平臺可訪問性API。輔助技術可以通過公共的使用者代理應用（例如讀屏軟體）DOM或通過對映到平臺可訪問性API來訪問這些資訊。當與角色結合時，使用者代理應用可以為輔助技術提供使用者介面資訊，以便隨時傳遞給使用者。狀態或屬性的更改將導致向輔助技術發出通知，這可能會警告使用者發生了更改。

我們來看個例子：

<li role="menuitemcheckbox" aria-checked="true">Sort by Last Modified</li>
複製程式碼

上面的例子裡，使用了一個<li>來建立一個可點選的選單，通過JS的事件來改變aria-checked，從而讓使用者代理應用理解這部分的功能作用。

由於這部分是使用者主動進行的操作，並非預設狀態，所以為了更佳的體驗，我們可以對aria-checked="true"時li進行樣式處理，如下：

[aria-checked="true"] { font-weight: bold; }
[aria-checked="true"]:before { background-image: url(checked.gif); }
複製程式碼

WAI-ARIA狀態與屬性分類如下：

1. 小部件屬性
   • aria-autocomplete
   • aria-checked (state)
   • aria-disabled (state)
   • aria-expanded (state)
   • aria-haspopup
   • aria-hidden (state)
   • aria-invalid (state)
   • aria-label
   • aria-level
   • aria-multiline
   • aria-multiselectable
   • aria-orientation
   • aria-pressed (state)
   • aria-readonly
   • aria-required
   • aria-selected (state)
   • aria-sort
   • aria-valuemax
   • aria-valuemin
   • aria-valuenow
   • aria-valuetext
2. 實時區域屬性
   • aria-atomic
   • aria-busy (state)
   • aria-live
   • aria-relevant
3. 拖放屬性
   • aria-dropeffect
   • aria-grabbed (state)
4. 關係屬性
   • aria-activedescendant
   • aria-controls
   • aria-describedby
   • aria-flowto
   • aria-labelledby
   • aria-owns
   • aria-posinset
   • aria-setsize

焦點管理（Managing Focus）

WAI-ARIA裡提倡，所有的使用者互動物件都應該是可聚焦的，就是鍵盤可選中的。

當我們使用標準的HTML標籤以及WAI-ARIA小部件時，開發者應該按順序建立鍵盤可訪問的節點，例如Tabs鍵，方向鍵等。

開發者應該對以下的容器角色進行焦點管理：

• combobox
• grid
• listbox
• menu
• menubar
• radiogroup
• tree
• treegrid
• tablist

焦點管理這部分內容其實一個更加感性的內容，很多時候我們得依賴我們的業務邏輯以及技術選型。

例如在如今很常見的單頁面應用裡，當我們進行路由切換，或者通過AJAX進行內容更改的時候，對於視力正常的人來說，我們很容易就會知道了，但是如果是依賴讀屏軟體的失明人士，可能會不知所措，我明明是點選了下一頁，怎麼內容不知道讀到哪裡去了？

例如這樣：

<nav>
  <a href="/">Home</a>
  <a href="/goods">goods</a>
  <a href="/user">user</a>
</nav>
<main>
    <Link />
</main>
複製程式碼

但是如果我們加上切換路由或者進行資料互動時重置焦點的功能，那麼對讀屏軟體來說，便可以重頭開始讀，對失明人士來說便不會感覺到突兀：

<nav>
  <a href="/">Home</a>
  <a href="/goods">goods</a>
  <a href="/user">user</a>
</nav>
<main>
    <h1 tabindex="-1">魚頭家的商城</h1>
    <Link />
</main>
<script>
    function routerChange() {
        const heading = document.querySelector('h1')
        heading.focus()
        document.title = heading.textContent
    }
</script>
複製程式碼

後記

關於 Accessibility 的知識，不是一篇文章就能解釋清楚的，本文只是對一些基礎內容進行解釋，希望大家後續可以多對這個概念進行了解。

魚頭我關注這個領域也已經有一段時間了，越是接觸，越發現A11Y的重要性。

在之前一次出國旅遊的時候，一次晚上，眼鏡忘帶了，身邊的朋友也跟自己走散了，因為自己是近視眼，到了晚上看物體會更看不清楚，所以在朋友找到我之前的心情，真的非常不好，語言不同，內心是充滿恐懼的。

所以在後面接觸到這個概念之後，心裡面很有感觸，也非常希望能為有瀏覽障礙的朋友做點什麼。

同時也希望堅持看到這裡朋友也能多多關注，傳播這個概念，將所知道的知識運用到自己的專案裡，雖然從理性的角度上來看，對商業利益並沒有太大的輔助，但是對於部分有閱讀障礙的朋友來說，確是非常重要的。

魚頭後續也會對上述的一些概念以及開發細則進行詳解，有興趣的可以持續關注。

參考資源

1. mds.is/a11y/
2. www.w3.org/TR/wai-aria…
3. developer.mozilla.org/en-US/docs/…
4. tao-wai.gitbooks.io/wai/content…
5. www.zhangxinxu.com/wordpress/2…
6. zhuanlan.zhihu.com/p/29359260
7. www.w3.org/Translation…
8. www.w3.org/Translation…
9. developer.mozilla.org/zh-CN/docs/…
10. zh.wikipedia.org/wiki/聽覺障礙
11. zh.wikipedia.org/wiki/視力受損
12. zh.wikipedia.org/wiki/運動言語障礙
13. accessproject.colostate.edu/disability/…
14. zhuanlan.zhihu.com/p/53821168
15. www.w3.org/TR/2014/REC…
16. www.w3.org/TR/2014/REC…
17. www.w3.org/TR/2014/REC…
18. www.bbc.co.uk/guidelines/…
19. www.bbc.co.uk/guidelines/…

後記

如果你喜歡探討技術，或者對本文有任何的意見或建議，非常歡迎加魚頭微信好友一起探討，當然，魚頭也非常希望能跟你一起聊生活，聊愛好，談天說地。 魚頭的微訊號是：krisChans95 也可以掃碼關注公眾號，訂閱更多精彩內容。