HTML5拖拽API需结合语义化结构、键盘支持、ARIA属性和焦点管理才能满足WCAG标准；仅draggable="true"和原生drag事件无法支持屏幕阅读器、键盘或运动障碍用户。
HTML5 拖拽 API 本身不具备可访问性保障，必须配合语义化结构、键盘支持、ARIA 属性和焦点管理才能满足 WCAG 标准。仅靠 draggable="true" 和原生 drag 事件，对屏幕阅读器用户、键盘操作者或运动障碍用户是不可用的。
语义化容器与角色声明
拖拽区域应使用具备明确含义的语义标签，例如 <ol> 或 <ul> 表示有序/无序列表，<section role="region"> 标注功能区。避免用纯 <div> 实现排序容器——这会让辅助技术无法识别其目的。
为拖拽项添加 role="option"（若属选择上下文）或 role="listitem"（若在列表中），并确保父容器有对应 role="list" 或 aria-orientation。例如：
<li role="listitem" tabindex="0" aria-grabbed="false">完成文档</li>
<li role="listitem" tabindex="0" aria-grabbed="false">提交代码</li>
</ul>
键盘交互必须替代鼠标拖拽
不能假设用户会或能使用鼠标拖拽。需提供完整键盘方案：
立即学习“前端免费学习笔记（深入）”；
- 按 Tab 进入列表，聚焦首个可拖拽项
- 用 ↑ ↓ 键移动焦点，同时实时更新
aria-grabbed="true"和视觉高亮 - 按 空格 或 Enter “抓取”当前项（设
aria-grabbed="true"，并禁用其他交互） - 继续用 ↑ ↓ 移动到目标位置，按 Enter 确认“放置”；或按 Esc 取消抓取
- 全程保持焦点可见，且视觉反馈与 ARIA 状态同步
ARIA 状态与实时反馈
动态更新关键 ARIA 属性，让屏幕阅读器感知状态变化：
-
aria-grabbed：标识当前是否被“抓取”，仅对已抓取项设为true -
aria-dropeffect（已废弃，不推荐）→ 改用aria-live="polite"区域播报操作结果 - 在页面顶部或操作区旁添加
<div aria-live="polite" aria-atomic="true"></div>，每次排序后写入如“已将‘提交代码’移至第1位” - 拖拽过程中，可通过
aria-describedby关联说明性 ID，提示“按方向键调整位置，Enter 确认”
视觉与行为一致性设计
无障碍不是加补丁，而是统一体验逻辑：
- 所有拖拽手柄（如三横线图标）必须有
aria-label，例如aria-label="拖拽以重排序" - 禁用项需设
aria-disabled="true"并配合tabindex="-1"，防止键盘误入 - 动画不能依赖 mousemove —— 键盘操作时用 FLIP 技术驱动 transform，保证平滑且不打断焦点流
- 滚动容器内自动滚动时，要同步触发
scrollIntoView({ block: 'nearest' })，确保焦点始终可见
