原文： Web Accessibility Guidebook for Developers by Nikola Shekerev (KendoReact team的QA工程師)

基於無障礙規範(Section 508, WCAG 2.0 and WAI-ARIA)，在為KendoReact (一套React 的原生UI 組件) 做無障礙優化期間，我們討論了不少無障礙話題，有基礎入門的也有高階深入的。在這篇文章中，我們希望可以將KendoReact 的Web 無障礙優化之路，以及探索到的最佳實踐方案分享給各位。

根據W3C 的定義，有生理缺陷的人也能輕鬆使用，更確切地說是能夠感受、理解、操作產品(比如網站、工具…各種現代技術)，就可以被稱為"無障礙"(accessibility )。

閉著眼睛使用你的產品，測試看看它是否是"無障礙"的。在無法用眼看無法用鼠標，僅僅通過屏幕閱讀軟件對界面的描述去操作你的產品時，人們還能順利地使用那些嘔心瀝血做出來的功能嗎？

為什麼總是無人在意無障礙

大家都在聊無障礙的重要性，但事實上大部分人僅僅是在"談論"而已，為什麼現實中沒什麼人在實踐無障礙呢？主要有以下三種原因。

首先，你真的很難對殘疾人的生理不便感同身受，要處理自己無法體會的情況，確實很難。大多數時候我們缺乏的不是動力，而是所謂的"常識''：生理缺陷到底是怎麼阻礙人們使用我們的站點。這個問題包含兩個方便：哪些生理缺陷會影響用戶使用產品；以及如何調整產品以實現無障礙。對這兩個問題的細節我們還不了解。

其次，實現無障礙的工作量不小。開發者需要先了解標準，參照標准進行開發。開發完成了？很好，下一步是測試，有大量的手工測試在等著你。後面我們將分享一些實踐經驗，有了這些經驗開發者可能輕鬆一些，但總體上來看還是有很多工作要做的。

第三點，營收壓力決定了設計導向。很好理解，在商業項目中不太可能為了少數用戶而延遲交付，關注大部分用戶的需求才是核心要義，所以無障礙優化往往會被推到下一個、再下一個…版本。

為什麼無障礙很重要

倫理意義

生理缺陷者的日常生活相對不便。至少在互聯網中，將服務平等的提供給你的用戶是最基本的尊重。

市場

10億網民中有20%的人或多或少都有一些障礙，從比例來看的確算少數，但10億的五分之一也不容忽視。

法律

隨著法律體系的不斷完善，未來會有明確的法律條例約束互聯網應用的無障礙體驗。這一點在後文會展開描述。

用戶體驗

遵循無障礙指南可以讓用戶更好地使用你的站點，無障礙的優化還能提高可用性，這是對所有用戶都是有利的。比如提高文字的可讀性，也有利於視覺正常的用戶的體驗。

工程

總體來看，有著良好無障礙體驗的產品往往也有良好的設計和工程化。如果一份代碼已經不忍直視了，那也不用對這個產品的無障礙抱有什麼期待。對於想要成為匠人的我們而言，做好無障礙只不過是職責內的的一部分而已。

口碑

無障礙體驗比你的對手要好，這無疑是一個頗有競爭力的優勢。能大大提升品牌口碑。

SEO

其實SEO 和無障礙優化是有重疊的。比如具有良好語義化的HTML 結構對SEO 和無障礙都有幫助，所以要正確的使用標籤屬性，正確對待label、video transcription、image captioning，還有title 和header 標籤。

立法

世界各地的法律都在往規範化無障礙體驗的方向邁進，未來無障礙會成為一個產品的標配。美國的無障礙推進由ADA負責，許多發達國家都有類似的法律，比如應該有2010年平等法案。目前，根據這些法律，政府相關的公共組織或者經營都必須按照WCAG規定實現無障礙。

無障礙優化的對像不僅僅是你的用戶。如果你所在的組織人數超過50人，也許你的團隊中也有生理缺陷的人，所以即使是內部工具也做好無障礙。

美國專用：另外，如果你在為政府部門工作，除了上面需要注意的，還要確保遵守了Section 508 of the Rehabilitation Act 。法律規定，所有美國政府服務都需要遵守這一條規定。

