簡介： 最近一直在思考一個問題：“在互動團隊這么多年了，什么樣的互動項目是有溫度的呢？又應該如何構建有溫度的互動項目呢”？想了很久，接下來以我自己角度的理解來嘗試著回答，如果回答不對之處，還請路過的大神拍磚指正。

作者|廖偉華(大貘)
出品|阿里巴巴新零售淘系技術部

最近一直在思考一個問題：“在互動團隊這么多年了，什么樣的互動項目是有溫度的呢？又應該如何構建有溫度的互動項目呢”？想了很久，接下來以我自己角度的理解來嘗試著回答，如果回答不對之處，還請路過的大神拍磚指正。

什么是互動項目

什么是互動項目呢？我想圍繞著互動這個詞來說：

• 互指的是相互，比如說相互溝通與交流
• 動指的是動起來，元素動起來，人動起來

放到一起的話：相互動起來

回到互動項目中來的話，在不同的時期經歷了不同的過程：

• 項目元素動起來，只有A自己在動
• 項目和人動起來，A和B或A和C在動，具有一定的交互行為
• 項目和人動起來，除了A和B或A和C在動，甚至是B和C也能在動

比如2016年年貨節的項目：

讓頁面元素動起來，主要還只是提高活動的氛圍

時至今日，互動的項目要變得更為復雜，業務難度也更為復雜：

更像一個簡單的游戲。

為什么要做有溫度的互動項目

先來給大家看一個在線項目，金幣莊園錄屏效果：

為什么要放這么一個錄屏效果呢？其實這是有一個故事的。

一直以來，自己都在探索Web可訪問性相關的技術，不過大部分經驗都是停留在PC端，而如今天是移動端的天下，所以想看看在移動端上如何來做Web可訪問性。特別是在這樣的互動項目（帶有游戲化）又應該如何做Web可訪問性？帶著這樣的問題，開始征程。

但在2019年雙11的時候，主互動多人PK項目上線了，公關部的同學看到支付寶的有無障礙方面的能力，希望我們的項目也能具備無障礙方面的能力。

起初我和老板說，我們的具備了這方面的能力，只要開啟了讀屏就有效果。結果呢？

打臉了！打臉的同時我就納悶了？為啥呢？排查了半天，結果因為一個小細節帶來了致命的結果。也因為這個事情，我覺得互動在可訪問性方面還有更多的事情可做。

除了這個原因之外，后面了解到手淘APP的用戶群體，就視障人士還是有一定的量。

如果將視野放得更大一點，不僅針對視障人士做可訪問性，那這個量又是多少？再加上我國正在進入老年化時代，那么在不久的未來，視力存在障礙的人士只會越來越多。那么我們就有必要，也應該去主動的承擔這樣的責任，讓自己的產品能讓更多的人，更好的使用。

加上看到雙11蓋樓的互動活動能讓更多有訪問障礙的人得到一個更好的體驗時，再次讓我自己堅定了一個信驗：我們除了做到處處有互動，人人可開發之外，還應該做到有溫度的互動：

如何構建有溫度的互動項目

在聊如何構建有溫度的互動項目之前，先簡單的和大家說一Web可訪問性。可能我對于有溫度的理解還過于片面，但讓一個產品的可訪問性更好，能讓更多的人有更好的訪問，甚至參與進來。特別對于有訪問障礙的人士來說，這就是一種溫暖。

? 什么是Web可訪問性

目前互動項目大多數都是圍繞著Web（也就是大家所說的H5）進行的，因此在接下來的文章中只和大家探討Web方面的。

Web可訪問性是Web Accessibility的譯文，很多時候也被譯為Web無障礙。其中Web是指我們的Web網站或Web應用，Accessibility是指可訪問性（很多時候也被人稱為無障礙），但我更喜歡稱之為可訪問性。

Accessibility常常又被稱為A11Y：

A11Y也成了“可訪問性”的代名詞！

正如前面所說的，很多同學喜歡把可訪問性稱為無障礙。一度的認為，只要讓盲人人士可以正常訪問（操作）Web網站或Web應用，該應用就具備可訪問性（無障礙就做得好）。其實這是一種錯誤的認知。因為我們所說的可訪問性，其目標是：盡可能多的人使用你的網站。

換句話說：為失能人士提供與非失能人士同等機會。這里所說的失能根據具體形式和嚴重程度各不相同，但主要可以分為四種：認知、視覺、聽覺，以及活動能力。

