现代 CSS

创建可访问性网站并不是想得那么难

作者：大漠 日期：2019-11-10 点击：843
CSS
可访问性
Accessibility
会员专栏
A11Y

特别声明：如果您喜欢小站的内容，可以点击申请会员进行全站阅读。如果您对付费阅读有任何建议或想法，欢迎发送邮件至: airenliao@gmail.com!或添加QQ：874472854(^_^)

最近@Robin Rendle和@stefanjudis先后写了篇文章，从同一个角度抛出两个话题：“为什么创建无障碍网站这么难”？和“应该通过增强浏览器开发者工具实时提供开发者开发无障碍网站存在的问题”！那么我想问的是，开发无障碍网站为什么会令大家感觉难以及工具上的实时提示就能让开发变得更容易了吗？如果不是，怎么样来开发一个网站才能符合无障碍规范相关的要求，即具有高可访问性。更直接一点，怎么才能让开发者创建无障碍网站是件轻易而不再觉得是件困难的事情。在接下来的内容，将作为前端开发者的角度来和大家一起探讨这方面的话题。如果你感兴趣的话，请继续往下阅读。

先来看一些数据

2019年08月我国发布了第44次《中国互联网络发展状况统计报告》。我截取了报告中的一些数据：

  • 截至2019年6月，我国网民规模达8.54亿，较2018年底增长2598万，互联网普及率达61.2%，较2018年底提升1.6个百分比
  • 截至2019年6月，我国手机网民规模达8.47亿，较2018年底增长2984万，我国网民使用手机上网的比例达99.1%，较2018年底提升0.5个百分比
  • 截至2019年6月，我国农村网民规模为2.25亿，占网民整体的26.3%，较2018年底增长305万；城镇网民规模为6.30亿，占网民整体的73.7%，较2018年底增长2293万
  • 截至2019年6月，我国网民使用手机上网的比例达99.1%；使用电视上网的比例为33.1%；使用台式电脑上网、笔记本电脑上网、平板电脑上网的比例分别为46.2%、36.1%和28.3%

接下来再来看另一份数据。根据第六次全国人口普查我国总人口数，及第二次全国残疾人抽样调查我国残疾人占全国总人口的比例和各类残疾人占残疾人总人数的比例，推算2010年末我国残疾人总人数8502万人。

各类残疾人的人数分别为：视力残疾1263万人；听力残疾2054万人；言语残疾130万人；肢体残疾2472万人；智力残疾568万人；精神残疾629万人；多重残疾1386万人。

而据世界健康组织的统计，视障人士就达2.85亿，仅我国就有1263万人患视力障碍（2010年末的数据），美国这样的发达国家也有近810万网民患视力障碍。

上面是各种有关于有障碍人群的数据统计。在今年年初（2019年2月），WebAIM使用WAVE独立API（附加工具收集站点技术参数）对100万个网站主页进行了可访问性评估。虽然这项研究的重点是自动检测，但最终的结果是令人感到沮丧的，无障碍化方面做得都不够好。具体的数据可以点这里查看（2019年分析报告 和 2018年分析报告）。

你可能会说这些数据和我们前端开发者（或者产品、设计师）有什么关系呢？

早在1997年10月22日，W3C的主席@Tim Berners-Lee在美国华盛顿国际计划办公室（IPO）启动无障碍网页倡议（WAI）时说过一句话：

The power of the Web is in its universality. Access by everyone regardless of disability is an essential aspect," said Tim Berners-Lee, W3C Director and inventor of the World Wide Web. "

大致的意思是Web的力量在于它的普遍性。每个人不论残疾与否都能访问是一个最基本的方面。

既然如此，我们就有必要让自己的产品除了为普通人提供更好的使用体验之外，还要能让残障人士（用户）正常地与产品交互。

在Web页面或应用中能够给访问页面有障碍的人士提供更好的体验，那就需要使用一些无障碍方面的技术。那么什么是Web无障碍呢？

什么是Web无障碍

任何一个Web页面或应用程序从根本上来说是为所有人设计的，无论他们的硬件、软件、语言、位置或能力如何。当Web达到这一目标时，具有不同听力、运动、视觉和认识能力的人就可以访问它。因此，残疾对Web影响发生了根本性的变化，因为Web消除了许多人在现实世界中面临的沟通和互动障碍。然而，当网站，应用程序、技术或工具设计得很糟糕时，它们可能会造成阻碍，使人们无法正常的使用Web。

对于想要创建高质量网站或应用程序的开发人员来说，无障碍是必不可少的，这就不会让一些人在使用他们的产品和服务的时候被排队在外。

作为一名开发人员，你可能时常看到 “Accessibility” 这个词。在Web发展的初期，人们习惯性将其翻译成“无障碍”，因为它的初衷主要是考虑如何让残障人士更容易地访问Web内容。比如有行动障碍的人士他更依赖于键盘与Web做交互；有视觉障碍人士更依赖于放大屏幕与Web交互；有听力障碍人士更依赖于阅读方式等。但随着互联网的发展，访问Web的场景、设置和人群都更复杂化，多样化。“Accessibility”已不再局限于满足残障人士的需求，它也涵盖了在特定场景下的网站可用必，比如移动终端，弱网环境、忘带鼠标，触模板坏了，老年人访问等等。

在面对这样的新场景、新群体之下，“Accessibility”更多时候被译为可访问性。常常也被缩写为a11y（其中11是指a和y之间有11个字母）。因此，在整个社区你会看到有很多以a11y为名的网站或应用，一般这些网站都是围绕着“Accessibility”相关的内容，比如A11y.meThe A11Y Project和A11yWeeky等。

要是根据W3C的说法来解释的话：

Web可访问性意味着 每个人都可以感知、理解、导航、与Web交互，并为Web做出贡献。在这方面，网站的可访问性包括所有影响网站访问的条件，包括 视觉、听觉、物理、语言、认知和神经功能障碍。

简单地说，某个网站具有可访问性时，指的就是是 网站的内容可用，并且毫不夸张地讲，其功能可由任何人操作。

大部分开发者都有类似这样的一个潜意识，轻易地认为所有用户都能看见和使用键盘、鼠标或触摸屏，并且与网页内容的交互方式与自己相同。这会造成一些人能够获得良好的体验，其他人则会遇到从简单烦恼到重大障碍的各种问题。

那么，可访问性（无障碍功能）就是指这样一类用户的体验，他们可能不在“典型”用户这一狭窄范围之内，并且与网站的访问或交互方式异于常规。具体地讲，它所涉及的用户具有某种身体缺陷或残障（切记这种体验可能具有非生理性或暂时性）。

传统上会认为这是关于残疾人的，甚至是仅狭隘的定义在盲人人士这单一群体，但实际上它也涵盖了其他群体，比如使用移动设备的人群，或者那些网络连接缓慢的人群等。

尽管我们在探讨无障碍功能时往往是围绕身体有缺陷的用户，但实际上都能将其与我们使用的界面由于其他原因而无法访问的经历联系起来。您是否曾在手机上使用桌面版本网站时遇到问题？是否看到过“您所在地区不提供该内容”消息？或者是否在平板电脑上找不到熟悉的菜单？这些都属于无障碍功能问题。

随着了解的深入，您会发现在这种更广泛、更普遍意义上解决无障碍功能问题几乎总能让所有人的用户体验得到改善。

为什么要做可访问性

正如万维网的发明者和W3C组织的主席@Tim Berners-Lee所说：

Web的力量在于它的普遍性。每个人不论残疾与否都能访问是一个最基本的方面。

从文章开头提供的数据来看，整个世界有残障的人士数量并不少，加部分无残障的人士在特定的场景访问Web也有可能存在一定的障碍。如果我们的Web页面或应用程序在可访问性方面做的不够好（甚至是没有做），结果将是：

  • 可能会流失部分群体
  • 可能会造成一定的经济损失

甚至还有可能面临一定的法律风险。比如达美乐披萨这个法律案件就是一个公司因为没有给自己的Web提供可访问性而被起诉。在很多国家有对Web网页或应用程序的可访问性有明确的法律条款。可访问性法规因国家不同，也有相应的差异，比如：

事实上许多国家有关于Web可访问性都有相应的政策和法律，说不定不久之后我国也会有相关的法律。

看到这些法律法规，可能很多人或组织会感到不知所措。任何个人或小公司都不可能跟上所有规定，但这也不是致命的问题，因为有一些标准机构、指导方针和专家可以帮助我们解决这个问题。

大多数的规则都是从WCAG 1.0、WCAG 2.0和WCAG 2.1标准中提取的，作为构建可访问网站的指导方针。这几个标准都是由Web内容可访问性指南工作组（Web Content Accessibility Guidelines Working Group）构建和维护的，该工作组由Web开发人员和来自各种公司和组织的专家组成。

