当我开始学习ARIA时，希望有人告诉我的事

可访问富互联网应用程序（ARIA）是处理Web可访问性时不可避免的技术。如果你从未接触过ARIA，这是个学习新知识的好机会；如果已有了解，本文可能帮助你更深入理解甚至学到新内容！

这些是我开始Web可访问性之旅时希望有人告知的内容。本文将：

• 提供理解ARIA概念的心态
• 破除常见误解
• 提供指导思路以更好地理解和使用ARIA

希望通过这些内容，让这个常被忽视但至关重要的Web设计和开发领域更易入门。

本文不涉及的内容

这不是使用ARIA构建可访问网站和Web应用的配方书，也不是修复不可访问体验的指南。许多可访问性工作高度依赖上下文，因不了解具体项目需求，提供建议可能弊大于利。

请将本文视为"行前须知"指南，旨在提供处理ARIA的良好心态，并指出需要注意的事项。

那么，什么是ARIA？

ARIA是在没有更适合的原生HTML元素或属性时，用于传达交互性、目的和状态的解决方案。

将其视为洒在标记中的调味料，用于增强内容。向HTML标记添加ARIA是为屏幕阅读器和语音控制软件提供额外信息的方式。

• 交互性：内容可被激活或操作，例如导航到链接目标
• 目的：某物的用途，例如用于收集姓名的文本输入框
• 状态：内容当前的状态，由状态、属性和值控制，例如可展开或折叠的手风琴面板

HTML按钮元素的存在会指示辅助技术将其报告为按钮，让人知道它可以激活以执行预定义操作。“静音"文本字符串会被辅助技术报告，提示按钮的用途。aria-pressed="true"表示某人或某物先前已激活按钮，现在处于"按下"状态以维持其操作。

ARIA的历史

ARIA已存在很长时间，第一版于2006年9月26日发布。ARIA的创建是为了在HTML的局限性与使辅助技术理解交互体验的需求之间架起桥梁。

最新版本是2023年6月6日发布的1.2版，1.3版即将发布。你可能也看到它被称为WAI-ARIA，其中WAI代表"Web可访问性倡议”。

ARIA的精神反映了其创建时代

原因很简单：过去的网络远不如现在成熟。2006年最流行的操作系统是Windows XP，iPhone尚未存在（一年后才发布）。从高层次看，ARIA是这个时期操作系统交互范式的快照，因为它重现了这些范式。

心态

具有可点击、可滑动和可拖动表面的智能手机远不那么普遍。单页应用程序"Web应用"体验也很罕见，基于Ajax的方法最流行。这意味着我们必须使用2006年的技术构建今天的体验。在某种程度上，这是好事，它迫使我们审视新的创新体验。

无法分解为更小、更专注且映射到ARIA模式的交互很可能不可访问，因为它们无法由辅助技术操作或在较旧或较不流行的设备上运行。

交互期望

当代对基于键盘的Web内容交互的期望（复选框、单选按钮、模态框、手风琴等）源自Windows XP及其前身操作系统。这些交互模型作为使用辅助技术的老年人的肌肉记忆延续下来，依赖辅助技术的年轻人也学习这些事实标准，从而延续循环。

这意味着使用键盘与网站或Web应用交互的人很可能会先尝试这些基于Windows操作系统的键盘快捷键，例如按Enter导航到链接目标、按Space激活按钮、按Home和End跳转到项目列表的开头或结尾等。

它也是活文档

这并不是说ARIA停滞不前。它不断被改进，有新增、删除和澄清。记住，它现在处于1.2版，1.3版即将到来。

并行地，HTML作为语言也反映了这种演变。元素最初是为支持面向文档的Web而创建，并逐渐演变为支持更动态、类似应用的体验。好处是这一切都是公开进行的，如果你有动力，可以参与贡献。

ARIA有使用规则

ARIA文档中包含五条规则来指导你如何处理它：

1. 尽可能使用原生元素
2. 尽可能不调整原生元素的语义
3. 任何交互都必须可通过键盘操作
4. 不要在可聚焦元素上使用role="presentation"或aria-hidden="true"
5. 交互元素必须被命名

遵守这五条规则将大有帮助。以下是提供更多支持的背景信息。

ARIA有分类法

ARIA有结构化的语法，以角色以及状态和属性为中心。

角色

角色是辅助技术读取并宣布的内容。许多人简称为语义。HTML元素具有隐含角色，这就是为什么锚元素会被屏幕阅读器宣布为链接而无需额外工作。