人們可能在上述任何一種或多種能力方面有所欠缺。這些可以稱之為“主要障礙”，通常我們考慮的可訪問性針對的也是這些障礙。徹底失明，徹底失聰，徹底喪失活動能力，身體或認知互動能力大幅受限，這些情況是障礙的最主要標志。不幸的是這些很大一部分人都面臨這些困擾，讓這些人也能有機會使用信息和技術獲得樂趣，這一點非常重要。然而還有一個更大的現實問題需要考慮，我們每個人都有可能步入老齡階段，也會在某些方面面臨一些障礙，哪怕程度并不像上文說的那么嚴重。另外還有“情境失能（Situational disability）”，所有人都可能受到這種情況的影響。

想想看在嘈雜環境中想聽清別人說的話，或在面對壓力或精力不集中的情況下想事情時的效果吧。面對外語，尤其是連字母表都和你的母語截然不同的語言，這足以算得上情境失能了。簡而言之，有些情況下所有人都能從具備可訪問性的產品中獲益。

想象一下下圖的場景：

我們再來看一下W3C標準組織是如何解釋可訪問性的：

“Web accessibility means that people with disabilities can use the Web. More specifically, Web accessibility means that people with disabilities can perceive, understand, navigate, and interact with the Web, and that they can contribute to the Web. Web accessibility also benefits others, including older people with changing abilities due to aging.” - W3C (World Wide Web Consortium)

大部分開發者都有類似這樣的一個潛意識，輕易地認為所有用戶都能看見和使用鍵盤、鼠標或觸摸屏，并且與網頁內容的交互方式與自己相同。這會造成一些人能夠獲得良好的體驗，其他人則會遇到從簡單煩惱到重大障礙的各種問題。

那么，可訪問性（無障礙功能）就是指這樣一類用戶的體驗，他們可能不在“典型”用戶這一狹窄范圍之內，并且與網站的訪問或交互方式異于常規。具體地講，它所涉及的用戶是屬于前面所說的“失能人士”。

盡管我們在探討可訪問性時往往是圍繞身體有缺陷的用戶，但實際上都能將其與我們使用的界面由于其他原因而無法訪問的經歷聯系起來。您是否曾在手機上使用桌面版本網站時遇到問題？是否看到過“您所在地區不提供該內容”消息？或者是否在平板電腦上找不到熟悉的菜單？這些都屬于可訪問性問題。

隨著了解的深入，您會發現在這種更廣泛、更普遍意義上解決可訪問性問題幾乎總能讓所有人的用戶體驗得到改善。

有了這樣的認知之后，我們就來進入互動項目中如何做可訪問性，從而構建出具有一定溫度的互動項目。

? 如何構建可訪問性應用

前面我們花了一些篇幅介紹了什么是可訪問性以及為什么重要。但問題在于通常只有在開發工作進入尾聲后才會考慮可訪問性。而且可訪問性通常是一個非常昂貴的過程，尤其是當主要開發工作已完成，系統已經完善后才考慮的時候。但我要說的是，可訪問性依然是值得投入的。

正如像前面所說的，從道德的角度來看，這樣是正確的，也是一個企業和開發者應有的社會擔當。而且在很多地方對此甚至有法律要求，尤其是政府機關和他們選擇的承包商都要考慮到這一點。對業務來說，讓產品更具可訪問性這本身也是合理的，因為這一過程可以改善每個人最終獲得的可用性。

那么作為開發者，我們應該如何來構建一個可訪問性應用呢？

構建一個可訪問性應用最簡單的方法是采用可訪問性構建方法，就好像在一堆技術中從頭開始構建Web或應用程序一樣，每種技術都自己的角色。就像你在開始構建應用程序之前需要仔細考慮要使用什么后端語言（比如是PHP還是Java），前端需要使用什么框（比如是Vue還是React），對于可訪問性應用的構建也應該這樣做。

換句話說，如果你想成為一個Web開發者，學習一些HTML、CSS和JavaScript是很有用的，但是僅僅使用這些技術往往是構建不好一個可訪問性的應用。也正因為如此，WebAIM的調查分析中會有那么多Web首頁達不到可訪問性。接下來從以個幾個方面展開，來聊聊如何快速構建一個具有高可訪問性的應用。如果你感興趣，歡迎繼續往下閱讀。

★ 可訪問性標準和準則

W3C組織的互聯網可訪問性行動為互聯網和開發者制定了相應的標準和準則，其中最重要的兩項是：

網頁內容可訪問性準則，即Web Content Accessibility Guideline，簡稱WCAG 2.0
可訪問的互聯網富應用標準，即Web Accessibility Initiative – Accessible Rich Internet Application，簡稱WAI-ARIA

WCAG準則

2008年，W3C發布了Web內容可訪問性指南WCAG 2.0版本，該指南已被廣泛接受為Web可訪問性的全球標準。雖然WCAG 2.0不是一個法律文件，但許多政府已經通過了基于之約的網頁可訪問性立法。2018年6月，W3C發布了WCAG最新版本，即2.1。

