[Accessibility] Web Accessibility入门
Web Accessibility
国内公司几乎不会考虑Web Accessibility，这与我们的法律有关，国内的法律并不强制要求Web Accessibility，而像美国，甚至专门出台了一个508康复法案，制订了若干Accessibility标准，一旦某公司的产品不达标，就要面临法律风险。所以很多外企，尤其是在我们国内设立研发中心的，基本上都要了解一点Web Accessibility，我在公司研究过一阵Web Accessibility，没有中文资料，确实挺麻烦，在对Web Accessibility有了大概的了解后，就一直想写一些Web Accessibility的博客，供有需要的朋友浏览，但一直拖到了2020一月中旬才开动，我会尽可能地以汉语习惯表达，但免不了出现一些纰漏，如有谬误，还请大家指教。
什么是Web Accessibility？
Web Accessibility翻译为Web可访问性或Web无障碍环境，指用户（所有用户，包括残障人士）可以轻松访问Web。为此，W3C还发起了倡议——WAI，WAI提供了一系列的规范和标准（WAI-ARIA，WCAG等）。当我们说我们的网站Accessible，那么所有用户访问起来都应该很轻松，这就意味着要对残障人士的体验做一些额外的处理。
为什么要让站点是Accessible？
Accessible的站点不仅让残障人士可以拥有好的体验，健全用户也会因此而受益。
当站点有一个checkbox，点击起来非常难受，我们要很小心地移动鼠标才能准确命中它，而当我们将一个
有时候，一些国家或地区的法律要求站点是accessible的。
像是美国，他们有个508康复法案，要求在联邦经营的站点必须accessible，欧盟也有类似的法律，其他各国很多也有相关的法律或政策限制。所以对于想要走出国门的公司，深入了解Web Accessibility是相当必要的，国内的大部分外企就更不用多说了。
残障人士是一个潜在的巨大市场。
根据W3C的数据，全球预计1 billion残障人士，市场规模高达$7 trillion，有兴趣的可以去了解下：The Business Case for Digital Accessibility
其实还有很多好处，就不赘述了，基本可以说有利无害，因为作为开发者，我们只需要一丢丢的额外工作，加上一丢丢Web Accessibility的知识，就可以让我们的站点变得Accessible。
怎么实现Web Accessibility？
在技术上，我们目前公认的最佳实践（Best Practice）：遵循WCAG的指导，正确使用HTML5语义化标签进行开发，辅之以WAI-ARIA.
当然，在如何实现WCAG标准这个问题上，有很多技巧性的东西，但不在此赘述了，以后有时间再写，本文定位只是入门。
什么是WCAG？
WCAG：全称Web Content Accessibility Guidelines（Web内容可访问性指南），是W3C制定的Web Accessibility的参考指南，说是参考，但目前是公认的Web Accessibility权威标准。
跟随WCAG的指导，我们就不必再花费精力研究：哪种残障人士以哪种方式访问Web，障碍会更少。
W3C推荐直接使用最新版的WCAG 2.1（2018年版），WCAG提供了非常全面的需要考虑的点，每个点还制订了三个等级的成功标准，A级，AA级和AAA级，所有点都达到A级，那么我们网站的Web可访问性就达到了WCAG Level A，以此类推其他等级。一般来说不必追求AAA级，因为有的点想达到AAA级会相当困难。
当网站最终评测Web Accessibility时，我们可以用VPAT去记录我们的网站在WCAG的各个点达到了什么等级，VPAT记录好后可以提供给客户或者挂在网站上，以证明我们的网站是Accessible的，而且可以省去我们去翻阅庞大的WCAG的时间。
什么是VPAT？
全称是Voluntary Product Accessibility· Template，是一个模板，用于标明产品的可访问性达到什么级别，分为几个不同版本，相同点在于都要求符合WCAG标准，这些版本的区别在于附加部分，附加部分遵循不同的标准，如美国康复法案508部分（Section 508）等。
什么是WAI-ARIA？
首先有必要说一下WAI，WAI是Web Accessibility Initiative的缩写，翻译为网页可访问性倡议，绝大部分Web Accessibility的标准、规范都是WAI制定的。
由于Web从早期的一个简单的文档（文字和图片），渐渐进化出了丰富的交互模式，Web进入RIA（Rich Internet Application）时代，而这些交互模式对于残障人士是相当不友好的，有的使用起来很困难，有的甚至连普通人用着都一头雾水，这时候就需要有一个权威的非功利性的机构来指定一些规则，指导开发者开发出交互友好的Web，于是WAI出现了。
WAI为了让RIA也具有良好的可访问性，提供了一个规范——WAI-ARIA，该规范全称是Web Accessibility Initiative-Accessible Rich Internet Application，该规范为HTML5提供了三种新的属性（Attribute）。
- Roles（角色）：该属性用于向辅助设备说明HTML5元素（Element）真实扮演的角色是什么，例如一个a标签的role="button"，那么辅助设备就会将其作为Button处理，而不是将其解析成超链接；
- Properties（属性）：该属性用于向辅助设备提供额外的语义信息，例如一个用于删除的Button，如果我们只是将其颜色设置为表示危险操作的红色，那么辅助设备并不会知道这点，辅助设备用户只会知道这个Button是用来删除的，那么它是删除什么数据的呢，是不是永久删除呢？这些额外的信息就可以通过aria-label属性来提供。
- States（状态）：该属性和Properties作用相似，但不同点在于States代表可变的语义信息，例如上条所说的aria-label，如果aria-label的描述总是改变，那么必然会造成用户的困惑，所以可以下一个定义：Properties的改变有无限多的可能，但States的改变是在几个已知状态之间来回切换。例如aria-hidden表示HTML5元素在显示或隐藏的状态。
WAI-ARIA最重要的一点就是这三种属性并不会对CSS Tree或Dom Tree有任何影响，它只会影响Accessibility Tree的构建，简单来说：WAI-ARIA属性对我们的页面、js脚本没有任何影响。
WAI-ARIA具体有哪些属性就不列举了，这里仅提供相关文档的资源：
- Accessible Rich Internet Applications (WAI-ARIA) 1.1，关于WAI-ARIA的W3C官方的文档，最权威最详细。
- WAI-ARIA Authoring Practices 1.1，也是W3C出品，主要是各种控件的设计原则、最佳实践、在线例子等。
残障人士如何访问Web？
了解残障人士访问Web的方式，有助于我们理解WCAG某些标准制定的意义，帮助我们去更全面的解决可访问性问题。
首先身体缺陷有多种类型，可分为视觉、听觉、认知和运动四种，而这四种缺陷并不一定都是永久性的，例如做了近视眼手术后，视力没恢复之前，就会具有视觉缺陷；再例如骨折了，在康复之前，就会有运动缺陷。我们想一下世界上每天有多少人正处于这种身体缺陷状态呢？我估计仅中国每天都会有大量骨折、手术等等具有暂时性缺陷的人，那么我们对于可访问性的支持就变得非常有意义了。
有身体缺陷的人访问Web一般通过辅助设备，如屏幕阅读器，盲文阅读器等，也有些色弱或高度近视用户会使用浏览器的高对比度或放大功能，总而言之，这些方方面面都在WCAG中有所提及。
什么是ATs（辅助技术）？
ATs（Accessible Technologies），翻译为辅助技术，也叫辅助设备。其中较为重要的就是屏幕阅读器，屏幕阅读器是一种小型设备，通过连接电脑，可以读取大部分我们肉眼可见的信息，并以语音播报的形式展示。
那么信息从何而来呢？信息正是从浏览器的Accessibility Tree中解析出来的，大部分ATs也都是这个Tree中获取信息。其工作原理大致为：
- Browser通过系统提供的API（不同操作系统，API的定义、实现也不同）暴露Origin UI（我们看到的页面，即Dom Tree）的语义化版本（即Accessibility Tree）给ATs；
- ATs获得语义化版本，构建一个替代页面给用户，即通过语音播报描述的页面；
- User通过ATs执行了点击等操作，ATs通过系统提供的API向Browser转述User的意图；
- Browser有义务响应User的意图，并在Origin UI上下文解释User的操作（即模拟真实的点击等操作，触发页面相关部分的变化）；
这里提供一些资源帮助大家更好的理解：
- Accessibility Overview By Goggles，谷歌开发者编写的关于Accessibility的介绍，通俗易懂，深入浅出，还很全面。
- Accessibility Guides By MDN，MDN上关于Accessibility的介绍，更注重技术细节，非常专业。
什么是Accessibility Tree？
Accessibility Tree简单来说就是浏览器构建Dom Tree之后，通过解析Dom Tree的语义信息，将每个Node的语义信息筛选出来，构建成Accessibility Node，进而构建成Accessibility Tree。Dom Tree的改变会影响Accessibility Tree，但对Accessibility Tree的操作并不会反过来影响Dom Tree，而且筛选出的信息是语义信息，更不可能影响CSS Tree，所以说WAI-ARIA对我们的页面无任何影响，原理就在此。
综合上面ATs原理中，ATs读取的只是Accessibility Tree，我们可以得出一个结论：ATs只关注语义信息。足可见HTML5语义化标签的正确合理使用对Web Accessibility多么重要。
用什么工具测试Web Accessibility？
针对浏览器，可以使用很多插件，如Chrome和Firefox有Axe，Wave，这些插件可以自动检测网页内容的Web Accessibility是否有Bug，明确标明违反了WCAG哪条规定，应当如何改进等等相当强大的功能。
个人推荐Axe，不仅免费，而且操作简单易懂，容易上手，UI也是我最喜欢的简约风，而且注册的用户可以使用更强大的测试功能，针对不同的内容提供了单独的测试模块，还可以生成测试Report，防止开发者互相扯皮。
还可以使用桌面应用程序Nvda，最流行的屏幕阅读器软件，直接模拟残障人士访问Web的方式，对优化Web Accessibility也是很有帮助的。
结语
在公司Share Web Accessibility时，还要靠强调“它同时也是优化正常人体验的途径”来获得认可，真的觉得很无奈，同为人类，是否应该怀有对同胞的怜悯？我们对技术的追求难道只是为了升职加薪？这个本就冰冷的世界中，如果人类社会只允许强者活，弱者死，那人类和动物也并没有两样，还谈什么人性的高贵与伟大呢？
我们是开发者，是Developer，是千千万万平凡职业中的一种，我们做不到视钱财为粪土，但我觉得我们应当具有开发者的道德和追求，这种道德与追求也必将反过来促进我们技术水平的提升，当拥有这种思想的高度，我们的Code不再是商人盈利的硬通货，而是沟通整个社会的桥梁。