键盘能操作不代表已经满足 Dragging Movements。WCAG 2.2 2.5.7 关注指针用户：如果功能必须按住并移动，通常还要提供点击/轻触等无需拖动的等价方式。
拖拽是现代 UI 非常常见的交互：看板移动卡片、表格调整顺序、滑块改价格、地图拖动、上传文件、设计工具移动图层。对手抖、精细运动控制困难、使用头控/眼控/触控笔等用户，按住并持续移动可能非常困难。WCAG 2.2 的 2.5.7 Dragging Movements 正是为此新增。
01 最重要的判断是：拖拽可以保留，但不能是唯一操作方法
除非拖拽本身就是功能本质，凡是依赖拖拽完成的功能，都应提供无需拖动、仅通过单指针点击/轻触即可完成的等价方式。
02 一、键盘替代并不自动满足 2.5.7
键盘可访问当然仍然重要，但这条标准专门关注指针输入。W3C 的 Understanding 文档明确说明：应有 single-pointer alternative。也就是说“我们支持方向键移动，所以没问题”可能仍不足以覆盖无法拖动但能点击的指针用户。
03 二、看板/列表排序：提供“移动到...”菜单
卡片可以继续拖动，但也提供更多菜单：上移、下移、移到顶部、移动到某列。用户点击一次打开菜单，再点击目标即可完成同样任务。W3C 技术示例也把上下移动菜单作为典型替代。
04 三、滑块：同时提供数字输入或 +/- 控件
价格范围、音量、透明度等滑块如果需要精准拖动，可以提供文本/数字输入框或加减按钮。这样也方便需要准确数值的人，而不是只服务无障碍。
05 四、文件上传：Drag & Drop 旁边必须有“选择文件”
拖文件到上传区很方便，但标准文件选择按钮同样应该存在，并有可见标签。上传区不要只写“拖到这里”，也不要隐藏按钮到只有键盘用户才看得见。
06 五、地图/画布：提供控制按钮或属性编辑
平移地图可以有方向/缩放按钮；设计工具移动对象可以提供 X/Y 属性输入；颜色选择器可以有数值输入。只要最终功能等价，就不必强迫用户走同一种操作路径。
07 六、什么叫“拖拽是本质必要”？
例外应该非常窄。例如某些绘画或笔迹任务，拖动轨迹本身构成功能。如果只是“开发这样实现最方便”，不算 essential。排序、调整数值、上传等任务通常都有合理替代。
08 七、替代操作必须真正可发现
把“上移”功能藏在只有长按才能出现的菜单，仍可能造成障碍。按钮/菜单要能通过常规点击访问，命名清楚，焦点顺序合理，并在操作后提供状态反馈，例如“已移动到第 3 位”。
09 拖拽功能验收方法
- 列出产品里所有需要按下→移动→释放的动作。
- 关闭拖拽能力，检查是否仍能用普通点击/轻触完成相同结果。
- 再检查键盘、读屏和焦点顺序。
- 测试替代方式是否同样能完成全部目标位置/数值。
- 操作后提供可感知结果和撤销能力。
10 最后：无障碍替代往往也会让主流用户受益
在触控板不好用、手机空间狭小、手持设备晃动时，拖拽同样容易失败。一个清晰的“移动到”“选择文件”或数值输入，不只是合规补丁，而是给所有用户多一条可靠路径。
11 八、移动端最容易暴露拖拽替代缺失
桌面鼠标拖动很轻松，手机上手指遮挡、屏幕小、滚动冲突会放大问题。看板、轮播排序、图片裁剪等应在触控真机测试，不要只在桌面浏览器模拟。替代按钮在小屏也必须可见，不应被塞进难以发现的手势。
12 九、拖拽完成后提供撤销，降低误操作成本
即使用户能够拖动，也可能误放。Toast 中提供“撤销”、显示新位置或在批量排序后允许确认，可以同时改善运动障碍和所有用户体验。无障碍不仅是能操作，还包括操作结果可理解、可恢复。
13 十、不要用“点击某处自动完成拖拽”制造新的猜测
替代操作要明确可发现。例如排序卡片提供“移动”按钮并打开目标列表，比让用户“点一下卡片再点目标位置”更容易理解。无障碍替代不只是技术上可完成，还要让用户知道这个路径存在。
对于频繁排序的专业工具，可以提供快捷键，但快捷键应作为额外效率功能，不能取代单指针替代。
常见问题
Drag & Drop 功能必须删除吗？
不需要，可以保留，只要同时提供无需拖动的等价单指针方式。
支持键盘就满足 WCAG 2.5.7 吗？
不一定。这条标准要求单指针无需拖拽的替代，键盘属于另一输入方式。
滑块必须改成输入框吗？
不必替换，可以同时保留滑块和数值输入/加减控件。
拖拽上传算 2.5.7 场景吗？
是常见场景，提供标准“选择文件”点击入口即可形成等价路径。
什么情况下拖拽可以没有替代？
只有拖拽动作本身对功能本质必要，或由用户代理/辅助技术决定等例外情况。
相关服务与进一步咨询
链接复制成功