該版本保留了所有WCAG 2.0需求并添加了新的需求。由于WCAG 2.1的要求非常新，大多數政府還沒有要求這些標準。一般的建議是，各組織應在2019年朝著WCAG 2.1標準方向努力。對于那些已經遵循WCAG 2.0的人來說，這并不是一個大的飛躍。

WCAG 2.0由四個基礎性原則組成，根據這四個原則的首字母，它們被稱為POUR：

• 可被感知的（Perceivable）：信息以及各種交互元素必須可以被用戶看到或者聽到
• 可操作的（Operable）：用戶可以在產品界面和導航中進行操作，并能使用諸如屏幕閱讀器等輔助技術
• 可被理解的（Understandable）：信息的展現和用戶的操作交互必須邏輯清晰一致，以便能被用戶充分理解
• 健壯的（Robust）：網頁和應用程序中的內容必須確保在各個平臺和環境中都能正確地展示，包括在使用了輔助技術的情況下

將這四點作為WCAG 2.0的基礎原則是將可訪問性思維融入設計中的重要一步，因為這四個原則為設計得提供了可以滿足用戶需求的方法，而非簡單地提供一個羅列著技術要求的清單。這四項原則解釋了“為什么”還要保證互聯網產品的可訪問性，其他的技術要求則解釋了“如何去”保證互聯網產品的可訪問性。我們需要使用“POUR”原則來思考并明確用戶的需求，再用WCAG 2.0具體規則來做符合要求的設計。

另外，W3C的《如何滿足WCAG 2.0：快速參考》提供了這些原則中所有要求的詳細說明。如果你堅持每一個，就可以很容易構建一個可訪問性網站或應用。

是否滿足WCAG 2.0準則，分為三個級別：A、AA和AAA：

• A級通過最基本的可訪問性標準
• AAA級是通過最高級別的可訪問性標準

A、AA和AAA就好比我們住的酒店，有一星級，二星級等區別

而在一些法律法規中，要求Web網頁或應用程序的可訪問性級別需要達到AA級別，所以這也是大多數組織和開發者所追求的級別。這對于各方來說都是較為理想的，因為AA標準提供了強大的Web可訪問性，同時又保留了靈活的設計和功能。

WAI-ARIA

2014年，W3C發布了可訪問的互聯網富應用標準，最新標準是1.2版本。

互聯網富應用標準也為開發互聯網管理工具和諸如瀏覽器和媒體播放器之類的軟件提供了指導準則。WAI標準主要的目的在于解決應用的可訪問性問題，它與HTML5標準同屬于W3C組織。WAI標準對于互聯網產品的可訪問性至關重要，因為該標準從最基礎的層面影響著網頁和應用程序的可訪問性。

在社區上可以找到大量和WAI標準相關的教程，借此推薦大家閱讀一篇《How People with Disabilities Use the Web》，可以更清楚的了解和知道殘障人士如何使用互聯網。

★ 普適設計原則

著名的建筑設計師@Ron Mace說過：

普適設計的目的在于無須額外適應和個性化設計的情況下，讓產口可以最大限度地被所有人無障礙地使用！

普適設計原則的前提是認為典型的、理想的所謂“正常用戶”是不存在的，用戶情境會隨著周圍環境的變化而變化，因此需要用“隨需而變”的精神來貫穿設計流程，確保設計能夠滿足不同場景下的多種用戶需求：

• 平等使用：設計不應該歧視任何一類用戶
• 良好的適應性：設計應該對大多數用戶的個體偏好和生理情況都良好的適應
• 簡單直觀地使用：無論用戶的知識水平，閱讀能力和精神集中程序如何，設計都應該做到簡單直觀易理解
• 確保信息可以被感知：無論用戶的周圍環境以及自身的感知能力如何，設計都要將信息有效地傳達給用戶
• 容錯性：當用戶做出設計之外的操作時，設計應將用戶的操作帶來的負面影響限制在最低程度
• 使用省力：設計應該讓用戶的操作舒適而高效，不易疲勞
• 適宜操作的尺寸：無論用戶的體型、姿態和移動能力如何，他們都當有合適的大小和空間來進行各種訪問與操控

普適設計原則之所以充滿吸引力，就在于它提供了一種目的明確的設計方法，這種設計方法在保證視覺美觀的前提下，能夠創造出讓生個人都能舒適使用的產品。盡管普適設計原則被提出于互聯網誕生之初，但其中的各項規范對今時今日的互聯網設計仍有指導作用。

★ 設計性思維

設計性思維是由@Tim Brown提出的：

像一名設計師那樣去思考會改變你開發產品、提供服務、制定流程乃至確定戰略時的思維方式。