WCAG工作组是W3C（万维网联盟）下的众多工作组之一。W3C是负责HTML（HTML5）、CSS和Web所依赖的许多其他技术的国际标准社区。

在一些国家除了有明文法律规定要求对Web做可访问性的硬性要求之外，其实给Web添加可访问性还有其他的作用或者说意义：

  • 伦理意义：任何人生理带给生活带来的缺陷对于生活都是相对不便的。但是在互联网的世界中，我们应该把缺陷带来的不便降到最低，即将服务平等的提供给你的用户是最基本的尊重
  • 用户体验：有着良好可访问性的产品往往也有良好的设计和工徎化。对于有工匠精神追求的工程师而言，给自己的产品（Web页面或应用程序）做好可访问性是自己职责内的一部分，而不仅仅是情怀所致
  • 口碑和品牌形象：具有较好的可访问性将给自己的用户群体有一个较好的体验，这样比你的对手要好。无疑是一个颇有竞争力的优势。能大大提升品牌口碑，同时也能提高自己的品牌形象
  • SEO：其实SEO和可访问性优化是有重叠的。比如具有语义化的HTML结构对SEO和可访问性都有帮助，因此在构建自己的产品时应该正确的使用正确合理的标签及标签属性

简单地说：

良好的 Web 可访问性，就是把你的网站建设成让尽可能多的人都觉得好用，可以让每一个人受益。

为什么总是无人在意Web的可访问性

既然Web可访问性有这么的优势，那么为什么实际中为什么总是无人在意Web的可访问性呢？在聊这个话题的时候，先告诉在大家一个故事。据说在Web社区中有一个传说：

在自己的Web页面或应用（或产品）中添加可访问性相关的功能需要附出额外的代价，而这个代价是高昂的、困难的，又是没必要的。

换句话说，从零开始设计符合可访问性的应用（或产品）不会添加额外的功能或内容，也就不会有额外的成本。不过这个传说也不假，如果你面对下面这样的场景：

  • 在一个已存在的有众多可访问性的应用上试图解决，让其具有可访问性
  • 在项目的最后一步才开始考虑可访问相关的问题以及处理方案

基于这两点，处理Web可访问性是较难的，成本也是极高的。

另外还有就是意识和认知问题上。在很多团队中，大家时不时会聊Web可访问性的重要性，但事实上仅停留在空谈上（没人愿意把时花在这上面）。那么为什么会这样呢？从我切身的角度来想，应该有以下这几点：

  • 从业务角度而言，Web应用是否具有可访问性，对我没有实际的利益（我看不到具有可访问性的应用能带来多少价值），所以与其花时间处理不具效益的功能，还不如多花点时间做一些能带来实际效率的功能
  • 从开发者角度而言，我也想做好Web应用的可访问性，但业务需求都这么紧张，哪有时间再处理这些额外的需求，不是主要的需求；对于有情怀的开发者而言，我有足够的时间，我想做的时候再来考虑Web可访问性相关的事项吧
  • 不管是产品还是开发者，无法切身体会到残障人士的生理不便感同身受，也就是说要处理无法体会的情况，的确很难。换句话说，缺少的不是动力和技术，而是常识或者意识
  • 给Web应用添加可访问性的工作是一个细活，费时不说，不一定见效。对于开发者而言，需要了解很多有关于Web可访问性相关的知识，特别是标准，然后在此基础上参照开发。而且开发完之后不一定是合适的，需要人测试，而这些测试的工作量也不少

简单地说：

很多时候是屁股决定脑袋。在商业项目中不太可能为了少数用户而延迟交付，关注大部分用户的需求才是核心，所以Web可访问性往往会被推到下一个，再下一个。有时间，有人再说。

另外，很多时候，开发者自身都会存有同样的困惑。可访问性和我自己有什么关系？甚至很多开发者不一定具备这方面的知识点，如果你要让其给Web应用添加可访问性，他有可能不知道从何处入手。也正是因为这个原因，很多人都会觉得创建可访问性网站是很困难的。

要改变这种现状，需要从一个产品的开发的源头就要有这样的意识。也就是说，不管是产品还是开发者或者是测试都不能再抱着“与我何干”的心态，更多的时候应该把自己纳入到这些特殊群体中来，哪怕是把自己纳入暂时性的特殊群体也是好的开始。

这么说的原因是，所谓的这些特殊群体在时间上是可以分为：暂时性、永久性和情景性。针对这几个场景，我们可以这样来理解。

暂时性

比如说，你突然有一天因为某些事情，无法正常的用手来操作鼠标（或者忘记带鼠标）或者无法双手操作某些设备终端。面对这样的场景，咱们就可以被纳入到暂时性的群体中来。如果我们要继续操作一个应用，就需要借助别的方式来完成，比如在PC端，需要依赖键盘来完成对Web应用的操作，可能会用到键盘的一些操作键盘，比如tab键（最常用键之一）、Enter键，方向键盘等：

在移动端上虽然没有键盘，但移动设备都会提供一些辅助功能的选项，比如iPhone就提供了“辅助触控”来实现无障碍：

永久性

在这些特殊群体中，可能很多人是永久性的，比如说盲人、视弱或者色盲。这样的情景之下就需要调整颜色。比如iPhone在辅助功能选项中就提供了显示调节、色彩滤镜和对比度增强等功能来帮助这些用户群体。

情景性

情景性是生活中经常可接触的场景。比如你使用手机的时候，很多时候无法使用语音（比如你在参加一个重要的会议，不方便开启语音）。在这种场景之下，有朋友给你发了一条语音，你可能会选择将语音转换成文字。

Web可访问性分类

Web可访问性（无障碍）的分类一般都是根据生理障碍来划分，即分为听觉、视觉、行动和认识四个类型。不同类型都会包含多种情况，它们或多或少都会影响用户使用Web应用。这样一来，网站开发者需要为这些用户群体做好可访问性方面的优化。这里简单地根据对应的类型做一个简单的介绍。

听觉障碍

听觉障碍指的是听力有障碍的用户群体。对于这些的用户群体，对于音频和视频来说是有一定的障碍（有可能听不太清楚，甚至一点都听不清楚）。如果你的Web应用正好是做音频或视频方面的（比如现在喜欢提供短视频描述产品详细、比如喜欢营销页面配乐等）那就需要为这样的用户群体做一些可访问性相关的处理。比如不仅依靠声音来传递信息，提供音频的同时还需要提供别的媒介。比如针对视频提供完整的字幕，比音频提供文本描述。除此之外，还需要注意音视频中的噪音影响，保证受众群体可以准确地接收到信息。

视觉障碍

视觉障碍指的是视力有障碍的用户群体，比如视弱，色弱，色盲，盲人甚至一些老年人（老年人视力有减弱的情况）。对于这些用户群体在访问Web页面时会有一定的障碍。

对于视弱的用户群体在访问Web应用可能会因UI视觉上的因素看不太清楚，针对这些用户群体应该提供一个可读的界面。比如UI元素要足够清楚，字号尽可能的大等。对于色弱和色盲的用户群体，对于颜色的区分较弱，针对这些用户群体应该提供一个颜色对比度更合理的界面。对于盲人群体，应该提供更合理的HTML结构，然后用自然语言向用户描述解析结构，便于读屏软件阅读。另外，一些盲人用户群体除了依赖读屏软件之外，可能会强度依赖于键盘的操作，因此应该给Web应用提供较好的焦点操作，便于用户通过键盘访问Web应用。

运动障碍

运动障碍是指肢体操作有障碍的群体。在某些应用中需要快速或者重复执行某个动作，比如长按一个按钮或者在规定时间内完成某项操作，这些对于有运动障碍的群体来说都是比较困难，如果要求他们强行做到这些动作，可能会造成生理不适。针对于这样的场景和用户群体，我们应该尽可能在Web应用上避免采用这些动作，不过这不是件容易的事情。比如在滑动滑块的时候，你可能需要按住一个按钮来保证它持续滑动。想到了运动障碍的用户，或许会改变方案，换成每轻触一次按键滑块滑动一点距离。虽然这样做有所改变，但也可能带来新的麻烦，变成重复动作，这样也会为有运动障碍的群体带来操作负担。所以在这方面，我们应该更多的是保证Web应用无论使用鼠标操作还是键盘都是一个较好的操作。

认知障碍

