最近，在处理一个 ElementUI 的 PR 时，有幸接触到关于可访问性的知识。在学习之余，也将之记录下来作为沉淀。
前言
可访问性(Accessibility)，简称 a11y，目的是为了使你的产品能够被更多人所正常使用。
在大多数人理解中（包括之前的笔者），可访问性主要是解决一些身体上不便的用户使用产品的问题。但广义上而言，可访问性也包含了移动端等各种设备，或者网络缓慢的产品使用人群等。
国内因为互联网目前处于高速发展中，更注重的是功能的快速迭代和市场的竞争。而可访问性实际解决的是小众人群的需求，在当前的发展环境中，属于 ROI(投入产出比)较小的部分，因此大多数公司和产品在该方面投入资源较少。而在国外部分地区，可访问性甚至拥有法律层面的强制要求，因此假设产品定位在国外市场，可访问性的具备与否将成为能否占领市场的重要因素。
可用性规范
使用内置语义标签
在 html5 规范中，新增了大量诸如 article, nav, aside, main 之类富含语义的标签，这些标签一方面方便与搜索引擎爬虫分析页面内容。同时，也具有天生的可访问性属性，因此，在构建可访问性网页时，优先选用这些具有语义的标签。
不更改内置语义标签含义
在使用语义标签的时候，尽量保证该标签与语义含义所对应。同时不使用 role 等语义属性更改原始语义。
例如： 在构建一个语义为 tab 的 head 标签时
避免使用该写法：
<h2 role=tab>heading tab</h2>
改为使用：
<div role=tab><h2>heading tab</h2></div>
可用键盘交互控制
在可访问性要求里，所有的可访问性交互，都应同时可使用键盘进行控制。
假设你创建了一个可点击/可滑动/可拖拽的组件，那么同时需要保证用户能通过键盘定位到该组件并执行对应的操作。
对于这一点，笔者表示深刻认同。在笔者认为，这点一方面是可访问性的要求，另一方面也是良好的 UE 体验，尤其是在注重交互的表单等模块下，键盘交互往往能节省使用者大量时间。
使用 role 与 aria-* 属性进行可访问性定义
在内置语义不足以支持使用的情况下，使用对应的 role 与 aria-* 属性值进行语义定义。
在 w3c 规范 用了大量篇幅进行不同 role 与 aria-* 属性的使用进行说明，有兴趣的小伙伴可以直接进行阅读。
总结
可访问性的设计，不仅仅为身体不便的用户提供了无障碍访问能力，同时使得页面开发语义更清晰，便于浏览器进行 SEO 优化，实则是一举多得之事。也许 role 与 aria-* 属性等针对屏幕阅读器识别的语义上手较有难度，但基于原生标签的语义可访问性使用，在日常开发中，笔者也将会更加重视。