設計性思維背后的哲學是這樣的：如果你僅僅在考慮技術細節，那你最終將會得到一個無法滿足用戶需求的純技術型產品，但是如果你能開拓思路，將產品所在的社會環境以及用戶的個體特性都納入考慮，那你將會開發出真正以用戶為中心的產品。設計性思維中的諸多方面對于可訪問性設計都起著舉足輕重的作用。

• 集成和迭代：貫穿整個項目的設計工作都應考慮，而不應僅僅把精力集中在優化產品的視覺效果上。應預先為產品準備好一系列備選方案，然后通過構建原型、測試的迭代過程并根據反饋探索出最佳的設計方案
• 發散性思維：不要限制自己的想象力，應該仔細審視目前方案是否是最優解而不是匆匆忙忙地開始編寫代碼實現方案。在項目進入編寫代碼實現功能的階段之前，發散性思維往往可以產出具有良好可訪問性的創新性解決方案
• 收斂性思維：結合使用場景去選擇最有效的設計方案，對于可訪問性設計來說，則是選擇最能適應多樣的互聯網環境并滿足多種個性化需求的方案
• 以人為本：實踐設計性思維的關鍵在于理解用戶的欲望、需求和行為習慣，理解了這些才可能確定項目的方向，并利用用戶的反饋來優化產品的設計方案
• 洞察力：想獲得良好的洞察力，就必須知道如何才能滿足不同用戶訪問互聯網的各種個性化需求，也就是說要去觀察用戶的使用場景，看看他們做了什么，聽聽他們說了什么。洞察力來源于同理心，而同理心又可以來源于故事。換句話說，同理心和洞察力，可以激發大家的創造力和發散性思維，最終想出更具創造性的可訪問性設計方案

★ 使用設計性思維提升可訪問性

設計性思維可以改進網頁可訪問性設計的慣常做法，目前，可訪問性設計方面的大多數工作都僅僅局限在關注修改細節以便符合指導規范上，這種做法只能產生有限的漸進式改進，但是如果在可訪問性設計中運用設計性思維，則問題就會迎刃而解，大量的新想法也會由此產生。

在很多情況下，可訪問性只有在項目開發的末期才會被考慮，而無論對于開發者還是用戶來說，解決一個已經成型產品的可訪問性問題都會存在很多障礙—— 這類似于在已經竣工的大樓旁邊額外搭建一個木頭梯子。

設計性思維要求將對于可訪問性的關注貫穿整個項目流程，并充分考慮不同場景下的用戶需求。你應該當在項目開始就把設計性思維融入到工作流程中，而不是在產品成型之后再對其做可訪問性工作的小修小補，而且在設計性思維的指導下，你還可以使用你的既有經驗去挖掘需求，制作原型，進行測試，從而讓你的優雅的產品始終都具有良好的可訪問性。

WCAG + WAI-ARIA + 普適設計原則+ 設計性思維= 人人都能使用的互聯網

★ 從開發的角度來看可訪問性的構建

構建一個具有可訪問性的Web應用不僅僅是設計或者開發某一個環節就可以做好的。要做好一個具有可訪問性的應用，在產品整個構建過程中每個環節都應該努力去做好自己的本職工作。就拿我們開發者而言，需要考慮的東西絕對不僅僅是簡單的擼碼，或者按自己以往的經驗擼碼即可。

作為開發者，在構建可訪問性Web應用之前，首先要改變的就是自己的看法和端正自己的態度。為什么這么說呢？仔細回想一下，你在開發一個Web應用的時候是否有真正的去關注過可訪問性，是否有真正的去為你的用戶考慮過。如果沒有，說明你是一位未及格的開發者，哪怕你的技術再厲害。因為你“沒有責任，也沒有擔當”。

而很多開發者，他是真心的想把自己的產品做到最好，希望給自己的用戶提供最好的體驗。但往往很多時候，他們并不知道如何真正的去做，就好比我們聊的可訪問性。

接下來我將以一個開發者的角度來聊聊，如何更好的構建一個可訪問性的Web應用。

僅僅掌握HTML、CSS和JavaScript技術棧是構建不好一個具有可訪問性的Web應用。

簡單地說，想要構建一個可訪問性Web應該，就應該從可訪問性的開發堆棧開始說起。

眾所周知，在前端開發者的認知里，一個Web頁面或應用都是有HTML、CSS和JavaScript三個部分構成：

每個部分各斯其責：

其中HTML會經過HTML Parser將HTML結構轉換成DOM Tree；CSS會經過CSS Parser將CSS轉換成CSSOM Tree，正如下圖所示：

熟悉瀏覽器工作原理的話，知道DOM樹和CSSOM樹的結構可以構建出Render Tree：

最終經過幾個過程就渲染出我們所能看到的Web頁面：

但這對于構建可訪問性頁面而言是不夠的，我們需要借WAI-ARIA相關的準則，這樣一來，構建一個可訪問性頁面就有四個部分構成：HTML、CSS、JavaScript和WAI-ARIA：