如果用例需要，隐含角色几乎总是更好使用。回想ARIA的第一条规则。这通常是数字可访问性从业者所说的"只需使用语义HTML"。

角色有类别，每个都有其目的。抽象角色类别值得注意，因为它是一个组织超类别，不打算由作者使用。

状态和属性

状态和属性是ARIA整体分类法的另外两个主要部分。

隐含角色由语义HTML提供，显式角色由ARIA提供。两者都描述元素是什么。状态以辅助技术可以理解的方式描述该元素的特征，这是通过属性声明及其伴随值完成的。

ARIA状态可以快速或缓慢地改变，无论是由于人为交互还是应用程序状态。当状态因人为交互而改变时，它被认为是"非托管状态"，开发人员必须提供底层JavaScript逻辑来控制交互。当状态因应用程序（例如操作系统、Web浏览器等）而改变时，这被认为是"托管状态"，应用程序自动提供底层逻辑。

如何声明ARIA

将ARIA视为HTML属性的扩展，一套名称/值对。有些值是预定义的，而其他值是作者提供的：

声明ARIA与声明其他HTML属性的方式相同。其他使用说明：

• 可以在HTML元素上放置多个ARIA声明
• ARIA在HTML元素上声明的顺序无关紧要
• 对元素可以放置的ARIA声明数量没有限制
• 可以在HTML元素上声明ARIA并同时具有其他非ARIA声明

不是很多ARIA是"硬编码的"

在此上下文中，“硬编码"意味着直接将静态属性或值声明写入组件、视图或页面。

许多ARIA设计为基于应用程序状态或响应用户操作动态应用或条件修改。

在已隐含使用该角色的元素上声明ARIA角色不会使其"额外"可访问

如果使用语义HTML，隐含角色就是所需全部。通过ARIA显式声明其角色不会带来任何额外优势。

注意：此指导有一个例外。在某些情况下，某些复杂标记模式无法按预期用于辅助技术。在这些情况下，我们希望将隐式角色硬编码为显式ARIA以确保其工作。

不需要说明控件是什么；那是角色的作用

隐式和显式角色都由屏幕阅读器宣布。不需要为交互元素的文本字符串或aria-label包含该部分。

ARIA角色有非常具体的含义

我们有时 colloquially 将网站和Web应用导航称为菜单，尤其是电子商务风格的巨型菜单。

在ARIA中，菜单有非常具体的含义。不要考虑全局或页面内导航等。在此上下文中，将菜单视为单击应用程序菜单栏上的编辑菜单按钮时出现的内容。

因为名称乍看起来合适而错误使用角色会给没有视觉UI上下文的人造成混淆。

某些角色禁止具有可访问名称

这些角色是caption、code、deletion、emphasis、generic、insertion、paragraph、presentation、strong、subscript和superscript。

这意味着你可以尝试为这些元素之一提供可访问名称（例如通过aria-label），但它不会起作用，因为它被ARIA语法规则禁止。

不能编造ARIA并期望它工作

有些开发人员猜测添加CSS类（如.background-red或.text-white）到他们的标记中，如果设计视觉上更新正确，就会得到奖励。

这起作用的原因是有人先前将这些类添加到项目中。对于ARIA，添加我们可以使用的内容的人是可访问富互联网应用程序工作组。这意味着每个新版本的ARIA都有一套预定义的属性和值。

声明不属于该预定义集的ARIA意味着辅助技术不会知道它是什么，因此不会宣布它。

ARIA静默失败

这涉及到前一部分，ARIA不会理解其有限词汇表之外的单词。

对于格式错误的ARIA没有控制台错误。也没有警报对话框、蜂鸣声或操作系统、浏览器或辅助技术的闪烁灯。这一事实是为什么用实际辅助技术测试如此重要的另一个原因。

ARIA仅向辅助技术暴露某物的存在

向某物应用ARIA不会自动"解锁"功能。它只向辅助技术发送关于交互内容应如何行为的提示。

对于像屏幕阅读器这样的辅助技术，该提示可能是如何宣布某物。对于像可刷新盲文显示器这样的辅助技术，它可能是如何升高和降低其针。

此外，通过ARIA调整元素的角色不会修改元素的本地功能。

在某物上声明ARIA角色将覆盖其语义，但不覆盖其行为

这涉及到前一部分关于ARIA仅暴露某物的存在。不要忘记某些HTML元素具有内置的主要和次要交互功能。

