背景

信息无障碍，英文为 Accessibility（a11y），是指任何人（无论是健全人还是残疾人，无论是年轻人还是老年人）在任何情况下都能平等的，方便地，无障碍地获取信息、利用信息。

全球 76 亿人中，互联网人口突破 44.3 亿。联合国残疾人调查世界上 10% 的人口即七亿六千万是残疾人。他们是世界上最大的少数群体。

互联网将近四亿五千万残疾用户。2018年facebook的65岁及以上的老人用户增长了20％。

中国有近2亿需要关怀的人群，其中包含1.5亿 65周岁以上的老年人，1700万视障者，2700万听障者和大量的认知障碍人群，他们生活在有网络的地方，却因生理功能受限，不能顺畅地使用互联网。

注：考虑到内部信息的敏感性，下面的一些实践案例会以其它网站为例

标准解读

标准选择

在正式做之前，我们需要先确定采取哪套无障碍标准，目前世面上常用的无障碍规范有这几个：

• 《GB/T 37668-2019 信息技术 互联网内容无障碍可访问性技术要求与测试方法》
• 行业标准YD/T1761-2008《信息无障碍身体机能差异人群网站无障碍技术要求》
• 《互联网网站适老化应用设计规范》
• WCAG（Web内容无障碍指南）

它们之间很多指标是类似的，我们项目选择了这两个规范：

• 《GB/T 37668-2019 信息技术 互联网内容无障碍可访问性技术要求与测试方法》
• 《互联网网站适老化应用设计规范》

其中第一个标准是面向视障人士，以下简称”无障碍规范“，另一个则是是面向老年人，以下简称”适老化规范“。

标准解读

标准有了，不意味着就可以直接开发了，对于没有开发过无障碍的人，看这两个规范的感觉就好比段子所说”每一个字我都能看懂，但是连在一起我却不知道是什么意思“，这也是我们做之前最头疼的地方，所以我觉得很有必要和大家说一下过来人对于这些标准的解读。

无障碍规范

概述

---

无障碍规范由这几个部分组成：四大原则、十五项准则、五十九个指标，三个等级

四大原则： 首先是四大原则，它提供了Web无障碍的基础：可感知性，可操作性，可理解性和兼容性。

十五项准则： 提供的 15 项准则是为了达到这样一个基本目标：作者应努力使内容更容易让不同症状的残障用户能够访问。该准则是不可测试的，但提供了框架和总体目标，以帮助作者了解成功标准和更好地实现该技巧。

五十九个指标： 对每一个准则，提供了可测试的成功指标，以允许该标准被用在需要进行需求和一致性测试的地方，这个才是指导开发、设计以及验证的内容。

三个等级： 为了满足不同的群体和不同的情况，我们定义了一致性的三个级别：一级（最低），二级，三级（最高），不同级别对应需要满足的指标数量不同，其中一级应满足对应 20 项指标；二级应满足一级全部指标与二级 17 项指标；三级应满足全部 59 项指标，要满足哪一个级别的标准需要视自己的业务情况而定，不建议将三级的技术要求作为整个网站或应用程序的通用策略，因为对于某些特定内容不可能满足所有三级的技术要求。

指标解读

---

确定好要实现的等级，下面就是根据等级对应的指标去进行实现了，对于 59 项指标来说，在这里一一去解读我觉得实在是过于冗长，我简单以我个人的理解来阐述一下我对这些指标的理解，我首先将这些指标概括为三大类：产品交互类、UI视觉类、前端适配类，下面我一一介绍一下：

产品交互类： 需要产品交互在软件设计之初就要从功能层面去进行兼容的指标，比如：

• 验证码：如果网页或移动应用中存在非文本验证码，则应提供可被不同类型感官(视觉、听觉、 触觉等) 接受的替代表现形式.以适应不同的残疾人群使用，说白了就是需要提供无障碍人士可以操作的验证码，这个后面会有详细介绍
• 跳过重复模块：需要提供快捷方式能够跳过重复模块读取网页主要内容，且焦点同时跳转到主要内容处，这个一般是针对 PC 端需要设置对应的快捷键可以直接聚焦到主要内容区域

UI视觉类： 需要视觉同学在出视觉稿时就要考虑的指标，这类指标一般都是有明确的数值要求的，比如：

• 视觉呈现：段落内的行距至少为 1.5 倍，其段落间距至少比行间距大 1.5 倍
• 目标尺寸：网页内容中，指针输入的目标尺寸至少为 44x44 层叠样式表像素点，就是说可交互的元素的尺寸不能小于 44x44

前端适配类： 这种就需要开发同学根据 W3C 规范里面的 ARIA相关属性去进行适配了，比如：