认知障碍一般指的是有晕动症（指与晕动症和感官超载相关，比如癫痫病患者）、有学习障碍和阅读困难等用户群体。面对这些群体，我们应该尽量让页面上不能有动效，因为动效会诱导类似患有癫痫病患者发病（这可能是件极其危险的事）。对于学习有障碍的群体，我们应该要尽量的简化Web应用的场景、界面，尽量用简单的方式来描述。对于阅读有困难的用户群体（阅读困难是一种生理缺陷，这类患者难以阅读，因为看到文字就会觉得文字在旋转扭曲或者全部挤在一起），我们应该操持良好的可读性，至少保证一部分生理不便的用户可以操作你的Web应用，比如使用可读的字幕和文本。

针对这些不同的用户群体，在可访问性设计或者开者过程中都有一些针对性的技巧和需要注意的细节，在稍后的我们会详细阐述这方面。

Web可访问性指南

Web可访问性指南又称Web内容无障碍功能指南（Web Content Accessibility Guidelines）常常简写成 WCAG，目前最新版本是V2.1。这是一套由无障碍功能专家编辑的指南和最佳做法，旨在有系统地阐述“无障碍功能”的含义。实际上，有若干国家在其网络无障碍功能法律要求中明令，必须使用这些指南。

Web内容无障功能指南中文版本

使用WCAG的个人和组织差异很大，包括网页设计师和开发人员、决策者、采购代理人、教师和学生。为了满足这些受众的不同需求，提供了多层指导，包括总体原则、一般准则、可测试的成功标准以及丰富的充分技术、咨询技术，和记录的常见故障包括示例，资源链接和代码。

  • 原则：最重要的是为Web可访问性提供基础的四个原则：可感知、可操作、可理解和健壮性
  • 准则：原则的下层是准则。13条准则提供了作者应该努力的基本目标，以便让不同有障碍用户更容易访问内容。准则不可测试，但提供框架和总体目标，以帮助作者理解成功标准并更好地实施技术
  • 成功标准：对于每个准则，提供了可测试的成功标准，以允许在要求和一致性测试的地方使用WCAG 2.1，例如设计规范，采购，法规和合同协议。为了满足不同群体和不同情况的需要，定义了三个一致性级别：A（最低），AA和AAA（最高）
  • 充分的咨询性的技术：对于WCAG 2.1文档本身的每个准则和成功标准，工作组还记录了各种各样的技术。这些技术具有信息性，分为两类：足以满足成功标准的技术和提供咨询意见的技术。咨询技术超出了个人成功标准的要求，并允许作者更好地解决准则。一些咨询技术解决了可测试成功标准未涵盖的可访问性障碍。在已知常见故障的地方，也会记录这些故障。

所有这些指导层（原则，准则，成功标准以及充分的咨询技术）协同工作，为如何使内容更易于访问提供指导。

简单地说，WCAG 围绕四大原则进行组织，通常使用首字母缩写词 POUR 来称呼这些原则：

  • 可感知：用户是否能感知内容？这有助于我们紧记这一点：仅凭可通过一种感官（例如视觉）感知内容并不能断定所有用户都能感知
  • 可操作：用户是否能使用 UI 组件和在内容中导航？例如，需要悬停交互的内容无法由不能使用鼠标或触摸屏的用户操作
  • 可理解：用户是否能理解内容？用户能否理解界面，以及其一致性是否足以避免产生混淆？
  • 健壮性：内容是否能被多种 User Agent（浏览器）使用？ 它是否能与辅助技术协作？

原则是我们实施的策略和方法，准则是我们的目标，成功标准是我们测试的标准。

有阅读过规范的同学，不管是什么样的规范，都是一件较为痛苦的事情。尽管 WCAG 提供了无障碍内容含义的全面概览，可能还会让人觉得有点不知所措。

不过值得庆幸的是，WebAIM小组将 WCAG 指南提炼成了一份易于遵循的检查清单，专以网络内容为目标。WebAIM提供的检查清单简要介绍了您需要实现的内容，同时还在您需要扩展定义时提供了底层 WCAG 规范的链接。

有这个工具在手，您就可以为自己的无障碍功能工作制定方向，并坚信只要项目达到规定标准，用户就能在访问您的内容时获得良好的体验。当然，在社区中除了WebAIM提供的这些检查清单之类的，还有其他的资源帮助大家更好地理解和实践无障碍功能，有关于这部分，后续我们还会花更多的篇幅来阐述。

为什么会觉得创建可访问网站很难

前面我们花了很长的篇幅和大家一起聊聊了什么是Web可访问性、为什么要做可访问性、Web可访问性分类和Web可访问性操作指南等相关的话题。从这些话题中我们可以得知，要做一个具有可访问性的Web网站或应用会涉及到很多知识点，比如设计方面的知识（UI怎么设计、颜色怎么选择等）、开发方面的知（HTML结构、焦点控制、样式渲染）和测试（怎么测试，有什么测试工具）。虽然说这些都是一些客观存在的因素，对于这些客观因素，我们总是有办法（或者找到相应的方案）来解决，比如一些标准和在线工具可以帮助我们：

这仅仅是其中的一些，社区中估计还有很多我未发现的优秀资源。

正因为标准过多，而且阅读标准又是件极为痛苦的事情，所以不少设计师和开发者都不愿意花费时间，如此一来形成一个恶性循环：

不学习，就无法获取相关知识；没有相关知识，就无法改变现状。甚至无法着手怎么设计一个具有可访问性的应用和怎么着手开发一个具有可访问性的应用。

客观因素我们可以克服，更主要的是一些主观因素，比如：

  • 过于追求现实利益，自认为可访问性无法带来实际利益
  • 刻意忽略有障碍的人士（直接把这些用户群何排除）是自己的用户群体
  • 不愿学习，不愿主动改变

另外有些产品、设计师和开发者愿意去尝试着改变，但觉得在整个开发链路上没有较好的方式让我们设计一个具有可访问性的应用成本变得更低，效率更高。正如@Robin Rendle和@stefanjudis在各自文章中提到的，希望在编辑器或者浏览器上有一些工具能在我们开发时就得到较好的提示。也正因为这些原因，很多人都会觉得开发一个具有可访问性的应用太难了，但事实上呢？我们还是有办法可以克服，让我们创建一个具有可访问性应用变得没有那么难。

在开始之前，先来看一个在线的网站，比如淘宝首页：

从上图上我们可以看出，有近159个问题，比如ARIA的使用、颜色对比度、标签属性的缺失、HTML标签乱用、元素焦点等。这些问题有设计方面的，有开发方面的。你可能会好奇这样的报告是怎么出来的以及怎么来修复这些存在的问题。

那么在接下来将花一些篇幅和大家从设计、开发、测试和一些需要注意的细节上做一些探讨，从而提高大家在这方面的能力，能快速设计和开发出一个具有可访问性的Web网站或Web应用。

如何设计一个可访问性网站

先从设计的角度来考虑怎么设计一个可访问性网站。

首先要说的是可访问设计（无障碍设计）并不会强迫设计师把UI变得更丑，相反是让设计师尽可能的考虑一些用户群体在和应用交互时可能存在的问题。比如根据无障碍设计规范尽量为所有人（比如，盲人、视弱、色盲；听觉失聪或有听力障碍；有认知障碍的患者；为年长、年幼的人和行动有障碍的人）设计。

再次强调，可访问性用户群何不仅仅指的是盲人，指的是有障碍访问应用的用户群体。

做可访问性设计时，主要从以下几个方面来做考虑。

视觉可访问性设计

视觉可访问性设计主要是针对于有视觉障碍用户群体做的。

视觉障碍用户群体包括：视弱、色弱、色盲、盲人和视力存有障碍等。

针对群用户群体，设计师在设计UI的时候主要应该从以下几个方面考虑：

  • 确保UI的颜色有足够的对比度
  • 别仅依赖用颜色传达信息
  • 文字字号
添加足够的颜色对比度

颜色对比度是一个经常被忽视的问题（可访问性 ），从众多网站或应用程序的“无障碍”检测结果就可以发现“颜色对比度达不到WCAG标准”：

视弱的人可能会发现，如果背景颜色和前景颜色对比度低，难于阅读。而且从世界卫生组织在一份关于视力障碍和失明统计报告中可以得知有近2.7亿人患有中度至重度视力障碍。因此在设计一个Web应用时，需要考虑文本和背景之间颜色要有充分的对比度。

根据WCAG视觉对比（WCAG Visual Contrast）规范，我们可以得知，文本与背景之间的颜色对比度应该至少是 4.5:1(可达到级别 AA)。如果文本更宽，更大和更重，那么对于视力有一定障碍的用户更便于阅读，那么颜色上的对比度就可以稍微更低一点。比如，文本字号是18pt或14px粗体时，最低对比度可以下降到 3:1。

在设计的时候可以按照下面表格相关的标准来设计（根据规范整理）：

Text Normal Bold Ratio AA Ratio AAA
Small <24px <19px 4.5:1 7:1
Large >24px >19px 3:1 4.5:1