相反的情况也成立。当元素没有功能时，调整其角色不会授予任何新能力。记住，ARIA只宣布。

你需要声明ARIA以使某些交互可访问

之前的许多内容可能使ARIA看起来是你应该完全避免使用的东西。这不是真的。知道此指导是为了帮助引导你到HTML不提供开箱即用描述交互能力的情况。这个空间是你想要使用ARIA的地方。

某些ARIA状态需要某些ARIA角色存在

这类似于HTML同时具有全局属性和只能按元素基础使用的属性。

学习什么状态需要哪些角色可以通过阅读官方参考来实现。检查每个条目特征的"用于角色"部分。

自动化代码扫描器（如axe、WAVE、ARC Toolkit、Pa11y、equal-access等）如果编写错误，可以捕获这类问题。

ARIA不仅仅是Web浏览器

说到监听的技术，知道声明的ARIA指示浏览器与其安装的操作系统对话是有帮助的。辅助技术然后监听操作系统报告的内容，然后将其传达给使用计算机、平板电脑、智能手机等的人。

然后，人可以指示辅助技术请求操作系统对浏览器中显示的Web内容采取行动。

这种交互模型是设计使然。这样做是为了使来自辅助技术的交互与没有辅助技术执行的交互无法区分。

这种方法有几个原因，最重要的是它有助于保护依赖辅助技术的人的隐私和自主权。

仅仅因为它存在于ARIA规范中并不意味着辅助技术会支持它

这个支持问题之前提到过，是一个难以接受的事实。

当代开发人员享受Web标准运动艰苦赢得的 benefits。这意味着你可以声明HTML并知道它将与所有主要浏览器一起工作。ARIA没有这个。每个辅助技术供应商对ARIA规范都有自己的解释。通常，这些解释是收敛的。有时，它们不是。

辅助技术供应商也有其产品的支持路线图。一些辅助技术供应商：

• 最终会添加支持
• 可能永远不会
• 可能会以与其他供应商选择实现方式相矛盾的方式这样做

还有操作系统层需要应对。

有了这些层，就会出现辅助技术可以支持声明的ARIA，但操作系统本身无法传达ARIA的存在，反之亦然。

此外，没有相当于Caniuse、Baseline或Web Platform Status的辅助技术。最接近的支持检查资源类比是a11ysupport.io，但知道它是一个人艰苦的工作。

如何确定ARIA支持

确定某物是否受支持有三个主要层：

1. 操作系统和版本
2. 辅助技术和版本
3. 浏览器和浏览器版本

1. 操作系统和版本

每个操作系统（例如Windows、macOS、Linux）都有自己的方式向辅助技术传达存在什么内容。每个辅助技术都必须适应如何解析该通信。

一些辅助技术与某些操作系统不兼容。此外，每个操作系统的每个版本在报告内容和方式上都有细微变化。

2. 辅助技术和版本

制作辅助技术没有"一种真正的方式”。每个都是为解决不同的访问需求和需求而构建的，并且是以有主见的方式完成的——想想不同的Web浏览器如何具有不同的功能和UI。

每个使用Web内容的辅助技术都有自己的方式传达这些信息，这是设计使然的。它与操作系统报告的内容一起工作，通过启发式和偏好等进行过滤。

像操作系统一样，辅助技术也有不同版本，每个版本能够支持什么。它们也容易受到错误和回归的影响。

另外两个值得指出的因素是升级犹豫和缺乏财务资源。一些依赖辅助技术的人对升级它犹豫不决。这是基于可以理解的恐惧，害怕打破他们用来与世界交互的重要机制。

缺乏财务资源有时被称为残疾税。残疾人群的就业率往往较低，随之而来的是用于获取新技术和更新它的资金减少。

3. 浏览器和浏览器版本

一些辅助技术与一个浏览器相比与另一个浏览器工作得更好。这是由于浏览器如何向辅助技术报告其内容的底层机制。

此外，对此报告的支持有时仅针对较新版本添加。不幸的是，这也意味着支持有时可能意外回归，人们在发布浏览器更新之前没有注意到——再次，这是由于历史缺乏资源和优先级。

声明的ARIA越不常用，越需要测试它

你会遇到的常见ARIA声明包括但不限于：aria-label、aria-labelledby、aria-describedby、aria-hidden、aria-live。

这些更常见是因为它们更受支持。它们更受支持是因为许多这些声明已经存在一段时间了。

更新、更晦涩的ARIA或历史上被优先考虑的声明可能还没有那种支持或可能永远没有。