• 非文本控件：一般是对于可以交互的组件，如按钮、输入框等表单控件，这些控件如果不设置 A11Y 属性则视障人士无法通过读屏软件理解该如何使用，这里面场景比较多，下面我会举例说明
• 分文本内容：一般是对于图片类的内容，如果是装饰性质的则需要通过设置 ARIA 属性让其对读屏软件隐藏，如果是非装饰性内容则需要设置读屏文案

这里面个人感觉产品交互类和UI视觉类标准说的都比较明确，可以在产品设计阶段就按照标准去进行设计，就是前端适配类的涉及到代码开发，这个如果之前没有做过无障碍开发的会感觉无从下手，所以下面我会从开发角度去分享一下我的经验。

适老化规范

适老化规范和无障碍规范相仿，也是由若干原则、准则和指标构成，只不过指标没有那么多，也不做等级区分，里面大部分是产品交互类以及UI视觉类的，其中需要前端新开发适配的主要是工具条，工具条是一系列功能的集合，其中包括了：大字幕、大鼠标、放大镜、语音播报等功能，目前市面上大的门户网站都有该功能可以进行参考，这部分在后面的开发沉底里会详细描述。

这里以百度首页为例

开发沉淀

如果用一句话概述前端如何适配无障碍，那就是让页面中的各种元素能够支持读屏软件读屏，更进一步说如何去做的话，其实大部分内容都可以在 MDN 的ARIA文档中找到，它定义了不同用途的控件应该设置什么属性，但是也有些场景里面没有涵盖到或者说需要一定的经验积累才能避免走弯路，所以这里我着重说一下我们在开发过程中沉淀的这些经验。

无障碍

焦点聚合

在无障碍协会对我们功能的测试报告中，焦点冗余的问题占比应该是最多的，那么什么是焦点冗余呢，在无障碍指标中专门有一条指标”3.3.2.2 组件聚焦关联性(三级)“：在移动应用中，当多种组件(文本、图片、音频或视频等) 所表达的语义相同时，应对语义相同的部件设置联合的单一聚焦框而非分别设置；无关联性组件之间的聚焦框应能对用户进行严格分隔展示

说人话就是语义相同的元素要设置为一个统一的焦点，避免拆分成多个焦点，这样会提升视障用户操作的复杂度，举例来说下面是几个金刚位的图标和文案，你应该设法让图标和文案统一成一个焦点而不是拆分成两个焦点

这里以支付宝首页金刚位举例

做法也并不复杂，只要在最外层的 element 上设置对应的 role 和 aria-label，然后对内部的子元素设置 aria-hidden=true 让其对读屏软件隐藏即可

这里要注意对于纯文本的场景，比如下面这种，如果不做任何处理这里的读屏信息被均被拆分为多个焦点，例如“姓名”、“：”、“xxx”等，需要设置 role=text 外加 tabindex=0 才能起作用

验证码

我们知道传统的人机校验方式（如：滑块验证、拼图等）对视障用户都很不友好，所以我们通过调研找到了四种替代的人机校验方式：智能无感知验证、语音验证、短信上行验证、支付宝挥一挥验证。

弹窗

弹窗是业务中常用的组件，对弹框组件做无障碍适配的时候有两个地方是需要注意的，一个是隐蔽/显示底层元素，一个是焦点控制，下面我详细介绍一下

隐蔽/显示底层元素

没做过无障碍的开发同学在做弹窗适配的时候可能会只关注到弹窗本身应该设置什么属性，而忽略了底层元素的焦点问题，简单来说当弹窗显示时应该将底层元素设置 aria-hidden=true 对读屏软件隐藏，避免可以滑到底层元素进而造成误操作，当弹窗关闭时应该设置 aria-hidden=false 恢复底层元素的可访问性

useEffect(() => {
    const root = document.getElementById('root');
    if (visible) {  
        root?.setAttribute('aria-hidden', 'true');
        root?.setAttribute('tabindex', '-1');
    } else {
        root?.setAttribute('aria-hidden', 'false');
        root?.removeAttribute('tabindex');
    }
}, [visible])

焦点控制

因为视障人士不能看到页面内容，只能通过触摸感知当前读到的内容，而弹窗这种突然出现的控件会打断他的浏览顺序，所以需要开发者手动控制焦点让视障人士能够顺畅的进行浏览，当弹窗出现时将焦点设置到弹框标题上，当弹窗消失时将焦点返回给触发弹窗的那个元素

/**
 * 弹框关闭时将焦点聚焦到之前打开弹框的元素
 */
const returnFocus = () => {
  if (focusElm) {
    const timer = setInterval(() => {
      focusElm.setAttribute('tabindex', '-1');
      focusElm.focus();
      clearInterval(timer);
    }, 200);
    document.removeEventListener('click', getFocusElm, true);
  }
};

读屏文案冗余