如果在你的Web應用中加入WAI-ARIA之后，將會在DOM、CSSOM的基礎上新增AOM（Accessibility Tree）：

用一個簡單地小示例圖向大家演示：

在瀏覽器渲染地過程中，可訪問樹（AOM Tree）和DOM樹是并行結構。粗略地說，可訪問樹是DOM樹的子集。它包括用戶代理的用戶接口對象和文檔的對象。可訪問對象是在可訪問樹中為每個應該暴露給輔助技術的DOM元素創建的，因為它可能觸發一個可訪問事件，或者因為它有一個需要暴露的屬性、關系和特性。

通常情況下，如果某些內容可以被刪除，那么它就會被刪除，這是出于性能和簡單性的考慮。例如，只有樣式更改而沒有語義的可能無法獲得自己的可訪問對象，但是樣式更改將通過其他方式來處理。

雖然大家對于HTML、CSS和JavaScript都不陌生，但這每個部分在可訪問性的構建中都有著自己原則和要求。

★ 構建可訪問性的基本原則

@Jeremy Sydik在《設計可訪問的網站》一書中針對網站的可訪問性給出了十個基本原則。對于希望讓自己的網站更易于訪問的人，這些原則可以在系統的設計和創建過程中提供極為有用的指導：

• 可行的情況下不要假設你的用戶在身體、精神、以及感官方面具備相同程度的能力
• 用戶所用的技術能夠發送和接收文字，這是你唯一可以做的假設
• 用戶的時間和所用技術屬于用戶自己，不屬于我們。如果沒有足夠必要的原因，絕對不能控制這些
• 為任何非文本內容提供足夠好的文本描述
• 通過使用率最廣泛的技術接觸你的受眾
• 使用簡潔的語言傳達你的信息
• 確保你的網站可用、可搜索、可導航
• 按照語義設計你的內容，內容和呈現方式之間維持獨立
• 通過添加額外功能漸進式地增強基本內容，允許不愿或不能使用這些功能的用戶以得體的方式“降級”
• 遇到新的 Web 技術后，為確保其可訪問，也要為這些技術應用上述這些基本原則

除了使用這些原則指導我們設計更可訪問的體驗外，還可以使用其他一些技能對網站的可訪問性進行測試。@Albert Gareev 開發了一套為測試工作提供指導的助記短語：“ HUMBLE（謙遜）”：

上圖來自于@Albert Gareev的《HUMBLE：Agile Accessibility Testing Strategy》一文。

簡單的描述一下HUMBLE的含義：

• H – 人性化（Humanize）：有同理心，了解情緒的不同成分
• U – 忘卻（Unlearn）：遠離你默認采用的 "針對具體設備進行設計" 的習慣，有能力切換至不同的習慣模式
• M – 模型（Model）：借助不同角色幫你看到、聽到、感受到具體問題，并要考慮行為、節奏、精神狀態和系統狀態
• B – 構建（Build）：發展知識、啟發性測試法、核心測試技能、測試基礎結構，以及可信度
• L – 學習（Learn）：障礙到底在哪？用戶如何感知、理解和操作
• E – 實驗（Experiment）：將自己置身于不同情況下，與設計師和程序員合作并提供反饋

? 互動項目構建可訪問性的歷程

有了上述的理論依據做為支承，接下來結合到互動項目中來看，是具體怎么做A11Y的。

★ 互動項目的結構

互動項目和其他的Web應用（H5項目）還是有所差異的，其中最大的差異就是：互動的項目帶有游戲化的場景，而且交互方式也更為復雜。我們來看幾個互動的項目視覺稿：

其最的特色就是：游戲化場景和主交互元素相結合。如果用Web元素來描述的話就是：Canvas畫布和DOM元素的結合：

上圖中綠色區域就是Canvas畫布，也是游戲區域，在Web中有關于canvas中A11Y的處理至目前還沒有較好的技術，因此接下來的內容會先忽略canvas中的內容。上圖中高亮的都是DOM元素，而且這些高亮的部分也是鏈路交互元素。

簡單地說，進入到主互動首頁，主要操作還是這些具備交互的元素之上，那么這些元素如果具有A11Y的能力，有障礙的人士訪問就不會有障礙。

因此，在設計技術方案的時候就需要考慮這一點。為什么這么說呢，我們來看兩個實際項目的對比：

左側是雙12人民寶貝的互動項目，當初選擇的技術方案整個游戲區域和行動點都是在同一個Canvas畫布內，這也致使了該項目如果在做可訪問性，難度和成本都非常的大，而且到目前沒有較好的技術方案；右側不同的是，只有蓋樓的游戲區域（動畫區域）是在Canvas畫布。相比之下，右側雙11多人PK（蓋樓的活動）要做可訪問性會輕松的多。