這些法律可不只是善意的擺設。越來越多的法律被付諸行動，更詳細的進度可以查看無障礙與法律這篇文章。

生理障礙的類型，以及無障礙的最佳實踐

聽覺、視覺、行動和認知，大部分生理障礙集中在這四個方面。不同類型包含多種情況，它們或多或少都影響了人們使用互聯網，所以需要網站或者應用開發者為這些用戶做好無障礙優化。讓我們分別探索它們的最佳實踐吧。你將會發現這些實踐基本和底層技術無關，更多的是我們如何設計自己的產品。這也意味著，在創造這個產品的過程裡，團隊中的每一個人都可以貢獻一份自己的力量。

聽覺障礙

從輕微的聽力受損到完全聽不到都能算聽覺障礙。要提高這類用戶的用戶體驗，就要保證你的產品不只依靠聲音來傳遞訊息，提供音頻的同時還需要提供別的媒介。比如，當你使用視頻時，確保它有完整的字幕。如果你用的是音頻，也別忘了文本描述。字幕和描述都要完整，不要遺漏了訊息。後文中，我們將會羅列出可讀性指南，開發者可以根據這份指南參照自己的字幕和文本是否合理。除此以外，還要注意音視頻中的噪音影響，保證受眾可以準確地接收到消息。

視覺障礙—視力低下

優化低視力人群的用戶體驗最重要的方法是，提供一個可讀的界面。 UI 元素要足夠大且清晰。文字的情況更複雜一些，詳情可以看後文的可讀性指南。這份指南意在指導開發者優化低視力人群的使用體驗。

對比度是另一個重要的方面。界面元素的顏色有著高對比度有助於低視力用戶閱讀。你可以在這裡找到WAI (Web Accessibility Initiative)推薦使用的工具，用於檢查對比度是否合理。現在大量頁面設計的對比度都大有問題，畢竟視覺政策的用戶會覺得高對比度的主題"辣眼睛"。既不想犧牲產品設計又想滿足視障用戶的需求，折中方案就是，提供切換主題的入口，就和語言切換類似。

視覺障礙—盲人

盲人使用讀屏軟件。這類軟件的原理是解析HTML 結構，然後用自然語言向用戶描述解析結果。針對屏幕閱讀器的開發有其特殊之處，我們會重點在後文中講解。另外，失明用戶所使用的輸入設備也有所不同。一般不會使用需要"看"的鼠標，盲人更多使用的是鍵盤。

視覺障礙— 色彩障礙

即是是色盲也分有各種各樣不同情況。請注意，接下去所說的只是這種疾病的冰山一角。綠色弱最常見，這種缺陷會導致患者看不到綠色。類似的，紅色弱認不出紅色，相對綠色弱的患者數量要少。這兩種情況的可見光譜上比較相近，以"紅綠色盲"廣為人知。藍色弱指的是無法辨別藍色，這種情況相當罕見。

上述每種情況中還有輕重之分，從輕微的知覺問題到完全看不到相應的顏色。如果是缺少部分知覺，我們使用前綴'nomaly'；如果是完全無法看到顏色，用'nopia' 做前綴。完全的色盲相當少見，患有這種缺陷的人眼裡只有不同深淺的灰色。顏色感知的變化影響的整個視覺光譜，而不僅僅是一種顏色。

你的初衷可能是選擇一種大部分有色彩障礙的人都能識別到的顏色。但由於有各種色弱，且每種色弱的情況有輕有重，要選出這樣一種顏色相當困難。不過橘色和藍色還算能滿足大部分情況。這就是為什麼互聯網產品裡藍色如此常見。

有很多工具可以模擬有色彩障礙的人使用你的站點時的體驗。你可以用這些工具感受一下，如果需要的話，可以為色彩障礙用戶設計一套主題。

更好的解決方式— 不只用顏色傳遞關鍵訊息。還可以用形狀、符號、動畫等等媒介來表達。

運動障礙

