语义化html是无障碍访问的基础，应使用正确的html标签表达内容含义，如用
HTML无障碍访问的核心在于构建语义化的网页结构，让辅助技术（如屏幕阅读器）能够理解内容并有效传达给用户。ARIA（Accessible Rich Internet Applications）角色则是在原生HTML语义不足以表达复杂交互或组件状态时，作为一种补充，为这些元素提供额外的语义信息。
解决方案
要让HTML实现无障碍访问，首先要从基础做起，也就是编写语义化的HTML。这意味着使用正确的HTML标签来表达内容的含义，而不是仅仅为了视觉效果。比如，用
<button>而不是
<div>来创建按钮，用
<h1>到
<h6>来表示标题层级，用
<nav>来包裹导航链接，
<main>来表示页面主要内容。这样做的原因很简单：辅助技术会根据这些标签来构建一个“可访问性树”，让用户知道页面上有什么，以及如何与它互动。
接着是键盘可访问性，这是很多开发者容易忽略的一点。所有可交互的元素，比如链接、按钮、表单控件，都必须能通过键盘（Tab键、Enter键、空格键等）进行操作。如果自定义了组件，确保它们能获得焦点，并且能响应键盘事件。这通常涉及到
tabindex属性的使用，但要谨慎，
tabindex="0"可以使非交互元素可聚焦，而
tabindex="-1"则可以使元素通过脚本聚焦但不参与Tab顺序。
立即学习“前端免费学习笔记（深入）”；
内容的可理解性也至关重要。图片要有
alt属性提供描述性文本，链接文本要清晰明确地指出链接目标，避免“点击这里”这种模糊的表述。表单输入框要有
<label>与之关联，让屏幕阅读器用户知道每个输入框是做什么用的。色彩对比度也要足够高，确保有视觉障碍的用户也能看清内容。
当原生HTML标签无法完全表达组件的复杂行为或状态时，ARIA就派上用场了。ARIA提供了一套角色（roles）、属性（properties）和状态（states），它们不改变元素的视觉表现，但能为辅助技术提供更丰富的语义信息。例如，一个自定义的滑动条，虽然视觉上是滑动的，但屏幕阅读器可能不知道它是一个控制数值的组件。这时，可以给它添加
role="slider"，并用
aria-valuenow、
aria-valuemin、
aria-valuemax等属性来描述其当前值、最小值和最大值。
除了ARIA，还有哪些基本的HTML无障碍实践？
谈到无障碍访问，ARIA确实是个强大的工具，但它绝不是万能药，更不是替代品。我个人觉得，很多时候我们过于强调ARIA，反而忽略了最根本、最基础的HTML实践。其实，在考虑ARIA之前，我们应该先问自己：我有没有用对HTML标签？
最核心的无障碍实践，首先是语义化HTML。这听起来可能有点老生常谈，但真的太重要了。用
<a>标签做链接，用
<button>做按钮，用
<h1>到
<h6>来组织页面结构，用
<nav>、
<main>、
<aside>、
<footer>这些HTML5语义化标签来划分区域。这不仅仅是为了搜索引擎优化，更是为了辅助技术能正确解析页面结构。屏幕阅读器用户可以通过标题快速浏览页面内容，通过地标区域（如
nav、
main）快速跳转到感兴趣的部分。如果所有内容都是
<div>，那辅助技术就无从下手，用户体验会非常糟糕。
其次是键盘可访问性。这是我看到很多前端项目里经常被忽略的一点。一个网站或应用，如果不能仅通过键盘操作，那它在无障碍方面就基本是失败的。这意味着所有可交互元素都必须能通过Tab键聚焦，并且能通过Enter键或空格键激活。如果你用了自定义的JavaScript组件，比如一个自定义的下拉菜单，你必须确保它能接收焦点，并且能响应键盘事件（比如方向键选择选项，Enter键确认）。
tabindex属性在这里很重要，但要小心使用，
tabindex="0"让元素可聚焦并加入Tab顺序，
tabindex="-1"让元素可通过脚本聚焦但不在Tab顺序中，而
tabindex大于0则应尽量避免，因为它会打乱自然Tab顺序。
再来是提供替代文本。图片如果承载了信息，必须提供
alt属性的描述性文本，让屏幕阅读器知道图片内容。如果是装饰性图片，
alt=""空字符串表示辅助技术可以忽略它。视频和音频内容要提供字幕或文字转录。链接文本要清晰明了，避免“点击这里”或“更多”这种模棱两可的表述，因为屏幕阅读器用户可能会跳过上下文，只听链接文本。
最后是清晰的视觉设计。这包括足够的色彩对比度（WCAG 2.1 AA级标准要求文本与背景的对比度至少为4.5:1），以及可调整的字体大小。如果用户需要放大页面，布局不能乱掉。这些看似是视觉层面的东西，但它们直接影响到有视觉障碍或认知障碍的用户能否有效获取信息。
ARIA角色、属性和状态：它们各自扮演什么角色？
ARIA是W3C制定的一套标准，它为HTML元素提供了额外的语义信息，尤其是在原生HTML不足以描述复杂UI组件的交互和状态时。我们可以把ARIA理解为给HTML元素贴上“标签”，告诉辅助技术它们“是什么”以及“在做什么”。
ARIA角色（Roles）：角色定义了一个UI元素的类型。它告诉辅助技术这个元素的功能是什么。比如，一个自定义的标签页组件，虽然可能用
div和
span构建，但我们可以给它的标签页列表添加
role="tablist"，给每个标签页添加
role="tab"，给对应的面板添加
role="tabpanel"。这样，屏幕阅读器就知道这是一个标签页组件，用户可以通过特定的快捷键（比如方向键）在标签页之间切换。常见的角色有
button、
checkbox、
radio、
dialog、
menu、
navigation、
alert等。选择角色时，有一个核心原则是“尽可能使用原生HTML语义”。如果HTML本身有对应的语义标签，就优先使用它，比如按钮就用
<button>，而不是
<div>加
role="button"。
ARIA属性（Properties）：属性描述了UI元素的特征或关系。它们提供了关于元素如何运作、与其他元素关联的信息。属性通常是静态的，或者不经常变化的。例如，
aria-labelledby和
aria-describedby可以用来将一个元素（比如输入框）与页面上其他地方的文本（比如描述或错误信息）关联起来，即使这些文本不在输入框的直接子元素中。
aria-label则可以在没有可见标签的情况下，为元素提供一个可访问的名称。
aria-haspopup可以指示一个元素是否会触发一个弹出窗口（如菜单或对话框）。这些属性帮助辅助技术构建更完整的上下文。
ARIA状态（States）：状态描述了UI元素的当前条件或交互状态。它们通常是动态的，会随着用户交互或程序逻辑而改变。例如，
aria-expanded指示一个可折叠的区域当前是展开还是折叠的；
aria-checked用于复选框或单选按钮，指示它们是否被选中；
aria-disabled指示一个元素是否被禁用；
aria-hidden则可以隐藏一个元素，使其不被辅助技术发现。当这些状态改变时，开发者需要通过JavaScript动态更新对应的ARIA属性值，以便辅助技术能够实时感知到这些变化。
简单来说，角色定义了“我是谁”，属性描述了“我有什么特征”，状态则说明了“我目前处于什么情况”。三者结合，为复杂的Web应用提供了丰富的语义层，使得辅助技术能够更好地解释和呈现内容。
在实际开发中，何时以及如何正确使用ARIA？
在实际开发中，使用ARIA的原则是“少即是多”和“能用原生就用原生”。这不仅仅是个人偏好，而是WCAG（Web内容无障碍指南）的明确建议。我见过太多项目，为了“无障碍”而滥用ARIA，结果反而制造了新的障碍。
何时使用ARIA？
- 当原生HTML语义不足以表达时：这是ARIA最主要的用武之地。比如，你创建了一个自定义的复杂组件，像一个拖放界面、一个树形视图、一个可折叠的面板，或者一个进度条。这些在HTML中没有直接对应的语义标签，这时就需要ARIA来补充。
-
当需要改变或增强现有HTML元素的默认语义时：虽然不常见，但有时你可能需要覆盖或细化一个HTML元素的默认语义。例如，一个
<div>
被用作按钮，你可能需要给它role="button"
，并确保它能通过键盘操作。但请注意，这通常被视为一种“代码异味”，应该优先重构为使用原生<button>
。 -
当需要为辅助技术提供额外信息时：比如，一个输入框旁边有一个错误提示，虽然视觉上能看到，但屏幕阅读器可能不知道它们是关联的。这时可以用
aria-describedby
将输入框和错误提示关联起来。
如何正确使用ARIA？
-
优先使用语义化的HTML：这是最重要的原则。能用
<button>
就不要用<div>
加role="button"
。能用<h1>
就不要用<span>
加role="heading"
。语义化的HTML本身就自带很多无障碍特性，而且浏览器和辅助技术对它们的支持度是最好的。 - 遵循ARIA设计模式（Design Patterns）：W3C提供了许多关于常见UI组件的ARIA设计模式，比如标签页、模态框、菜单、折叠面板等。这些模式详细说明了如何使用ARIA角色、属性和状态，以及如何处理键盘交互。遵循这些模式可以大大减少犯错的可能性，并确保组件在不同辅助技术下的兼容性。
-
动态更新ARIA状态：ARIA属性和状态（如
aria-expanded
、aria-hidden
、aria-disabled
）通常是动态变化的。当组件状态改变时，你必须通过JavaScript实时更新这些ARIA属性的值。例如，当一个折叠面板展开时，其触发按钮的aria-expanded
属性应该从false
变为true
。 -
不要过度使用或滥用ARIA：给每个
div
都加上role="presentation"
或者role="none"
，或者给所有元素都加上aria-label
，这都是没有必要的，甚至可能产生负面效果。role="presentation"
和role="none"
通常只在需要从可访问性树中移除元素的语义时使用，比如在复杂的表格布局中，某个div
只是为了布局目的，没有实际语义。 - 进行充分的测试：使用屏幕阅读器（如NVDA、JAWS、VoiceOver）进行实际测试是必不可少的。不同辅助技术对ARIA的支持程度和解释方式可能略有差异。通过真实的测试，你可以发现仅仅通过代码审查无法发现的问题。
记住，ARIA是增强剂，不是替代品。它的目的是弥补原生HTML的不足，而不是取代它。当你发现自己为了实现某个UI而不得不大量使用
div和
span时，那往往就是考虑ARIA，并参考其设计模式的时候了。但如果一个简单的按钮，你还想着怎么用ARIA去“增强”它，那多半是走错了方向。