WCAG视觉对比（WCAG Visual Contrast）规范可以帮助视力障碍用户更好地使用互联网产品。

如果你实在拿不准配色是否合理（Web安全颜色），你可以借助在线工具，比如Contrast Checker:

该工具是根据WCAG 2.0 guidelines for contrast accessibility标准来做的。比如下面图所展示的效果就是一个较好的效果：

如果你想获得更详细的分数，我建议你使用WebAIM颜色对比度检查器，此工具将计算不同对比度的级别（A、AA、AAA）中常规文本大小和较大文本大小的分数，同时可以更改颜色值实时查看结果。

Chrome浏览器有一款插件"High Contrast"，它能够提高页面调色方案的对比度，通过此类工具来查看页面能够在配色的选择上助我们一臂之力。

令人感到惊讶的是，早在1992年就有人开始使用下图这样的公式来计算颜色的对比度：

有关于该公式更详细的计算可以阅读《Signs and color contrast》一文。

别仅依赖颜色作为关键信息传递

当你的应用需要和用户做一些重要交流的时候（比如有单的填写），不要仅把颜色作为视觉提示。这是因为低视力，特别是色盲的用户很难理解。比如下图所示：

上图左侧是正常用户看到的效果，右侧是有色盲的用户看到的效果。

当然完全色盲的用户群体也相当少见，患有这种缺陷的人眼里只有不同深浅的灰色。颜色感知的变化影响的整个视觉光谱，而不仅仅是一种颜色。

你的初衷可能是选择一种大部分有色彩障碍的人都能识别到的颜色，但由于有各种色弱，且每种色弱的情况有轻有重，要选出这样一种颜色相当困难。不过橘色和蓝色还算能满足大部分情况。这就是为什么互联网产品里蓝色如此常见。

对于这些用户群体，唯一的原则是：别仅用颜色区分。比如上面的表单控件，可以在设计表单时，表单验证环节除了增加颜色之外区分之外，还可以添加一些区分对错的图标，甚至还可以添加一些提示信息。如下图所示：

Facebook的注册表单在可访问性方面要比Twitter的注册表单更友好，特别是对于色盲的用户群体！

听觉可访问性设计

听觉可访问性性设计主要是针对于听力有障碍的用户群体。

听觉有障碍用户群体主要是指听力有障碍（听不清楚或听不到界面发生的声音）的用户群体。

如果你的产品或者Web应用是主打视频或音频方面的，那么就需要特别为听觉有障碍的用户做相应的考虑。在设计方面可能需要考虑的是：

  • 使用文本替代音视频（用文字描述，容易被理解）
  • 确保界面上的所有空间，在没有声音时仍能正常使用

对于听觉有障碍的用户群体，更多要注意的是在开发时要多为这方面的用户群体做考虑。

运动可访问性设计

运动可访问性设计主要针对于有“运动障碍”用户群体做的。

运动障碍是指肢体操作有障碍的群体，可能包括不能操作鼠标、键盘或触屏等。

针对运动障碍用户群体在做设计的时候需要考虑：

  • 确保所有界面控件交互都可通过键盘或者只使用鼠标完成
  • 确保界面控件辅助技术正确标记（不要让用户犹豫不决地找东西）
设计可用的焦点状态

你是否注意到有时在可聚焦元素（比如链接<a>、按钮<button>或表单控件元素<input>）在被选中（得到焦点，有可能是tab键或鼠标点击让其得到焦点）时周围会出现蓝色的轮廓。这种效果也常称焦点指示器。在Web页面或Web应用中，默认情况下，浏览器使用CSS的伪类（比如:focus，:active等）让元素被选中时显示这些轮廓。从设计师的角度来看，可能会觉得这些默认的焦点指示器效果不漂亮（和自己的主题不搭），往往会试图隐藏它们（不希望有焦点指示器效果）。但是，如果你不希望有这样的默认效果就一定要使用其他的样式替换它。

下面的效果来自BBC。它使用颜色条来提示哪个链接处于焦点状态。

Twitter使用默认焦点和提示的组合方式来显示焦点，图标也从灰色变成绿色。这是三个独立的视觉效果，可以很好地为键盘用户提供焦点提示。

焦点指示器帮助用户知道哪个元素具有键盘焦点，并帮助用户在浏览网站时了解自己位置。这些导航系统的使用者包括盲人和需要屏幕阅读器的人、行动不便的人、或者忘记带鼠标的人以及那些极度依赖于键盘操作的用户。

咱们可以设计符合网站风格和品牌的焦点指标。创建一个高度可见的状态，具有良好的对比度，因此它从其余的内容中脱颖而出。

不要让用户犹豫不决地找东西

这主要是为有运动障碍的人提供服务。这包括具有视觉功能但只能使用键盘的用户，以及使用Dragon Naturally Speaking等语音识别工具与网页进行交互的用户（一般是视障用户）。键盘用户和Dragon等辅助技术依赖于屏幕上显示的可操作项目。如果Dragon无法识别链接或按钮，那它就无法说出“点击”。如果只能使用键盘的用户无法看到页面上的按钮，那么他们也无法明白空白区域最后是会出现内容的。

以下是来自Gmail的Dragon Naturally Speaking屏幕截图。Dragon使用后，会在网页上叠加一层内容：在每个超链接上面出现数字标识。 用户可以大声说出一个数字，这样就能激活一个链接。 如果是那种需要鼠标悬停在上面才会出现的链接呢？应该告诉Dragon怎么办呢？ 应该做到在有链接的空白区域旁边显示数字。

认知可访问性设计

认知障碍意味着用户可能需要辅助技术来帮助他们阅读文本，因此文本替代方案的存在非常必要。在设计的时候应该更多的考虑：

  • 避免重复或闪烁的显示方式，因为这可能会为认知障碍用户造成使用不便
  • 给用户留出充足的时间操作

有关于这方面更多的内容可以参阅：

如何开发一个可访问性网站

作为开发人员开发开发一个可访问性网站需要具备很多知识。首先可以先从各种规范开始。

标准和指南

有关于创建可访问性网站相关的标准和指南较多。

WCAG

WCAG是Web Content Accessibility Guidelines的首字母缩写，俗称网络内容无障碍指南。主要是为构建无障碍（可访问性）网站提供指南。其中常见的清单有：

WAI-ARIA

WAI-ARIA是Web Accessibility Initiative - Accessible Rich Internet Applications首字母缩写。它是W3C的Web无障碍推进组织(Web Accessibility Initiative / WAI)在2014年3月20日发布的可访问富互联网应用实现指南。

WAI-ARIA是一个为访问Web页面有障碍人士等提供无障碍访问动态、可交互Web内容的技术规范。在WAI-ARIA概述中对WAI-ARIA及其他支持文档进行了介绍。

简单点描述：

  • ARIA是W3C的一个独立规范，帮助Web应用程序和Web页面变得更具可访问性
  • ARIA主要是为了提升网页的可用性，网页对残疾人士的无障碍化
  • HTML5已经开始使用ARIA，并且W3C发布的很多其他标准也开始使用ARIA
  • ARIA 是对 HTML 语义化的补充。它具备比现有的 HTML 元素和属性更完善的表达能力，并让你页面中元素的关系和含义更明确
  • ARIA 规范为浏览器和解析 HTML 文档的辅助性技术提供了一种可以让人们以多种方式访问和使用 Web 的标准方法

有关于WAI-ARIA相关文档和指南主要有：

根据Accessible Rich Internet Applications (WAI-ARIA) 1.1可以划分出不功能模块，起到不同的作用：

其中ARIA Roles和ARIA States and Properties可以帮助我们构建可访问性强，功能复杂的组件。

每个部件都有各自特定的设计模式，并且用户和用户代理都期望能以相似的方式运行它们。

我们在构建基础组件的时候，如果要考虑到可访问性方面的事项，就可以参考Design Patterns and Widgets中提供的设计模式和组件模块：

ARIA是构建可访问性网站或应用的重要知识点，在这里不做详细阐述。如果想要构建好一个具高可访问性网站，这部分知识必须得掌握！

有关于ARIA更多的资料：

HTML5和CSS标准

另一部分标准就是HTML和CSS相关的标准：

其他

在指南的其余部分，我们将深入介绍创建无障碍网站的实用层面。 我们的介绍将围绕以下三大主题领域进行组织：

HTML语义化

前几天在Twitter上看到@Estelle Weyl上发了一条推：

让我深有体感。特别是当Web布局越来越强大之后以及优秀的JavaScript框架出来之后，很多开发者都不在关注HTML语义化的东东，往往在一个页面只能看到div标签。在今年的React Conf大会上@BrittanyIRL分享的Accessibility Is A marathon, Not A Sprint话题中展示了HTML语义化在可访问性上的作用。