選擇比努力更重要，也適用于此。

★ 構建可訪問性應用如何編碼

對于開發者來說，更為關心的是如何編碼才能讓應用更具可訪問性。前面也提到過：構建一個可訪問性頁面就有四個部分構成：HTML、CSS、JavaScript和WAI-ARIA：

這幾個部分對于構建可訪問性來說都非常的重要，如果要完全的講清楚的話，都可以寫本書了，為了節約篇幅和大家的時候，只會介紹一些關鍵部分。

HTML 對可訪問性的影響

在社區中經常可以看到這樣的一個討論話題：HTML語義化的重要性。其意思是指我們應該盡可能地用正確的HTML標簽來表達正確的意圖。特別是在現代Web的開發當中（尤其是使用JavaScript框架，比如React和Vue等），在構建Web頁面或應用的時候，越來越多的同學不再考慮HTML的語義化。在2019年的React Conf大會上@BrittanyIRL分享的Accessibility Is A marathon, Not A Sprint話題中也特別的提到這方面：

看到上圖，你可能有同感！

或許你可能會想，“用戶看到的僅僅是呈現后的效果，他們（甚至是你的老板）并不會太多的關注語義化（他們也有可能不懂啥是語義化）”。這里用一個簡單的示例來說明它對可訪問性的重要性。

使用語義化元素特別是一些UI控件（指的是與用戶交互控件），比如button、a和表單控件是具有高可用性。瀏覽器都知道如何處理它們，它們為用戶提供了與網站進行適當交互所需的一切。比如下拉選擇框就是一個很好的例子。如果在Web中使用默認的表單控件要比使用

模擬下拉選擇框的可用性更高。如下圖所示:

上圖中左側是Safari瀏覽器下的表現效果，右側是iOS移動設備上的表現效果。

HTML有近百個元素標簽：

面對一百多個HTML元素標簽，怎么選擇才能讓自己的選擇是對的。我們可以按照下圖這樣的一個流程來選擇：

除了選擇具有語義化的標簽元素之外，對于元素的屬性也應該根據具體的使用場景來選擇。比如元素，它的type類型有很多種，如果選對了，對于用戶的交互是友好的，比如下圖所示：

同樣的input，不同的type喚起的設備鍵盤就是不一樣。假設你要輸入的是一個電話號碼，你試想一下，喚起來的鍵盤只有數字鍵，是不是心情很爽，也無需花更的時間去做選擇。

除此之外，我們還可以根據下面的這些原則來構建自己的HTML或模板：

• 使用最具語義化的HTML標簽元素
• 結構和樣式的分離
• 定義文檔的語言類型非常重要
• 隱藏內容
• 不要遺忘的alt屬性
• 包含描述性內容鏈接
• 使用通俗易懂的語言
• 允許僅通過鍵盤訪問內容
• 在必要時使用ARIA

回到我們的項目中來：

嘗試著問自己，上圖標出來的能回答出來？回答的是正確的嗎？

CSS 對可訪問性的影響

一直以為我都認為，Web的可訪問性只和HTML相關，而事實上并非如此。CSS對于可訪問性的影響也是蠻大的。比如排版的可讀性、顏色的對比度、可聚焦元素的焦點樣式等等。下面簡單的來看幾個我們能經常接觸到的。

構建易讀到可讀的文本

如何構建易讀到可讀的文本，這里引用@Marcella Jalbert在她的博文《How to design for readability – a guide to successful web typography》中提供的一張圖來闡述，正所謂一圖勝過千言萬語：

事實上文本排版所涉及的知識和信息量非常多，而且其中很多都和可訪問性有關。在一篇文章中是無法把所有東西和大家聊清楚的。后續我們可以再花時間來和大家一起討論排版和可訪問性方面的話題

1、顏色對比度

說到顏色對比度，可能很多同學會認為，這跟前端有啥關系，這不是視覺的活嗎？如果從設計的角度來看的話，顏色的選擇和決定權是在視覺那里，但最終還原的是開發者，如果顏色使用對可訪問性有影響的話，我們有責任對其糾正，或和視覺設計師一起討論。不過，有的時候現實是很殘酷的，正如@Sheri Byrne-Haber 在他的博文《10 things that indicate designers have no clue about accessibility》中闡述的一些觀點，還是有一定的道理的。

回到顏色對Web可訪問性影響這個話題上來。

為網站選擇配色方案時,請確保文本(color)顏色與背景顏色(background-color)對比度良好。您的設計可能看起來很酷,但如果有視覺障礙(如色盲)的人無法閱讀您的內容,則設計就顯得一無事處。

2、可點擊區域應該足夠大