在刚开始做无障碍的时候，我们总想多做一步，有时候在设置读屏文案时为了防止视障用户不理解，我们特意多加了一些描述性文案，但是后来无障碍协会在测试过程中指出这些文案其实没必要添加，因为能够使用读屏软件上网冲浪的视障用户对互联网软件的一些基本操作已经是有认知的，过渡的文案会显得冗余。

案例一

案例二

焦点

顺序控制

对于页面中的焦点顺序，一般是按照从上到下从左到右的顺序进行朗读（同展示的顺序），如果你发现读屏的顺序和页面展示的顺序不一致，则需要查看你的页面 DOM 结构是否和页面的展示顺序一致，读屏软件是默认按照 DOM 结构的顺序来朗读的。

焦点控制

在弹窗那节我们说过因为视障人士不能看到页面内容，只能通过触摸感知当前读到的内容，所以当弹窗出现时需要将焦点设置到弹框标题上，其实除了弹窗其它的涉及到页面内容变化的情况，也需要手动控制焦点，让视障用户知道当前页面内容的变化，比如：

• 页面跳转时，将焦点定位到页面标题上
• 进入到表单页面时将焦点定位在第一个表单区域上

适老化

适老化的指标没有无障碍那么多，常见的问题主要集中在文字颜色的对比度、焦点区域大小、工具条功能的可用性，键盘可访问性上面，颜色对比度以及焦点区域大小需要视觉进行走查确认，这里主要说一下工具条和键盘访问。

工具条

工具条只是无障碍的一种实现形式，WCAG/行业标准没有提到要采用工具条，只有国标（3级）和适老化有提及，并且工具条是一系列无障碍功能的集合，一般包含文本放大缩小、在线语音阅读、大鼠标、多种配色切换、辅助线、大字幕。

注：工具条需要注意的是所有功能均可适配工具条使用，进入页面后，应允许用户先打开工具条相关功能，再进行下一步的操作

键盘操作

针对 PC 的网站，键盘操作对视障用户非常重要，需要能够让用户通过键盘访问到任何一个非装饰性元素，并可以通过键盘触发可交互的控件。

可访问

可访问性这里主要针对两种类型的页面内容，一种是可交互的，一种是不可交互的：

• 可交互控件：能够支持通过键盘tab键按界面逻辑顺序遍历界面所有可交互的元素组件，具有同样目的的相邻元素有且只有一个焦点
• 不可交互空间：可以通过键盘方向键遍历到界面所有不可交互的元素组件

可操作

可交互的控件需要能够支持通过键盘按键进行触发，比如回车键。

业务经验

上面所说的都一些无障碍开发需要注意的硬指标，这些指标只是约束产品能够让视障用户可用，但是是否真正好用就需要我们在产品设计阶段去进行思考，增加更人性化的功能，或者根据自己的业务特点来做自己的无障碍产品功能，下面是我们业务中探索的一些手段。

网站整体介绍

为了方便视障用户在一进入网站后，能够快速了解网站的基本信息，我们在首页设置了隐藏的网站介绍新，当新用户一进入网站后作为第一个焦点进行朗读。

表单提交

对于复杂的表单，用户经常会遇到表单内容太多，填完之后不知道整体的信息概览，或者提交之后发现信息填错了，这种情况对于视障用户或老年人更是明细，所以我们对于复杂表单都会在提交前弹出信息预览框，将表单信息进行整合展示，方便用户在提交前进行确认。

用户调研

除了我们自身对于标准的解读以外，如果条件允许，我可以和真正的视障用户进行访谈，了解到他们的一些真实的诉求：

（1）读屏信息不能过度整合，也要⽀持单条可读

（2）健全人习惯的交互可能对于视障用户来说并不理解（如：自动填充身份证号）

（3）视弱/色盲用户比较偏爱深色模式-深⾊模式更容易找到焦点

（4）色盲用户比较偏爱更存粹的颜色

（5）对于复杂的交互可以提供推荐功能

无障碍协会

如果想要将无障碍能力做好，并且得到相关的认证，建议还是找一家靠谱的无障碍资格认证的机构，帮助进行无障碍能力的测评和认证，机构中有专业的老师可以进行相关能力的咨询，并且认证人员中有视障人士进行检验，保证最终的网站是经得起真实用户使用的，我们的项目开发中，无障碍协会就提供了很大的帮助。

写在最后的话

在整个开发过程中，其实深刻的体会到了视障人士的不便，尤其是一些复杂的功能对于明眼用户来说都较为复杂，更别提对于视障用户了，所以我感觉无障碍决不能只满足于对标准的适配，还应该更多的去优化体验，实际走访用户了解他们的习惯，最后奉上一句我很喜欢的slogan ：让所有人平等享受现代文明。