需要快速或者重複執行某個動作，比如長按一個按鈕或者在規定時間內完成某項操作，這些對於有運動障礙的人來說都比較困難，如果他們強行做到這些動作，可能會造成生理不適。你最好盡可能地避免採用這些動作，不過這不是件容易的事情。比如在滑動滑塊的時候，你可能需要按住一個按鈕來保證它持續滑動。想到了運動障礙的人們，於是你改變方案，換成每輕觸一次按鍵滑塊滑動一點距離，但毫無疑問，這樣"改進"成了重複的動作，同樣為運動障礙的人們帶來負擔。所以在這方面，我們的建議是，你需要保證你的產品無論使用鼠標操作還是用鍵盤都是很好操作的。

認知障礙—與暈動症和感官超載相關（比如癲癇）

有很多情況會誘導暈動症或者感官超載，特別是一些高速、刺激的事物，比如搖晃、強光、閃光(一秒閃三次以上)。重複的移動、極快的速度都可能刺激到患者。一個典型的溫和的重複模式是"不斷掉落的節日氛圍雪花"。在頁面上使用華麗的變化和急劇的過渡效果也會造成問題。總之就是要溫和。如果你一定要用快速變化的效果，別忘了加一個開關，允許用戶關掉它。

認知障礙—學習障礙

關鍵是要足夠簡單。簡化你的場景、你的界面。盡可能用簡單的描述，不要用那些華麗的詞藻。用精準的語言描述清晰的指令。你的描述要遵守"金發姑娘原則" (Goldilocks principle) — 缺少訊息不是好事，但過多的描述反而迷惑用戶。也不要增加倒計時之類的時間限制，這樣會增加用戶的負擔。

認知障礙—閱讀困難

閱讀困難是一種生理缺陷，患有這種缺陷的人難以閱讀，當他們看著文字的時候會覺得文字在旋轉扭曲或者全部擠在一起。後文中我們將會提出對閱讀性文字的指導，這部分內容可以很好地指導開發者開發出對閱讀困難人群也友好的產品。

可讀性小技巧

保持良好的可讀性可以至少保證一部分生理不便的用戶可以使用你的站點：可讀的字幕和文本分別能幫助到有聽力障礙的人們和視力不佳或者閱讀障礙的人。還有一條經驗之談— 大字號用線條乾脆利落的無襯線字體。

空隙很重要。舉個例子，長長的一行文字是很難閱讀的，70個字符是單行的上限。對字幕來說，35個單詞足夠了。過窄的行間距會使讀者喘不過氣來，1.5倍的行距看上去還不錯。全是大寫字幕的單詞也不容易閱讀。在類似字幕這種會自動播放的場景裡，還需要考慮文字滾動的速度，可以按照0.3秒讀一個單詞的速度來估算更新字幕的時間。

還有一個關鍵點—對比度。背景圖片通常會影響閱讀文字，這種情況下最好在文字周圍加一層邊框，以提高和背景的對比。當然如果非要在文字後面加背景，用純色高對比度的更容易看清楚文字內容。

現在已經有不少字體提高了可讀性，比如Opendyslexic 、 Inter 。

輔助技術簡介

"輔助技術"是一個專業的產業，它指的是輔助殘疾人使用的軟硬件。常見的輸入設備有嘴棒、頭棒、大軌跡球、專用鍵盤、語音識別軟件；輸出設備上有屏幕放大鏡、屏幕閱讀器、盲文顯示器、助聽器、帶有自然語言界面的軟件等等。這其中有些是提高現有技術的無障礙性，有些則是提供了另一種使用計算機的方式。

大多數輔助技術在操作系統層面上已經實現了，web 開發者基本不用做什麼事情。但是，對屏幕閱讀器來說，要做的事可能更複雜一些。屏幕閱讀器的原理是解析HTML，然後將這個結構用自然語言描述出來，可想而知，屏幕閱讀器讀出來什麼東西取決於代碼寫的怎麼樣。所以當web 開發者在做網站的無障礙時，屏幕閱讀器的閱讀效果應該是第一考慮因素。接下來我們會聊到這一方面的最佳實踐。

為屏幕閱讀器做優化

編寫語義化的HTML

