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可選屬性如下：

[外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-WvLDCjVr-1575899036006)(https://www.w3.org/TR/2014/REC-wai-aria-20140320/rdf_model.png)]

如上圖，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. http://mds.is/a11y/
2. https://www.w3.org/TR/wai-aria-1.1
3. https://developer.mozilla.org/en-US/docs/Learn/Accessibility
4. https://tao-wai.gitbooks.io/wai/content/REFERENCE_FILE.html
5. https://www.zhangxinxu.com/wordpress/2012/03/wai-aria-無障礙閱讀/
6. https://zhuanlan.zhihu.com/p/29359260
7. https://www.w3.org/Translations/WCAG20-zh
8. https://www.w3.org/Translations/WCAG21-zh/
9. https://developer.mozilla.org/zh-CN/docs/Learn/Accessibility/What_is_accessibility
10. https://zh.wikipedia.org/wiki/聽覺障礙
11. https://zh.wikipedia.org/wiki/視力受損
12. https://zh.wikipedia.org/wiki/運動言語障礙
13. https://accessproject.colostate.edu/disability/modules/MI/tut_MI.php
14. https://zhuanlan.zhihu.com/p/53821168
15. https://www.w3.org/TR/2014/REC-wai-aria-20140320/usage
16. https://www.w3.org/TR/2014/REC-wai-aria-20140320/states_and_properties
17. https://www.w3.org/TR/2014/REC-wai-aria-20140320/roles
18. http://www.bbc.co.uk/guidelines/futuremedia/accessibility/html/
19. http://www.bbc.co.uk/guidelines/futuremedia/accessibility/mobile_access.shtml

如果你喜歡探討技術，或者對本文有任何的意見或建議，非常歡迎加魚頭微信好友一起探討，當然，魚頭也非常希望能跟你一起聊生活，聊愛好，談天說地。
魚頭的微信號是：krisChans95
也可以掃碼添加好友，備註“csdn”就行