事实上，在HTML5中新增了不少具有语义化的标签元素：

如果你在写HTML或者组件模板不知道应该选择哪个HTML标签元素的时候，可以参照下图来选择：

即使你在HTML或者组件模板中尽量的根据了上图使用具有语义化的HTML标签，我们还应该结合ARIA的Landmarks结合起来使用。ARIA不是HTML的一个版本，它通过添加新的属性扩展了HTML的功能。ARIA的主要目的是允许JavaScript将角色（roles）、状态（states）和辅助技术进行通信。

HTML5一些语义化标签和ARIA的Landmarks有些可以对标起来：

HTML5 ARIA Landmarks Roles
<header> role="banner"
<nav> role="navigation"
<main> role="main"
<footer> role="contentinfo"
<aside> role="complementary"
<section> role="region"
<article> role="article"
<form> role="form"
none role="search"

有关于HTML语义化标签的使用以及给可访问性带来的优势相关的介绍还可以查阅下面这些教程：

为什么强烈要求尽可能在使用具有语义化的标签呢？除了代码的可维护性，可阅读性，甚至说利于SEO优化等，在可访问性方面也有独特之处。因为原生元素包含内置可访问性无数据。正如渲染引擎使用原生代码来构建的UI界面，屏幕阅读器则会使用DOM节点中的元素数据来构建一个无障碍版本，其结构与下图所示类似：

如果对上图不太好理解的话，可以换过一种理解方式。HTML中的每个元素在源中都有先后顺序，依赖源码编写顺序时出现的时间，可以构建一颗树，即DOM树：

在Web可访问性的设计中同样有类似于DOM树的特性，该特性基本上就是浏览器实际呈现给屏幕阅读器的内容。浏览器获取DOM树，并将其修改成适用于辅助技术的形式。我们将这个修改后的树称为无障碍树。类似下图这样：

在Chrome浏览器中的“Accessibility”选项中也可以查看到DOM元素所对应的可访问树（Accessibility Tree）:

有关于无障碍树更多介绍可以阅读：

焦点管理和焦点美化

前面我们提到过，有运动障碍的人，依赖屏幕阅读器的盲人以及一些强度依赖于键盘操作的用户群体，他们访问Web页面或Web应用主要依赖于键盘来进行操作。

使用键盘操作，主要会依赖于键盘上的tab键，除此之外还可以会依赖键盘上的方向键、确认键盘、甚至是一些设置好的快捷键。而其中最为主要的是tab键，通过操作键盘的tab键可以获得焦点，提示用户现在在应用中的哪个位置。

在Web页面或应用程序中，可获得焦点的元素有很多，而且在一个Web页面或应用程序中，在任何给定的时间都有一个元素具有焦点。当前聚焦项通过使用聚焦环（outline样式）标示出来，对于该样取决于浏览器，也取决一些CSSer给可聚焦元素定义的样式：

既然有可聚焦元素就有不可聚焦元素，比如div和span等元素。但往往我们在实际开发中，又需要让这些不可聚焦的元素可以得到焦点。比如模态框组件，模态框在弹出的时候希望能得到一个焦点，但很多时候是使用div来做这个模态框。可div是一个不可聚焦元素，这个时候我们就需要使用HTML的tabindex属性。

tabindex属性是一个全局属性，既可以用于可聚焦元素上也可以用于不可聚焦元素上。其取值不同时效果也不一样：

  • tabindex="-1"：设置了tabindex为-1的元素，该元素不会被置于页面的tab键序列中，但可以通过JavaScript的focus()获取，允许脚本设置元素的焦点。当你需要将焦点转移到通过脚本或用户操作之外更新的内容时，该设置非常方便
  • tabindex="0"：可以让非常聚焦元素按自然顺序出现在tab键序列中
  • tabindex="1"：不要设置tabindex="1"或任何大于0的值

虽然规范是上是这样定义的，但是到真正的客户端的表现还是有所差异的。从测试的结果来看：

  • 显式设置tabindex="0"的元素（不管是可聚焦元素还是非聚焦元素）都可能得到焦点
  • 显式设置了tabindex="-1"的元素都无法得到焦点
  • 除了Safari浏览器，只要是可聚焦的元素都可以正常得到焦点
  • 非可聚焦元素，显式设置了tabindex值，但只未赋予任何值的情况之下都无法正常获得焦点

虽然tabindex能让我们很好的得到焦点，可以用来管理焦点（可以给非聚焦元素设置聚焦行为），可以让运动障碍的用户群体友好的操作Web页面；但世间万物总是两极的，用的好就有益处，用的不好反而会有坏处。所以在实际使用的时候，要慎用。

有关于tabindex更详细的介绍可以阅读《使用tabindex的正确姿势》一文。

可访问的样式

CSS样式是构建Web页面或Web应用程序的三大基石之一。那么样多处理的好坏对于可访问性也会有直接的影响，特别是对于视觉障碍用户群体更是有益。接下来主要围绕三个方面和大家简单的聊聊：

  • 为焦点和各种ARIA状态添加样式，确保对元素进行样式化以支持我们的可访问性工作
  • 赋予UI灵活的样式，以便对它们进行放大来满足无法看清小号文字的用户的需求
  • 选择合适的颜色和对比度，避免仅通过颜色传达关键信息

有关于这几个方面更详细的介绍可以阅读《可访问的样式》一文。

七步助你检测和修复可访问性

假设你根据前面介绍的内容构建了一个”可能”具有可访问性的网站或应用，然后又想看看自己构建出来的应用是不是真的具备可访问性或者说可访问性还存在什么缺陷。其实我们可以通过一些工具按照下面这几个步骤助你检测和修复可访问性应用。

Step01: 自动测试

要做的第一件事情就是借助一些工具来做测试。时至今日，目前社区中可以测试Web应用可访问性的工具或者浏览器的插件很多，比如：

可以根据测试出来的结果对号入座对行修复和改良，而且每个都有相应的提示信息和修改建议：

Step02：检测img的描述（alt）

在最初编写HTML的时候，用到的属性就需要注意有些元素标签的属性是必须得写的，比如<img>标签，该元素的alt属性就得显式设置，该属性主要用来描述图片的。在可访问性检测过程中，是必检的。如果未显式设置alt属性，在检测过程就会有相应的警告信息。

早期还没有这些工具之时，常常采用 Web Developer工具来进行体测：

Step03：禁用所有样式

Web Developer工具可以用来模拟没有样式的页面效果。禁用CSS，可以帮我们检测出：

  • 如果样式丢失，网站能不能正常浏览？
  • 页面元素的顺序有意义吗？
  • 图像和图标的大小是否正常？
  • 文档结构写得好不好？

Step04：验证HTML和CSS

使用W3C Markup Validation Service和CSS Validation Service来验证HTML和CSS的已经为数不多了，甚至是找不到了吧。

同样也可以使用Web Developer工具来验证：

现在检测CSS出来的结果有点令人头痛：

Step05: 检查文档大纲

完善文档的大纲很重要。它应该以h1开始，然后按层次顺序依次是h2、h3等。这对于搜索引擎和屏幕阅读器用户来说是非常好的，因为他们可能通过从一个标题跳到另一个标题来导航你的站点。

可以使用W3C Markup Validation Service来检查你的大纲或者使用tota11y工具来检测：

Step06: 颜色对比度检测

Web网站或应用存在问题最多的就是颜色对比度（前景色和背景色的对比），因此有关于颜色对比度的检测是很重要的。它会告诉你，你的设计工作不仅仅是处理颜色，更重要的是要确保你传达的信息不会因为颜色给用户造成不便。

High Contrast 是谷歌 Chrome 浏览器的一个扩展插件，它能够提高页面调色方案的对比度，通过此类工具来查看页面能够在配色的选择上助我们一臂之力。

如果不依赖插件的话，可以通过CSS的filter达到类似的效果：

body {
    filter: grayscale(100%);
}

Step07：使用键盘

尝试着把鼠标放一边，通过按键盘的tab键来浏览你的页面，看看你是否可以不用鼠标（或触模板）就能使用网站的每个部分。tab键是一个强大的测试工具，它会告诉你很多关于网站的信息：

  • 焦点样式是否清晰可见？
  • 所有的东西都能聚焦吗？
  • 你的按钮是真的吗？（是<button>？）
  • 整个UX使用键盘很棒吗？
  • 你是否能正确的管理焦点？
  • 隐藏和显式元素是否正确？
  • 视觉顺序是否与DOM顺序匹配？
  • 在没有鼠标的时候，可以使用自定义组件吗？

通过些步骤和工具可以很好的帮助你检测一个Web网站或应用程序的可访问性是否存在问题。这些步骤只是其中检测的一部分，事实上要做好的话还有很多东西需要检测，比如ARIA的使用是否合理、文字是否可以放大等等。