要說怎麼做對屏幕閱讀器最友好，那無疑是優化HTML 標籤的語義— 使用有效的HTML 標籤、遵循最佳實踐、根據不同的場景使用不同的HTML 元素。比如如果某個元素無論是行為還是視覺表現都是"按鈕"，那理所應該選擇<button>而不是<div> ；如果要表現一個標題，應該用<h>而不是僅僅用CSS讓它看起來是一個標題。

HTML元素的語義化正式定義可以參考標準。

說起來好像不難，但現實生活會告訴你，這實踐起來不容易。好了，讓我們進入下一節。

遵循規範

和任何基礎技術一樣，互聯網也有多個制定標準的組織。 W3C ( World Wide Web Consortium )就是其中一個，WAI ( Web Accessibility Initiative ))屬於W3C。我們作為開發者需要遵循WAI制定的WCAG ( Web Content Accessibility Guidelines )，這份規範定義了互聯網上主要的無障礙標準。

上文裡我們討論到的不同生理缺陷，在WCAG 中有更詳細的描述。 WCAG 是一份不斷更新不斷進步的標準，在撰寫此文時，WCAG 的版本號為2.1。

WAI還開發了一套WAI-ARIA ( Web Accessibility Initiative - Accessible Rich Internet Applications Suite )，這項技術標準指導了應該如何編寫我們的代碼。開發者需要遵循這份標準才能讓屏幕閱讀器正確地工作。簡潔起見，後文中我會用"規範"來指代WCAG 和WAI-ARIA。

自動測試

有很多自動化檢查工具檢驗我們的站點是否按照規範實施了。它們通常具有這些功能：元素是否遺漏了無障礙屬性；頁面的顏色對比度；HTML 標籤的合法性。我們建議每個季度都做一次全盤的掃描。當然，如果你對這方面要求非常高，你可以將這一步檢查放到CI 或者CD 過程裡。下面羅列的是一些掃描工具，排名不分先後：

• Google Lighthouse
• Axe
• Wave
• Powermapper
• Dynomapper
• Monsido
• Various other tools listed by W3

手工測試

自動測試只能覆蓋很小一部分，如果你想要得到真正有意義的結果，還是需要手動測試你的站點。最好的檢查方法就是— 閉上你的眼睛只用鍵盤和屏幕閱讀器操作你的站點。

邊注：個人看法，這是我感受到做無障礙測試是一件多麼困難的事情。

引導

當你緊閉雙眼時，你無法使用鼠標。在黑暗中通過鍵盤指引你的操作可比用視覺輸入困難得多。閉著眼的操作往往不如你的預期。這樣檢查可以發現一些被遺漏的場景。說了這麼多，我想表達的是— 提供有效的、真正起作用的鍵盤輸入引導非常難。

聽覺的複雜性

市場上有多種多樣屏幕閱讀器，但講真，大多數都不大好用。使用者常常迷惑於閱讀器讀出來的內容。之所以會這樣是因為閱讀器不僅僅將文字讀出來，它們還會盡可能先將界面描述出來，讓使用者的腦海裡有界面的大致結構。可想而知，只有在界面結構簡單，使用場景單純的情況下，閱讀器才能完美運作。所以對開發者而言，最好能盡可能地簡化站點結構。

矛盾

每款屏幕閱讀器的表述略有不同，在不同的瀏覽器下表現也並不一致。你將遇到很多"灰色地帶"，即使完全遵照規範實現，屏幕閱讀器的表現也可能不如預期。在這種情況下，你也許要向市場佔有率高的瀏覽器和屏幕閱讀器妥協。

在實踐中，我們發現以下組合值得考慮：

Jaws

Jaws是目前市場上最資深的屏幕閱讀器產品。同時也是最廣泛被使用的產品之一。你需要確保它可以正常地在你的產品上工作。但Jaws 歷史太久了，以致於它並沒有跟隨規範更新，我們發現最適合Jaws 的平台是IE。

ChromeVox

撰寫此文時， ChromeVox是最新的屏幕閱讀器，因此也是最貼合規範實現的。不過它才剛剛起步，使用者並不多，支持度最好的平台自然是Chrome。

NVDA

NVDA也是一款比較新的屏幕閱讀器，對規範實現良好，它在火狐上廣泛使用，表現也優秀。

