Web无障碍（WebAccessibility，取头尾各一个字母，总共有11个字母，因此简称a11y），也叫可访问性等。是指在Web开发无障碍性意味着使尽可能多的人能够使用Web站点，包括那些有视觉、听觉、运动和认知障碍的人。Web无障碍的目的是促进公平、包容和可持续的数字社会发展，让尽可能多的人都能够充分地参与到数字经济和社交生活中。
通过实现Web无障碍，不仅可以提高网站的可用性和用户体验，也能够促进社会的包容性和公正性，让更多人都能够享受数字经济和社交生活带来的便利和快乐。无障碍的实现不只是为了服务残疾人，而是为每个人提供更好的用户体验，并促进商业和社会应用程序的包容性和可持续性。
根据世界卫生组织2022年发布的最新数据，全球不同类型残疾的人数估计如下:
另外截止到2020年，我们国家中国残疾人总人数为8592.8万人，60岁以上老年人口约为2.68亿人，占全国总人口比例为19.14%。注意这些数据估计只是近似值，可能不完全准确，可能存在一个人患有多种障碍疾病等其他情况。此外，世界不同区域在残疾统计报告的定义和方法上可能存在差异。
在实际开发中，由于不同的应用功能及使用场景等因素，我们不可能完全覆盖所有人群，尽自己最大的能力让尽可能多的人能够无障碍的使用自己的应用就好，因此在开发中，我们主要考虑以下几种残疾类型：
当然还需要考虑其它的残疾类型，根据自己的实际开发的应用程序的用途，了解哪些用户会使用到自己的应用，还要考虑用户的年龄、文化差异或意识形态差异而遇到困难等因素来创建更加包容的设计。
WCAG（Web内容无障碍性指南）2.0和2.1是由万维网联盟（W3C）发布的一系列规范，旨在确保Web内容对所有人都可访问，包括残疾人。能帮助Web开发者创建尽可能无障碍的内容，从而使得更多的人能够方便地使用Web。
WCAG2.0于2008年发布，共有12个准则，每个准则都有一些成功标准，以帮助开发者创建无障碍的Web内容。其中每个成功标准都有三个级别：A、AA和AAA，级别A为最基本的要求，级别AAA为最高的要求。建议网站和应用程序至少达到AA级别的无障碍要求。因为AA级别的要求已经包括了许多基本的无障碍功能，可以满足大多数用户的需求。但是，如果网站或应用程序的用户群体中有许多有特殊需求的人，例如视觉障碍者或听力障碍者，那么建议尽可能达到AAA级别的无障碍要求，以确保他们能够完全访问网站的内容。
WCAG2.1是WCAG2.0的扩展版本，于2018年发布。它新增了13个成功标准，其中包括一些针对移动设备、低视力用户和认知障碍用户的要求。这些新的成功标准可以帮助开发者进一步提高Web内容的无障碍性。
HTML5引入了对WAI-ARIA的官方支持，并提供了新的语义元素和属性来支持无障碍访问。WAI-ARIA（WebAccessibilityInitiative–AccessibleRichInternetApplications）是一项由国际标准化组织（ISO）和W3C共同制定的技术规范，旨在提高Web应用程序的无障碍访问能力。它定义了一组属性和角色，这些属性和角色可以在HTML、SVG和其他Web技术中使用，以帮助屏幕阅读器和其他辅助技术理解Web内容的结构、功能和交互。对于通过动态内容或用户界面控件改变而不是在页面加载时进行完全渲染的应用程序尤其有用。
其中，WAI-ARIA的核心之一是ARIA（AccessibleRichInternetApplications）。它是一种Web技术，允许Web开发人员向HTML元素添加额外的语义信息，以便于使残障用户能够更好地使用Web应用程序。还为Web开发人员提供了一种简单的方式来改善Web应用程序的可访问性。
注意：
WAI-ARIA规范的主要内容有：
注意：使用role属性并不意味着我们可以忽略HTML的基本结构和语义。仅应该在需要进行语义增强的情况下使用，而不是将其作为一种浏览器样式的替代方法。
不同的角色之间，可能会存在超类或子类的关系，如果你熟悉JavaScript的类就很好理解了。WAI-ARIA规范中定义了近100个不同的角色，这些角色可以被分为以下几种类别（角色具有的必需、支持、继承和禁止的状态/属性请看后文状态与属性部分）。
抽象角色表示为网页语义而设计的一组无形的角色，描述了用户界面中的结构和行为。
注意：抽象角色只是用来构建具体角色的概念模型，它们缺乏明确的语义含义，可能会导致混淆和错误的解释，因此不能被直接用于描述Web内容。
部件角色代表用户界面中的交互性控件或部件。例如，按钮、滑块、文本框、下拉菜单等。
文档结构角色是一组用于描述网页结构，通常不是交互式的。
标志性角色用作导航地标的页面区域，所有这些角色都继承自landmark基类型
实时区域角色描述如何将Web应用程序中动态变化的内容与屏幕阅读器进行交互，使得这些内容能够被盲人和视力受限用户等人士正确地感知。
窗口角色角色充当浏览器或应用程序中的窗口。
WAI-ARIA提供了一组辅助功能状态/属性，用于支持各种操作系统平台上的平台辅助功能API。属性是控件或组件的持久化特征或配置选项。通常在创建控件或组件时设置，并且在其整个生命周期内保持不变，对应于控件或组件的默认状态；状态是指控件或组件当前所处的状态。两者都提供了关于对象的特定信息，并且都构成了角色性质定义的一部分。在HTML中两者均以aria-开头，作为HTML的全局属性使用。
注意：状态/属性也存在继承。
属性和状态的值均可以是以下几种类型：
注意：这些是状态/属性的通用类型，但不定义特定的表示。
在WAI-ARIA1.2规范中，状态/属性有40多个，分为下文6类。
注意：规范中有一类Drag-and-DropAttributes，但是在WAI-ARIA1.1规范中该类的两个状态/属性就已经被弃用了，因此本文不过多赘述。
有些状态/属性会出现在多个分类的情况，在本文中重复的状态/属性将提出放在一个表格中，如果分类A中的全部状态/属性也都属于其他分类，则会在分类A中说明。
另外各分类名称的缩写是我定义的，方便在重复的状态/属性表中查阅（有水文的成分）。
可翻译状态/属性在页面本地化时应该进行翻译。
WAI-ARIA1.2规范：
重复状态/属性：
有些状态/属性适用于所有宿主语言元素，而不管是否应用了角色。除非另有禁止，否则所有角色和所有基本标记元素都支持以下全局状态/属性。如果角色禁止使用任何全局状态或属性，那么这些状态或属性将在定义角色的部分中包含的特征表中被列为禁止的。
包含GUI系统或富internet应用程序中常见用户界面元素的特定属性，用于支持WidgetRoles。
包含特定于富Internet应用程序中实时区域的属性。这些属性可以应用于任何元素。这些属性的目的是指示内容更改可能会在没有元素具有焦点的情况下发生，并为辅助技术提供有关如何处理这些内容更新的信息。
注意：这部分状态/属性也均属于GSAP。适用于所有角色，并且没有继承到其他角色当中。
包含指示元素之间的关系或关联的属性，这些关系或关联无法从文档结构中轻松确定。
当在具有DOM焦点的元素上设置aria-activedescendant的值时，作者必须确保满足以下两组条件之一:
对于aria-colindex：作者必须将aria-colindex的值设置为大于或等于1、大于同一行中任何先前元素的aria-colindex值以及小于或等于整个表中的列数的整数。对于跨多个列的单元格或网格单元格，作者必须将aria-colindex的值设置为跨度的开头。
一个角色可以有多个状态/属性提供特定信息，一个状态/属性也可以适用于多个角色。以角色为主，与状态/属性会有以下几种关系：
注意：不是所有角色都会与状态/属性存在这四种关系，有些角色可能没有必需状态/属性。
WCAG和WAI-ARIA都是为改善Web内容的无障碍性而设立的标准和规范。但它们有几点不同：
另外WAI-ARIA补充了WCAG的内容，它们可以一起使用来实现更好的无障碍性。可以在元素上使用WAI-ARIA来增加交互式组件的无障碍性，并遵循WCAG的标准来确保页面的整体可访问性。
目前在一些设计社区中有很多大佬写了各种设计指南，对各种细节，包括字体样式、行高、滚动条、颜色对比度等等很多方面都有详细的建议和说明，大家也看得不少了，我就不过多赘述了。可以参考：
。。。
虽然这些指南不是标准规范，但是也能很大程度地提高Web应用的无障碍访问和应用美感。要注意，这些指南适用于各种Web应用，不只是CSS方面，只是对于我们前端开发人员来说，最主要直接方便能对这些指南细节进行设置和调整的莫过于CSS了。
另外，还可以利用Javascript内置的API来实现各种无障碍功能，这点下文有说明。除此之外，还有其他JavaScript无障碍问题，比如尽可能让所有交互元素都可以用键盘进行访问以执行某些复杂的功能，而不仅限于鼠标等等。
以在安卓和Windows环境下使用屏幕阅读器为例，先看一个简单的：
再来看一个复杂点的：
虽然在上面的中屏幕阅读器读出了我们想要的内容，但是不代表着这样就成功了，比如在上面的第一个，用Lighthouse测试时，无障碍部分只有96分，扣的4分在于ARIAprogressbarelementsdonothaveaccessiblenames，表示元素没有可访问名称。需要使用aria-label/aria-labelledby属性提供可访问名称。没有设置aria-label/aria-labelledby属性，可能会导致使用屏幕阅读器等辅助技术的用户无法理解它的用途。
另外Lighthouse也有浏览器插件版和工具包版。
Axe-core是网站和其他基于HTML的用户界面的无障碍测试引擎。支持多种平台和环境并且可以与测试框架结合使用。
使用方式（以上面第一个为例）：
所以在测试的时候要考虑全面，设身处地将自己带入到各种人群中，思考他们会怎么使用你写的应用程序。
无障碍功能树（AccessibilityTree）是一个虚拟的树形结构，是一种将Web内容和应用程序中的无障碍功能组织和描述的方法。反映了Web页面中的无障碍信息，并且可以被辅助技术使用。无障碍功能树通常由浏览器自动生成，与DOM树类似，但DOM树只反映了文档的结构和内容；而无障碍功能树还包含许多其他属性，例如元素的角色、状态、名称和值等。
这部分主要介绍两个与屏幕阅读器有点类似的API。但要强调一下与我们平时的方式方法没什么不同，我们可以使用常见的方式方法结合WCAG和WAI-ARIA规范实现无障碍访问，比如一样可以用setAttribute()方法设置role和aria-*属性。只不过学习了Web无障碍了之后，要考虑的东西可能会变得比平时更多。
注意：在使用这些API时要考虑兼容性！
WebSpeechAPI能够将语音数据合并到Web应用程序中。包含两个组件：SpeechRecognition（语音识别，即语音→文本）和SpeechSynthesis（语音合成，即文本→语音）。
AudioAPI（音频API）各位读者应该很熟了，它是一组用于处理音频的JavaScript接口。允许开发人员创建和控制音频流，包括音频的生成、处理和播放。
AudioAPI也能做到类似屏幕阅读器的功能，比如在用户鼠标悬停、键盘聚焦、移动端触摸等等时机创建一个Audio实例，并将准备好的音频赋值给实例的src属性，接着播放即可。这种也是某个政府网站的屏幕朗读的实现方式的一部分，不过我忘记是哪个网站了。
作为一名程序员，Web无障碍是一个非常重要的话题，学习Web无障碍也是一个非常有意义的过程。它可以帮助我们建立一个更加包容和平等的互联网。通过实现Web无障碍，我们可以让更多的人都能够享受到互联网带来的便利和乐趣，无论他们是否有不同的障碍。同时，这也是一个让我们更好地理解和尊重不同人群需求的机会。