如果你根据上面的工具检测（特别是第一步提到的工具）出来的结果以及相应的提示信息去修正的话，那么你创建出来的Web或应用在可访问性方面不会太差。不能达到100分，至少也能及格。感兴趣的同学，不仿在你的下一个项目中按照这个过程走一走。

如果你坚持阅读到这里的话，是不是会对构建具有可访问性网站更有信息？是不是会觉得构建一个可访问性网站并没有想象中的那么难？

15个阻碍残障用户使用移动应用程序的可访问性问题

现在是移动端的世界了，甚至你的产品不仅仅是PC、移动端，甚至还会是TV之类的。不管是在什么端上呈现，只要是Web或Web应用，在处理可访问性方面总是会相似的。为了让大家能更好的处理移动端方面的可访问性方面的问题。我在@Sanjay Nasta提到13个点基础上增加了两点。在实际生产中，影响可访问性的肯定不会少于这15条，如果你有相关的经验或踩过相关的坑，欢迎在下面的评论中与我们共享。

禁用双指缩放

双指缩放是一个非常有用的辅助工具，它允许有视力障碍的人通过简单的多点触控手势放大一段内容。但在移动端的开发中，开发者都习惯性使用<meta>标签来禁用双指缩放：

<meta name="viewport" content="width=device-width,initial-scale=1,maximum-scale=1,minimum-scale=1,user-scalable=no,viewport-fit=cover">

这样的设置对于有障碍的用户群体而言是致命的。

两指缩放的能力不仅仅是一个WCAG指导方针，而是日常生活中一个简化的工具。所以下次你在建立一个响应式网站（或进行移动端开发）的时候，要考虑到视障人群，比如我们的妈妈。除了让用户可以自由地在移动设备上缩放之外，还要记得检查PC端浏览器上高达200%的放大特性。

未读出的表单验证错误消息

屏幕阅读器无法访问验证的错误信息是移动网站和原生应用中常见的问题。对于看得见的用户，当他给表单提交无效数据时，就会出现绝错误消息：

前面也有提到过，为了照顾视障群体（色弱，色盲等）除了使用颜色区分之外，最好还能配上一些图标或提示信息。

对于屏幕阅读器用户，开发人员需要测试错误消息和其他修复建议是否被大声读出，以便用户能听到他们哪里填错了。

在开发表单的时候，不管是在PC端还是移动端，建议尽可能的采用原生标签以及表单验证的相关属性。这方面HTML5和CSS都做得非常的好。比如采用正确的表单类型type（或inputmode），合适的属性attributes(比如maxlength、minlength、size、readonly、required、multiple、pattern和placholder等)。在美化表单的时候也能尽可能的配合相关的伪元素（比如:placeholder-shown、:required、:optional、:disabled、:read-only、:valid和:invalid等）。

在构建可访问性网站或应用，表单可访问性的设计和开发是非常重要的，涉及的细节也是非常的多。感兴趣的同学可以阅读下面这些教程：

未读出的成功和公告消息

当操作完成时，开发人员通常会在屏幕顶部显示成功的公告消息。如果该应用没有适当的辅助功能公告通知方法，屏幕阅读器将无法大声读出这些内容。对于移动Web页面开发，开发者需要使用ARIA中的Assertive和Polite Live Regions两个方面的特性。

例如<div role="alert">用于断言公告，<div role="status">用于不会中断用户的礼貌公告。对于原生应用程序，有特定的辅助功能API可以让屏幕阅读器大声读出成功和公告消息。比如Bootstrap的Toasts组件。

没有<label>的占位符

在设计表单时，使用占位符（placeholder）作为标签（<label>）是最大的错误之一。特别是在移动端上，由于受屏幕空间限制，很多时候设计师和开发者都比较愿意在<input>元素使用了placeholder属性，而没有使用<label>文本元素。因为placeholder是把文本放在表单字段中而不是字段的上方或旁边，所以这样做会节省空间，看起来也更简洁些。

这样做的理由往往是用户能看到该字段的示例文本（例如，“紧急联系人姓名”）并知道它需要什么信息。但是，这样做是不利于认知可访问性的：一旦用户开始输入，文本就会消失；有了输入信息了，便不会再出现；除此之外，这种短暂的形式字段文本会对短期记忆造成压力；也不方便用户在提交表单之前检查他们的信息。另一个重要问题是占位符的对比度非常低，不符合WCAG可访问性要求。

WCAG 2.0 AA是全球范围内实施的可访问性标准，所以满足它的颜色对比要求是很重要的，即使你认为用户不需要占位符的帮助文本也能完成表单的填写（因为占位符文本通常是灰色的，对比度很低）。对于可访问性和可用性，我们建议设计人员对所有字段使用标准的<label>元素，确保文本标签始终显示在输入字段上方。例如，没有可见label的错误代码是：

<input type="text" placeholder="First Name" />

而正确的有label的输入框是：

<label for="first">名字</label>
<input id="first" type="text" placeholder="John" />

另外不使用<label>标签对于屏幕阅读器用户也非常的不友好。因为使用屏幕阅读器的用户通常使用tab键在表单中导航（和表单做相应交互），以跳过表单控件。如果你使用过屏幕阅读器的话，你会发现很多读屏幕软件只会读取<label>元素，任何非标签文本，比如占位符文本就通常会被忽略不读。即使你希望在UI上更匹配自己的主题风格或者品牌形象，在开发的时候，更建议将<label>内容充当占位符，同时在input获得焦点的时候改变<label>标签位置，这样既可以达到你想要的效果，又不影响可访问性方面的要求。比如：

其实在社区中有关于<label>和placeholder在用户体验上的讨论也非常的多：

缺少独特且有意义的页面标题

单页面应用程序（SPA）是一种Web应用程序，它可以加载单个HTML页面，并在用户与应用程序交互时动态更新该页面。单页应用的一个常见问题就是应用程序中的每个页面都缺少唯一且有意义的页面标题。它在新屏下动态加载内容而不是打开新的HTML页签，因此开发人员不会考虑在每次加载新屏时动态更新页面<title>文本。但是，页面标题是用户了解他们在应用程序中的位置以及他们可以期望的页面内容的关键指示符。拥有一个独特而有意义的页面标题是WCAG的特定要求，称为2.4.2页面标题。

但这并不是说无解，目前不管是使用React还是Vue这样的JavaScript框架来构建的单页面应用程序都是有相应的方式来解决每次加载新屏时动态更新页面<title>文本。比如React中可以使用React Document Title，只需要将渲染的组件放在<DocumentTitle>组件中，并通过title这个props传值即可：

class ExamplePage extends React.Component {
    render() {
        return (
            <DocumentTitle title="Example Title: Example Website Name">
                <main>
                    <!-- ... -->
                </main>
            </DocumentTitle>
        );
    }
}

如果需要，甚至可以将页面标题绑定到组件的state属性中，例如，如果你需要在组件挂载时从API或其他地方加载页面标题：

class ExamplePage extends React.Component {
    constructor(props) {
        super(props);

        this.state = {
            pageTitle: 'Loading Topics: Example Website Name',
        }
    }

    componentDidMount() {
        // Complete any tasks you need to complete before 
        // establishing page title

        this.setState({ pageTitle: 'Topics: Example Website Name' });
    }

    render() {
        const { pageTitle } = this.state;
        return (
            <DocumentTitle title={pageTitle}>
                <main>
                    <!-- ... -->
                </main>
            </DocumentTitle>
        );
    }
}

在Vue中，可以考虑使用Vue-router来管理页面的<title>内容。

这里要强调的是，不管使用什么框架来开发页面，都是有相应的方式方法来处理加载页面时动态更新<title>标签中的内容，只不过很多开发者并不会考虑。如果真正地开发一个可访问性页面，我们就需要考虑更多的事情。这也再次说明，可访问性的细节是无处不在的。

如果你对这方面感兴趣，还可以阅读：

糟糕的焦点顺序

在《使用tabindex的正确姿势》一文中深入的探讨了tabindex属性如何控制元素焦点相关的知识。焦点最基本的作用是可以告诉你的用户现在正处于应用中的哪个元素，什么元素正待激活。

在移动端上，屏蔽阅读器会显示当前元素的周围轮廓，如果用户双击，将激活该元素。单页应用则需要将键盘焦点从前一屏的焦点区域移到新屏中去；否则，每当新屏加载时，辅助技术用户将必须向左滑动（类似在PC端按键盘上的tab键）才能找到新的聚焦元素。糟糕的焦点顺序会影响使用键盘和屏幕阅读器的用户，因为他们的焦点要么还保留在旧内容上，要么已经跳过新内容了。