關於手工測試的總結

當你在測試時發現在某個瀏覽上屏幕閱讀器能良好運作，你也能多少放心些— 至少滿足了這部分使用者的需求。鑑於日常工作時我們所擁有的的資源有限，我的建議是優先測試上述的最佳組合，如有必要再做更大範圍的測試。

支撐上述論點的數據可以從屏幕閱讀器用戶調查報告中找到。

最後是第三方測試

如果能讓有生理缺陷的用戶幫你測試就更好了，還要積極地向你的用戶收集無障礙問題的反饋。當然，這些事情都應該是在自測通過之後。首先開發者要保證的是用戶不至於完全無法使用產品。這之後再來談真實場景下的用戶反饋，才是有意義的。

最佳工作實踐

教育

在解決問題之前，先要意識到所謂"問題"的存在。你需要在團隊中宣傳無障礙的重要性。忽略動機地去做一件正確的事情，是很難到達預期高度的。

話也說回來，無障礙優化不是團隊中某一個人的工作，而應該是所有人的責任。從開發者到設計師都應該有這樣的意識。撰寫本文的初衷也是— 和工程師同行們佈道、分享無障礙相關的訊息。

文檔

前文也提到了，無障礙優化不是一個精確的學科，你常常會發現自己處於一個灰色地帶，需要摸索著前進。遇到這種情況時，最好的做法就是記下你的方法，整理成文檔。傳授一個小技巧，你可以記錄下自己這麼實現的理由，標註通過這個實現手段是為了遵守哪些WCAG 條例。整個團隊共同維護這份文檔，灰色地帶將會越來越少。

KendoReact是JavaScript UI組件庫Kendo UI的套件之一。在Progress，我們跨團隊地共享代碼和文檔，一起進步。實踐證明，在無障礙優化上，文檔在其中起到不可小覷的作用。

可用性和無障礙優化不是同一個概念

雖然這兩者之間有很大的交集。本文中討論的大部分無障礙優化，最終會使所有的用戶都受益。可能你花了很多精力提升了產品的可用性，但殘障人士依然無法使用你的產品。如果你想搞明白"可用性“到底是什麼，可以看看下面的讀物：

• 美國政府公開的一份基於研究的web設計和可用性指南；
• Jeff Raskin 編寫的"Humane Interface" 是這個領域的入門讀物；
• 特別推薦Steve Krug 的一本小書"Don't Make Me Think“。

有時候甚至無障礙的方案和可用性的方案會有衝突，這種情況下，出於保證多數人的體驗，我們需要優先考慮可用性。兩者兼得當然是最好的，但就看開發者的創造力了。

使用無障礙體驗良好的工具

Web 無障礙優化很難，但已經有不少前人"填好坑“的產品了，如果場景允許，盡可能地使用這些已經做好無障礙的工具。比如，如果你想要搭建一個簡單的部落格或者站點，WordPress 就是個不錯的選擇。或者我們的KendoReact 也值得考慮。 KendoReact 是一款從零開始就有無障礙意識的工具，有了它，相信你不容易掉進灰色地帶了。

推薦閱讀

關於這個話題更深入的討論，可以在下面的資源里找到：

• Mozilla對WCAG的詮釋；
• a11y項目—核心的社區驅動的無障礙資源和工具中心；
• Google的免費無障礙課程；
• WAI建議的測試工具；
• AccessU —專注無障礙的峰會，頗具口碑；
• WebAIM (web accessibility in mind) —提供無障礙相關服務的組織，服務包括培訓、評估和認證等。

另外，Progress出了一份以無障礙為主題的白皮書— Accessibility for Web Developers可免費下載，其中有很多關於無障礙的細節討論。

結論

本文也是KendoReact 團隊無障礙優化之路的一個階段性總結。我們主要目的是希望開發者可以意識到無障礙的存在，希望我們確確實實將無障礙的重要性和實踐方案傳達給了開發者，大家可以遵循這些方法展開自己的無障礙實踐。有任何想法歡迎大家前來交流（譯者註：可在原文評論中和作者直接討論）。

願無障礙之力與你同在。 (譯者註：原句為'May the Force of Accessibility be with you.')