可點擊區域是否合理直接影響了用戶和你的產品的交互，特別是在移動端。大家可能有碰到過，有些產品在按鈕、鏈接、復選框或單選框等操作上就是失效，要點擊很多次才能有效果。造成這種行為就是因為點擊區域過小。可這種交互對于有行動障礙的用戶來說也是致命的一種。

特別是在一些可點擊操作的圖標上，Icon圖標的實際尺寸并不適合一些系統的設計規范，在iOS上就提供Icon圖標可點擊區域應該是48px x 48px，如果你使用的圖標小區該區域的話，我們就應該通過別的方式來進行擴展。比如在一個卡片上，可以讓整個卡片都具有可點擊效應（click事件綁定在）元素之上。如下圖所示：

3、可聚焦元素樣式設置

可以訪問你的應用有一些用戶群體屬于行動障礙中的一部分：

對于有行動障礙的用戶群體而言，訪問性Web應用時主要依賴于鍵盤操作（還有一群高體依賴鍵盤的用戶）。那么元素的焦點樣式的設計對于這些群體來說是非常重要的。

但在移動端的話，對于可聚焦元素樣式往往就顯得不是那么的重要。

4、隱藏內容

使用CSS來隱藏Web的內容經常可見，比如用圖片替代文本，在互動這種重氛圍場景之下，更常用，比如：

CSS實現圖像替代文本的技術方案有很多種，但不同的技術對于可讀性的影響有所不同，特別是對于屏幕閱讀器來說，比如:

眾多方案中，我更推薦使用下面這種方案。該方案在讓元素獲得焦點的時候，隱藏的內容會顯示出來，比如說使用tab鍵，定位到隱藏的元素時會顯示出來：

.sr-only:not(:focus):not(:active) {position: absolute;height: 1px;width: 1px;clip: rect(1px 1px 1px 1px);clip: rect(1px,1px,1px,1px);clip-path: polygon(0px 0px, 0px 0px, 0px 0px);overflow: hidden !important; }

該方案對于屏幕閱讀器特別的友好。要是沒使用sr-only來隱藏元素，而是采用aira-hidden="true"來隱藏元素的話，可以考慮@Nicolas Hoffmann提供的方案。

5、針對特定的場景禁用動效

在Web中很多地方都能看到Web動效的身影，雖然動效應用好的話可以給Web起到錦上添花的效果，但是對于特定人群的話反而不是好事。因為有些動效對這些特殊的用戶群體會造成不良的反應，會引起癲癇。為此，為了避免這種現象出現，媒體特性中提供了prefers-reduced-motion條件來做判斷。只要用戶在設備上開啟了Reduce Motion功能：

并且在代碼中顯式的設置了：

@media (prefers-reduced-motion: reduce) {* {animation: none;} }

ARIA對可訪問性的幫助

我們知道WAI-ARIA是W3C編寫的一套規范，定義了一組可用于其他元素的HTML特性（Attributes），用于提供額外的語義化以及改善缺乏的可訪問性。比如

<div role="button">回到首頁</div>

div標簽是屬性無語義化的一個HTML標簽，通過ARIA技術，即給div標簽加上role（角色），這樣一來一些輔助技術（比如屏幕閱讀器）就知道這個div不是一個普通的標簽，而一個具有按鈕角色的標簽。

正如上面示例所示，ARIA就是這么簡單易于。雖然ARIA是一套獨立的規范，但對于一個Web頁面或Web應用程序而言，ARIA始終離不開HTML，哪怕是通過JavaScript動態來控制ARIA，也最終附加到HTML標簽元素上。如果不想思考太多，可以簡單地理解成：

ARIA所有特性都是HTML的附加屬性（Attributes）。

ARIA整個規范中有三個主要的特性：角色（Role）、狀態（State）和屬性（Property）：

WAI-ARIA可以為可訪問性提供更詳細的信息：

• 角色：這是什么類型的“東西”？比如，它是一個button
• 狀態：它的情況如何？比如disabled、checked
• 名稱：它的名稱或標簽是什么？
• 關系：它是否以某種方式與頁面中的其他元素相關聯？

瀏覽器會將這些信息映射到操作系統的可訪問性API，并將其公開給輔助技術。一旦ATs理解了含義（或目的），它可以自動讀出特定的提示（或相關信息）。

使用WAI-ARIA主要可以做到：

• 讓輔助技術用戶（比如屏幕閱讀器）可以理解定制的小部件（Widget）
• 以編程方式指示元素之間的關系
• 通知用戶動態更新
• 向輔助技術隱藏不相關的可視內容
• 未完全重新編碼的不可訪問內容的修復

但WAI-ARIA并不是萬能的，他的使用也是會受到一定限制的，特別是ARIA的角色和屬性的使用：

