在React应用里，用<div>或<span>绑定onClick实现点击交互是很常见的做法，但这些元素默认既无法被键盘聚焦，也不会被屏幕阅读器识别为可操作组件。无障碍开发要求我们显式补充语义信息和键盘行为，让所有用户都能平等地使用产品。本文会围绕ARIA标签和键盘导航展开，给出可直接落地的React实现方案。
理解ARIA标签在React中的正确应用
ARIA全称Accessible Rich Internet Applications，它通过一组属性为辅助技术提供额外的语义描述。在React的JSX中，ARIA属性大多与原生HTML保持一致，例如aria-label、aria-hidden、aria-expanded。但有些属性名称因为与JavaScript保留字冲突而采用了驼峰写法，比如htmlFor对应原生for属性，className对应class属性。写React无障碍代码时，必须熟悉这些差异，否则属性不会生效。
一个典型的错误示范是给<div>元素添加onClick事件，却没有设置role和键盘处理。屏幕阅读器无法知道这个div是一个按钮，键盘用户也无法通过Tab键聚焦到它。正确的做法是使用role="button"和tabIndex={0}，同时监听键盘事件来响应Enter和空格键。下面是一个可访问的自定义图标按钮组件示例。
function AccessibleIconButton({ onClick, label, children }) {
const handleKeyDown = (event) => {
if (event.key === 'Enter' || event.key === ' ') {
event.preventDefault();
onClick();
}
};
return (
<div
role="button"
tabIndex={0}
onClick={onClick}
onKeyDown={handleKeyDown}
aria-label={label}
className="icon-button"
>
{children}
</div>
);
}
这里role="button"告诉辅助技术这个元素扮演按钮角色，tabIndex={0}把它加入页面的Tab顺序，onKeyDown则模拟了原生按钮的键盘行为。需要注意的是，如果样式层面没有强制限制，优先使用原生<button>元素才是更好的选择，因为原生按钮天然具备这些能力。
实现完整的键盘导航与焦点管理
键盘导航的质量高低，取决于焦点顺序是否合理以及焦点是否可见。默认情况下，浏览器按照DOM顺序进行Tab导航，React的条件渲染和动态列表可能会让焦点跳到意料之外的位置。开发者应当避免使用大于0的tabIndex值，因为那会打乱自然顺序，造成混乱。所有可交互元素都应有清晰的焦点样式，绝不能为了美观而移除outline，否则键盘用户会完全迷失位置。
对于模态框、抽屉等覆盖层组件，还需要处理焦点陷阱。焦点陷阱的意思是，当模态框打开时，按Tab键只能在模态框内的可聚焦元素之间循环，不会跑到背景页面上。实现思路是监听容器的keydown事件，判断当前焦点是否为第一个或最后一个可聚焦元素，然后手动将焦点移动到另一端。以下是一个React的焦点陷阱Hook示例。
import { useRef, useEffect } from 'react';
function useFocusTrap(active) {
const containerRef = useRef(null);
useEffect(() => {
if (!active) return;
const container = containerRef.current;
const focusableSelector = 'button, [href], input, select, textarea, [tabindex]:not([tabindex="-1"])';
const focusableElements = container.querySelectorAll(focusableSelector);
const firstElement = focusableElements[0];
const lastElement = focusableElements[focusableElements.length - 1];
const handleKeyDown = (event) => {
if (event.key !== 'Tab') return;
if (event.shiftKey) {
if (document.activeElement === firstElement) {
event.preventDefault();
lastElement.focus();
}
} else {
if (document.activeElement === lastElement) {
event.preventDefault();
firstElement.focus();
}
}
};
container.addEventListener('keydown', handleKeyDown);
return () => container.removeEventListener('keydown', handleKeyDown);
}, [active]);
return containerRef;
}
这个Hook把containerRef绑定到模态框外层容器，在active为true时启动焦点循环。实际使用时，还需要在模态框打开时把焦点移动到第一个可聚焦元素，并在关闭后把焦点恢复到触发它的按钮上。焦点恢复对于屏幕阅读器用户尤其重要，否则关闭弹窗后焦点可能丢失在页面底部，用户需要重新导航。
另一个容易忽略的细节是，动态列表删除或排序后，焦点可能停留在已卸载的节点上。可以通过useEffect检测列表变化，在必要时将焦点转移到安全的容器或邻近元素，避免出现焦点悬空的情况。
表单与动态内容的无障碍支持
表单是用户与系统交互最频繁的区域，无障碍处理不当会直接阻断用户完成核心任务。React中所有的<input>、<select>和<textarea>都应该有关联的<label>。由于JSX中不能使用for属性，需要用htmlFor来指定关联的输入框id。同时，错误提示不能只靠红色文字，还要通过ARIA属性让屏幕阅读器感知，比如使用aria-invalid标记非法输入，使用aria-describedby指向错误提示元素。
import { useState } from 'react';
function NameForm() {
const [name, setName] = useState('');
const [error, setError] = useState('');
const handleSubmit = (event) => {
event.preventDefault();
if (name.trim() === '') {
setError('姓名不能为空');
} else {
setError('');
}
};
return (
<form onSubmit={handleSubmit}>
<label htmlFor="name-input">姓名</label>
<input
id="name-input"
type="text"
value={name}
onChange={(e) => setName(e.target.value)}
aria-invalid={error ? true : false}
aria-describedby="name-error"
/>
{error && <span id="name-error" role="alert">{error}</span>}
<button type="submit">提交</button>
</form>
);
}
在上面的例子中，当姓名输入为空时，提交后会显示错误信息，并且role="alert"会让屏幕阅读器立即播报错误内容。aria-describedby建立了输入框和错误提示之间的关联，辅助技术在用户聚焦输入框时也会读取错误描述。动态内容的更新同样需要ARIA支持，例如加载状态或操作结果通知，应当使用aria-live区域。设置aria-live="polite"会等待当前播报结束后再通知，而aria-live="assertive"会立即打断当前内容，应根据场景选择。
使用aria-live时要注意，该区域必须在初始渲染时就存在于DOM中，后续只更新其文本内容，辅助技术才能捕获变化。如果区域本身是动态插入的，某些屏幕阅读器可能无法识别。此外，不要频繁更新aria-live区域，否则会淹没用户的信息接收。
常见误区与实用的测试方法
在React无障碍开发中，有几个误区反复出现。第一是在<a>标签上使用role="button"，却只绑定了点击事件而没有处理空格键，因为链接默认不响应空格键。第二是给纯文本或图标随意添加role="button"或role="link"，让辅助技术误以为用户可以操作，但实际上没有交互行为。第三是忽略焦点可见性，使用outline: none却没有提供替代的焦点样式。第四是滥用aria-label，例如给已经有可见文本的按钮添加一个不同的标签，导致屏幕阅读器读出的内容与视觉文本不一致。
要避免这些问题，推荐在项目中接入eslint-plugin-jsx-a11y，它能在开发阶段静态检查JSX中的无障碍问题，例如缺少alt属性、可点击元素没有键盘处理、htmlFor错误等。同时，应该使用浏览器开发者工具中的无障碍面板检查可访问性树，确认组件在辅助技术中的角色和名称是否符合预期。手动测试也不可替代，用Tab键完整走一遍页面流程，确认每个可交互元素都能到达、焦点样式清晰、模态框能正确锁定和恢复焦点。
无障碍不是项目收尾时的一次性修补，而应作为React组件设计的默认约束。每当你打算用<div>实现一个按钮、弹窗或列表项时，先问问自己：它是否可聚焦？辅助技术能否理解它的语义？键盘用户能否完成同样的操作？把这些检查融入开发流程，构建出的应用才能真正对所有人开放。