在Web开发中，往往是依赖于DOM源的顺序或者显式给元素设置tabindex来管理页面上的焦点，正因为如此，很多开发者在使用tabindex时并不能很好的遵守相应的规范，造成页面上焦点顺序的混乱。这样一来就给用户带来不便。因此，当你想要在元素上设置tabindex时，请先搞清楚其工作原理，只有这样才能不会让你的页面焦点混乱。

与其用不好，还不如不用！

模态框焦点问题

模式框是个窗口，强制用户在返回使用主应用程序之前与其进行交互。模态对话框的问题在于它们在被打开后却没有获得屏幕阅读器的焦点，换句话说就是，模态对话框没有把焦点放在对话框中最合逻辑的地方，以便用户可以直接采取行动。此外，开发人员通常不会将键盘和屏幕阅读器焦点限制在主要内容区域内，即使该区域已在视觉上变灰并被禁用。结果就是，可能存在这种情况：即使屏幕阅读器用户已经打开了模态对话框，但焦点仍然在打开它的按钮上；他们向左滑动以尝试阅读新内容，但仍保留在灰色主要内容中的模式对话框下方，无法采取所需操作。

汉堡菜单和手风琴未正确实现

如果代码写的不对，汉堡菜单和手风琴设计元素可能会导致视障人士的可访问性问题。汉堡菜单图标由三条水平线组成，出现在许多移动屏幕的顶部，无论是最左侧还是最右侧：

通过触摸或点击汉堡菜单图标，它会打开一个侧面菜单，其中包含一系列选项或其它页面。

手风琴是一种设计元素，可以在某些地方展开以暴露隐藏信息。手风琴将页面内容向下推，而不是像一个层或者模态框那样覆盖在页面上。手风琴元素的一个常见示例是当用户激活菜单标题时显示子菜单项的菜单：

折叠元素示例：在上面的三屏幕图中，左侧屏幕显示一个折叠所有选项的折叠元素。当用户点击或点击“个人信息”部分时，它会展开以显示与个人信息相关的输入字段，在屏幕下方按下第二部分“结算地址”，如中心屏幕所示。右侧屏幕显示“个人信息”部分关闭，并在用户激活“帐单地址”部分时显示不同的输入字段。

上图是W3C提供的示例，显示了一个手风琴元素，展示与不同类别信息相关的表单输入字段，可在W3C.github.io上的交互式手风琴示例在线体验下，以便更好地了解此功能。

展开和收起汉堡菜单和手风琴需要有有意义的可访问名称和动态状态（例如<button aria-expanded="true">, <button aria-expanded="false">）以使它们能用于屏幕读者用户。在编写手风琴和菜单时，开发人员需要为只能使用键盘的用户提供切换到手风琴或汉堡菜单的功能，并确保他们可以看到键盘焦点轮廓。

假<div>按钮

Web开发人员通常会使用<div>和<span>元素来模拟按钮，因为这样可以使用CSS轻松设置样式。在原生应用程序中，当使用非按钮元素（如<ImageView>）来编写按钮，或者使用不是从原生按钮派生的自定义控件时，会出现模拟按钮问题。非标准按钮会导致严重的可访问性问题。当点击按钮时，它们可以工作正常，但对于键盘和屏幕阅读器来说它们是不可操作的。此外，模拟按钮也不会把自己正确地暴露给可访问性API。简单的解决办法就是使用真正的<button>而不是<div>。

在社区中一直有一个类似的话题在探讨link（<a>） vs button（<button>）。但如今，在移动端上开发的页面的时候，很多时候不管是链接好，还是按钮好，很多开发者都喜欢使用div或span这样的标签元素来替代。当然，很多时候从视觉稿上也无法分辨出link和button，因为他们长得太像了。正因如此，@Estelle Weyl才会在Twitter上吐槽：”HTML is accessible. Don't fuck it up!“。当然社区中也有持反对声音：

贵前端圈真乱！

这里想说的是，我们应该尽可能的使用带有语义化的HTML标签。这一点在前面语义化一节中也有说过到。当然，如果你对link和button方面的争论感兴趣的话，可以花点时间阅读下面这些文章，还是蛮有意思的：

千万别小看了HTML，真正的开发者应该懂得HTML，能在适合的地方采用最适合的HTML标签，即使用正确的标签元素！

插个有意思的话题，@Jason Grigsby和@Adrdrian用两篇文章给人阐述了HTML在商业中也是很值钱的：

用这个来谈前端的价值，是不是也非常的有意思。值得每一位前端开发者去思考！

不支持的动态类型

创建应用时，支持动态类型非常重要。动态类型允许用户指定其首选字体大小（如上图所示）。这使视力不佳的用户可以轻松增加文本的大小。原生应用程序需要绑定到操作系统的大文本辅助功能API，以检查用户何时更改其文本大小首选项。然后，API将能够更新应用程序的文本以响应用户的新文本大小设置。当使用默认原生视图而不是自定义视图时，很容易支持动态类型。

文本和背景之间的对比度差

WCAG的色彩对比度要求尽量选择能够在内容和背景之间提供足够对比度的颜色，以便任何具有视力障碍和颜色缺陷的人都可以看到内容。WCAG 2.0 AA级要求普通文本的对比度为4.5:1，大文本的对比度为3:1。大文本可以具有较低的对比度，因为它的大小更容易阅读。许多网站和应用程序设计不符合WCAG对比度要求，例如，许多应用程序在白色背景上使用浅灰色文本，在白色上使用红色文本以显示错误消息，而非标准蓝色链接文本则不足以满足WCAG对普通文本的4.5:1的比率要求。输入占位符、表单错误消息、灰色页脚文本都是对比度失败的常见区域。设计人员需要确保移动网络和应用程序设计中使用的文本在根据文本背景进行测量时符合WCAG 2.0 AA级颜色对比度要求。

前面有关于颜色对比度之间的讨论，花了很长的篇幅。

WAI-ARIA使用不正确

可访问的富Internet应用程序（WAI-ARIA）定义了使残障人士更容易访问Web内容和Web应用程序的方法。它特别有助于使用了Ajax、HTML、JavaScript和相关技术开发的动态内容和高级用户界面控件。目前，某些残障用户无法使用网站中的某些功能，尤其是依赖屏幕阅读器和不能使用鼠标的用户。来自W3C Web可访问性计划的可访问的富Internet应用程序规范WAI-ARIA解决了这些可访问性挑战。解决这些挑战的一种方法是为辅助技术定义了新功能，通过WAI-ARIA，开发人员可以让高级Web应用程序也能供残障人士使用。但是，不正确的使用可能会产生意想不到的影响。

可访问性很难自行理解，并且，开发人员在编码代码时，会经常不测试在屏幕阅读器上的效果；再加开发人员也并非透彻理解即庞大又复杂的WAI-ARIA规范，也缺少使用屏幕阅读器进行测试的经验，导致灾难经常出现。一个常见的问题是React模态对话框，将aria-hidden=true属性/值放在<body>标记上，这完全对屏幕阅读器用户隐藏了整个页面。浏览器和屏幕阅读器依据的是代码，而不是屏幕上的可见内容。因此，如果你的代码说使用aria-hidden=true来隐藏整个页面，那么屏幕阅读器就会看不到了。为了克服复杂应用程序的可访问性问题，开发人员对WAI-ARIA和可访问性的教育至关重要。使用屏幕阅读器测试你的代码，并通过自动可访问性测试工具（如aXe和W3C的HTML5验证器)运行下代码，有助于避免不正确使用WAI-ARIA时出现的许多问题。

WAI-ARIA体系是庞大的，在使用的时候最好能够参考官方提供的最佳实践中提供的相关案例！

输入类型缺少移动键盘可用性增强功能

这个和前面提到的表单验证有点类似。只不过把<input>的type类型单独拿出来讲。这是因为，很多开发者都习惯于自己的思维模式，看到input输入框的时候，除了password就是text。

事实上，在移动端可以根据用户在其设备上键入的数据类型来显示不同的触摸屏键盘。

正如上图所示，正确的type类型能给用户带来更好的体验。例如，你想要用户输入电话号码，但是你却弹出完整的QWERTY键盘，那这就会出现明显的可用性问题。

HTML5输入类型允许你为特定的数据类型显示更可用和更简化的键盘。开发人员需要为所需的输入指定正确的键盘类型。例如，在移动应用程序中包含表单输入字段时，请确保使用<input type=tel, number, email, etc.>，这可以让在移动设备的输入更轻松。从手机上访问Paul Adam的“HTML5输入类型演示”，了解不同虚拟键盘的示例。

除了使用正解的type之外，还可以考虑使用input的inputmode属性：

给视频添加标题和子标题