• 某些角色只能作為特定復雜小部件的一部分（詳細請見ARIA的角色一節）
• 一些aria-*屬性是全局的
• 其他aria-*屬性只適用于特定的角色
• 并不是所有的角色或屬性都得到一致的支持或實現

雖然WAI-ARIA在某些場景之下能增強HTML標簽的語義化，但這并不代表他是萬能的。特別是對于剛接觸WAI-ARIA而言，你始終要記得WAI-ARIA不是魔法，也不是萬能的，他僅僅只是改變了輔助技術解釋內容的方式。具體的說；

WAI-ARIA還有很多事情是做不到的：

• 不能讓非聚焦的元素得到焦點
• 提供適當的鍵盤綁定
• 改變瀏覽器的行為
• 自動維護或更新屬性
• 變化可見的UI視覺（除CSS使用特性的選擇器重構UI風格之外）

可以說，WAI-ARIA是一個龐大的體系，涉及的知識點和相關信息也非常的多，要用好WAI-ARIA并不是一件易事，但我們遵循一些使用規則會讓其變得更簡單些。

• 不要使用WAI-ARIA，使用原生HTML標簽元素
• 除非真的需要，否則不要更改原生語義
• 所有交互式ARIA控件必須與鍵盤一起使用
• 不要讓可聚焦元素變得中立（Neutralise）
• 所有交互元素必須有一個可訪問的名稱

如果用一句話來描述的話:NO ARIA is better than bad ARIA!

JavaScript有助于提高可訪問性

在我們平時的開發中，很多同學不會采用具有語義化的標簽，比如頁面中的一個按鈕，用 button 可以讓我們減少很多工作量，但事實上很多人用div這樣的非語義化的標簽來作按鈕：

<divtabindex="0"role="button">Play</div>

為了這個模擬按鈕具有交互行為，就需要使用JavaScript了：

const buttons = document.querySelectorAll('.button');[...buttons].forEach(button => {button.addEventListener('click', doSomething);button.addEventListener('keyup', (event) => {if (event.key == 'Enter' || event.key == ' ') {doSomething();}}); });function doSomething() {console.log('Something!'); }

特別是在做可訪問性的時候，強度依賴ARIA，那么更需要JavaScript方面的加持。比如改變ARIA的狀態。其實這樣的事例很多，這里就不一一列出。

如何檢測和修復可訪問性

通過前面的內容，我們可以構建一個具有一定可訪問性的應用，但不能完全確定其中不存在問題。為了能更好的完善Web的可訪問性，我們可以借助一些工具來幫助我們做檢測和修復其中的不足。前段時間在《創建可訪問性網站并不是想得那么難》一文中對這方面做過一些探討。比如通過一些第三方在線的測試工具或瀏覽器的插件來做檢測：

但這些檢測工作都是一些人肉工作：

除此之外，還可以采用一些NPM包，把關于A11Y相關的檢測集成到自己的工程鏈路中來：

• React A11y
• Vue A11y
• react-axe
• vue-axe
• eslint-plugin-jsx-a11y
• eslint-plugin-vue-a11y
• agnostic-axe

這樣一來就可以做一些自動化的檢測：

這里我需要特別推薦agnostic-axe，因為它不會受限于任何框架:

// src/page/index/index.tsxif (process.env.NODE_ENV !== 'production') {// Import agnostic axe here.// Webpack will comment out this code in production.import('agnostic-axe').then(({ AxeObserver, logViolations }) => {console.log(`?→??💃🏾😃💁👉👉Minor（小錯誤）、Moderate（中等的）、Serious（嚴重的）和Critical（至關重要的）; Serious和Critical必須相辦法修復1. 配置文檔: https://github.com/juliettepretot/agnostic-axe2. Axe Core: https://github.com/dequelabs/axe-core3. https://web.dev/accessibility-scoring/4. https://web.dev/lighthouse-accessibility/💁😃💃🏾??→?👉👉`);const MyAxeObserver = new AxeObserver(logViolations);MyAxeObserver.observe(document);});}

這個時候在瀏覽器會輸出相關的檢測結果和提示修改建議：

雖然這些工具能幫助我們檢測出問題，但要記住，它并不能幫助我們解決所有可訪問性的問題。正如Axe所說：

Please note that only 20% to 50% of all accessibility issues can automatically be detected. Manual testing is always required. For more information see: Web Accessibility Testing, Part 2: Basic Methods and Tools。

待續...

這里不想做總結，因為這是一個持續性的過程，需要我們不斷的堅持。只有這樣才能慢慢的變得更好。最后感謝大家花時間閱讀此文。感興趣的話，請待后續相關更新。如果你對這方面也感興趣，歡迎能一起交流和學習。

總結

以上是生活随笔為你收集整理的淘宝的互动项目，为什么总会刷爆你的好友圈？的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。