向某物添加的ARIA越多，某物行为异常的可能性越大

这一事实考虑了偏好、不同支持水平、错误、回归以及伴随ARIA使用的其他问题的复杂性。

从哲学上讲，这很像通过JavaScript向网站或Web应用添加更多交互复杂性。代码覆盖的表面积越大，发生意外情况的机会越大。

考虑添加到组件或体验离散部分的ARIA数量。声明嵌套到文档对象模型（DOM）中的越多，它与父ARIA声明的交互就越多。

许多当代开发工作是孤立的、基于功能的工作，专注于整体体验的一小部分。因此，他们可能不考虑这种整体嵌套情况。

辅助技术可能支持你的无效ARIA声明

有机会不准确编写的ARIA实际上会按预期与辅助技术一起工作。虽然我不建议依靠这一事实来完成工作，但我认为在调试等方面值得提及。

这是由于编写ARIA的人的熟悉程度范围很广。一些更成熟的辅助技术供应商尝试适应这种熟悉度的低端，以便更好地使使用其软件的人真正获得他们需要的东西。

没有每个辅助技术具有的 accommodations 的详尽列表。

aria-label 很棘手

aria-label 是你将遇到的最常见的ARIA声明之一。它也是最常被误用的之一。

aria-label 不能应用于非交互式HTML元素，但经常是。它不能总是被翻译，并且经常被本地化工作 overlook。此外，它可能使使用语音控制软件的人操作起来令人沮丧，其中可见标签与底层代码使用的标签不同。

另一个问题是当它覆盖交互元素的预先存在的可访问名称时。

这些因素——以及其他考虑——是我认为aria-label是代码气味的原因。

aria-live 更棘手

实时区域公告由aria-live提供支持，是向使用屏幕阅读器的人传达体验更新的重要部分。

相信我，即使是在最好的情况下，让aria-live正常工作也很棘手。

ARIA创作实践指南可能误导你

也称为APG，ARIA创作实践指南应谨慎对待。

缺点

该指南最初是为了帮助展示ARIA的功能而编写的。因此，其代码示例几乎 exclusively、overwhelmingly、和 disproportionately 偏爱ARIA。

不幸的是，APG的最新重新设计也使其看起来比其周围的W3C文档更容易接近。这与以信号表明它是可以开箱即用的自服务资源的代码示例的UI模式相结合。

这些因素造成了一种人们假设一切都可以按呈现使用的情况。这不是真的。

回想一下，仅仅因为ARIA列在规范中并不一定保证它受支持。

另外，记住ARIA的第一条规则，知道ARIA优先的方法与规范的核心使用哲学背道而驰。

优点

APG的主要优势是突出显示人们期望在每个模式上工作的键盘按键。

考虑列表框模式。它详细说明了你可能期望的按键（箭头键、Space和Enter），以及不太常见的按键（类型提前选择和进行多个选择）。

APG的另一个优势是给UI模式赋予标准化、集中的名称。是下拉菜单？列表框？组合框？选择菜单？其他东西？

当涉及到数字可访问性时，这些术语都有具体的含义，以及随之而来的期望。

macOS VoiceOver 也可能误导你

macOS上的VoiceOver在过去几年中一直遇到很多问题。如果我作为外人猜测原因，那就是Apple的优先级集中在其他地方。

大部分Web开发工作是在macOS上进行的。这意味着善意的开发人员会选择VoiceOver，因为它与macOS捆绑在一起，因此更方便。

然而，macOS VoiceOver使用在桌面和笔记本电脑中占极少数份额。它不到10%的使用率，而基于Windows的JAWS和NVDA占据了78.2%的合并多数份额。

问题

可悲的事实是，macOS VoiceOver在目前状态下有很多问题。它只应用于确认它可以以基于Windows的屏幕阅读器的方式操作体验。

这意味着在Windows上使用NVDA或JAWS进行测试将创建更准确的体验，与大多数在笔记本电脑或桌面上使用屏幕阅读器的人将体验到的体验更接近。

处理问题

由于这种情况，我强烈鼓励涉及以下内容的工作流程：

• 创建体验的底层标记
• 使用NVDA或JAWS测试它以建立基线期望
• 使用macOS VoiceOver测试它以识别哪些不按预期工作

大多数时候，我发现自己不得不在编写的语义HTML上声明冗余ARIA，以解决macOS VoiceOver遗漏的预期公告。

macOS VoiceOver测试仍然重要，因为使用macOS VoiceOve