这可能是WCAG最麻烦的原则之一，这不是因为技术上的困难，而是因为它可能是费时的。不过有一些方法可以做到这一点。

让我们以YouTube为例。一旦你在这个平台上上传了一个视频，你就可以启用关闭标题。这些都是自动生成的，可能在某些情况下是不准确的，这取决于语言、背景噪音或说话人的口音。不过，这些都很容易实现，而且在大多数讲英语的视频中都能很好的工作。

如果我们很难看到百分百准确的标题，很难相信YouTube会有好的复制，所以我们必须自己写标题，或者雇佣第三方人员来做。如果我们不用任何字幕软件，或者我们希望我们的社区帮助我们翻译内容，YouTube将采用最常的副标题格式（.srt、.sub和.sbv）以及让我们在平台上写副标题。而不让管理员访问我们的账号，这将是非常方便的。

也许你不想把YouTube当作你的主机平台。也许您希望在你的服务器上使用一个HTML5视频。HTML5有一个<track>标签，可以使用它方便让你添加你喜欢的标题和字幕软件，你可以使用你喜欢的WebVTT：

<video controls> 
    <source src="movie.mp4" type="video/mp4"> 
    <track label="English Captions" kind="captions" srclang="eN" src="captions.vtt" default> 
    <track label="Subtitulos en español" kind="captions" srclang="es" src="subs.vtt"> 
</video>

有关于视频相关的可访问性资料还可以参阅：

隐藏元素

在Web开发中，经常会用到图片替代文本的方案。但如果运用不好，在可访问性方面是致命的。比如淘宝（PC端）在禁用CSS之后，图片替代文本这个细节之处就做得不够完美：

暂且不说使用了哪种技术方案，仅从图片替代文本的技术方案来思考，你至少想到了十多种隐藏Web元素的姿势：

  • 设display的值为none，这种方法也被称为FIR方法
  • 负margin值（一个足够大让元素移出视窗外的负margin值）
  • 负text-indent值（text-indent具有一个足够大的负值时，可以达到隐藏文本的效果）
  • 设置height、font-size和line-height值为0，让元素在视觉上不可见
  • CSS的clip让元素在视觉上不可见
  • position:absolute配合任何一个足够大的left、right、bottom或top的负值，让元素不在视窗范围内显示
  • visibility设置值为hidden在视觉上让元素不可见
  • opacity设置值为0在视觉上让元素不可见
  • clip-path让元素在视觉上不可见
  • HTML元素添加hidden属性，让元素不可见
  • filter的opacity()取值为0在视觉上让元素不可见
  • mix-blend-mode在高亮模式下，让视觉上元素不可见

上述提到的那些技术手段都可以让Web元素真或假隐藏。但它们在Web中的具体渲染还是有所差异性的：

  • 是否生成盒模型？
  • 该盒模型是否影响布局？
  • 该盒子在屏幕上可见吗（视觉上可见）？
  • 元素的内容会被屏幕阅读器读取吗？
  • 元素是否可操作（可单击，可聚焦）吗？

如果放到可访问性中来探讨，图片替代文本如果处理不好，会直接影响有障碍用户群体访问你的Web，特别是依赖于屏幕阅读器的用户群体。我前段时间针对这些技术方案做过一些测试，测试的结果如下：

隐藏术 是否有盒模型 是否影响布局 屏幕上是否可见 屏幕阅读器是否可读 元素是否可操作
display: none ✗ ✗ ✗ ✗ ✗
hidden="true" ✗ ✗ ✗ ✗ ✗
visibility:hidden ✓ ✓ ✗ ✗ ✗
opacity:0 ✓ ✓ ✗ ✓ ✓
position:absolute ✓ ✗ ✗ ✓ ✓
clip-path ✓ ✓ ✗ ✓ ✗
mask ✓ ✓ ✗ ✓ ✓
改变盒型尺寸 ✓ ✓ ✗ ✓ ✓
transform ✓ ✓ ✗ ✓ ✓

众多方案中，我更推荐使用下面这种方案。该方案在让元素获得焦点的时候，隐藏的内容会显示出来，比如说使用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提供的方案。

有关于隐藏相关的话题还可以阅读：

通过在开发期间避免这些常见的移动应用程序可访问性问题，你将给大家提供一个更易访问的产品。

从简单开始做起

在生活中，无法一口吃成胖子；在工作中也是如此。如果你坚持阅读到这里，你会发现：

要做好Web页面或应用程序的可访问性并不是件易事，甚至会怯步。

既然未来是美好的，现实是残酷的。那么我们不仿先从简单的开始做起。接下来再花点篇幅和大家聊聊，在实际生产中，我是怎么来给应用添加可访问性的。

在今年上半年，首先在金币庄园上做了小小的尝试。

这是一款游戏化的产品，从页面结构上来看的话，是普通DOM元素和Canvas的相结合。如果要给他添加可访问性，我想到的是先从一些用户频繁操作的区域开始，把暂时啃不下来的<canvas>放一边。就拿上图来说（游戏化区域），很多ICON图标都是可以点击的，点击之后有可能会有弹窗，有可能跳到新的页面。如果从DOM结构元素来考虑的话，它们要么是一个链接（<a>），要么是一个按钮（<button>），但从源码中查阅的话，他们都是一个<div>。如果和前面提到的可访问性知识对号的话，我们犯了”没有使用正确的HTML标签“，也未考虑语义化相关的事情。

如果你足够仔细的话，我们很多地方都使用了”图案替代文本“。图案替代文本这个方案没错，但我们在这个过程中犯了另一个错误，在DOM源的结构中，仅使用了空标签div，却没有输入任何描述性的文本。

仅仅这两点，可访问性就不够及格。

为了改善这样的现状，简单地做了三件事情：

  • 在类似<button>的div元素上添加了AIRA的角色(role)判断，即<div role="button">，告诉屏幕阅读器，这是一个按钮button
  • 在空的div元素添加了描述性的内容，比如”换种子“，在DOM源修改成<div role="button"><span class="sr-only">换种子</span></div>或者使用ARIA的aira-label属性<div role="button" aira-label="换种子"></div>
  • 由于div元素是不可聚焦元素，为了屏幕阅读器可以在该元素上得到焦点，所以在该元素上显式设置了tabindex="-1"

也就这几个小小的改动，如果你尝试着在移动端开启”旁白“功能，当你聚集在这些图标上时，会读出相应的内容，也就可以告诉你双击之后会去哪？

习惯和成长同行

从上面的示例上来说，虽然未做得很完美，但也有新的开始。

从这个项目开始，在平时开发项目的时候，我习惯性将可访问性考虑到项目中，比如在编写代码的时候：

  • 尽可能的使用语义化标签
  • 将WAI-ARIA的role、state考虑到标签和组件中
  • 注意细节，比如说图片替代文本，能否让屏幕阅读器正常读取对应的内容，比如<img>标签添加alt属性等

对于语义化而言，并不是说你把HTML中带有语义的标签用上了就具有语义化了，但你可以尝试着两条检测原则：

  • 禁用所有CSS，文档的大纲和结构是否清晰
  • 禁用所有CSS，Web页面或应用能否正常浏览

个人觉得难一点，比较费时的是WAI-ARIA的实际使用。说实话，WAI_ARIA体系很大，它有很多角色，状态的控制。不同的组件或者设计模式在使用ARIA都会有所不同，就我个人而言，我喜欢直接阅读规范的方式来写ARIA，更多的时候是参考WAI-ARIA的最佳实践中提供的案例。

并不是用了ARIA就对可访问性友好，用对了才能有效

在此我建议您在自己的下一个项目中，尝试着将WAI-ARIA体系加入到自己的项目中。

再说回来，如果你实在不知道自己在可访问性方面做得好还是不好，或者要怎么去修改，也不用担心，你可以按照前面提到的七步eggl你检测和修复可访问性的几个步骤去做。现在很多工具可以帮你检测出存在的缺陷，并且提供指导性的建议，按着建议去做准没错。

有备无患

这是一个切身体会，今年双11主互动的多人PK项目，上线不久就被要求做无障碍方面的需求。值得幸运的是，在开始做该项目的时候，我就把一些可访问性的细节考虑进去了。换句话说，基本上达到了最低标准。不会影响链路的操作。

但里面有很多细节是没有做好的，比如点击按钮拉起浮层，比如Tab选项的切换，比如模态框等。控件未做到联动。希望在下一个项目中能让这方面做得更完美一些。

再说句题外话，看到《30万盲人在天猫双11剁手盖楼分红包》一文还是有些许的自豪感。

待续...

最后在这里不做小结，因为要做好可访问性还有很多事情要做。在未来，希望有更多的机会和大家一起探讨可访问性相关的话题...

参考阅读

返回顶部