把课程的“结课练习”从第八节移到第三节，拖一下似乎就能完成。但用户可能正在用触屏，也可能无法持续按住鼠标；列表很长时，还容易把章节放进错误的位置。拖拽排序设计要先回答的是：用户怎样准确表达目标位置，以及不用拖拽时能否得到相同结果。
下面用一份八节课的课程目录讨论排序。目录只调整同一课程内的先后顺序，不允许改变章节所属课程，也不修改章节内容。这个边界能让移动入口、插入提示和操作结果保持一致。
不依赖拖拽的移动入口还需要配合可见焦点和结果反馈；可以先用WCAG 2.2 设计检查清单核对这些要求，再把它们落实到下面的课程排序流程。
从“移动到哪里”开始，而不是先画拖拽手柄
课程管理员想把“结课练习”放在“练习讲解”之前。他知道相邻章节的名称，不一定记得目标是第几位。因此，这份目录可以同时提供两种表达：短距离直接拖拽，长距离通过“移动到”选择目标章节及其前后位置。
只提供“上移一位”也能完成任务，但从第八节移到第三节需要连续操作五次。对更长的目录，可以保留上移、下移作为快捷动作，再用位置选择器处理跨越多节的移动。不要把同一套复杂面板强加给只有三项的列表，也不要让长目录只能一步一步挪。
先在纸上写出移动结果：“将结课练习放到练习讲解之前”。再决定界面需要哪些控件。这样可以避免一个菜单写“移到第三位”，拖拽线却表示“第三节之后”，两条路径最终产生不同顺序。
手柄说明可以拖动，插入线说明会放在哪里
在每一行左侧放置拖拽手柄，章节标题仍负责打开章节。把两个动作分开，能减少用户想选中文字却开始移动整行的情况。如果整行都可拖动，也要确认行内的链接、复选框和更多菜单不会被拖拽行为抢走。
开始拖动后，保留原位置的空间线索，让用户知道拿起的是哪一节。跟随指针的预览可以突出标题，省略不影响识别的次要信息；目标位置则用横向插入线标示。只给某一行加背景色，容易让人分不清是放到它之前、之后，还是成为它的子级。
Atlassian 的拖放设计指南将可拖动提示、拖动中的反馈和移动后的呈现分开处理。课程目录也可以沿用这种分工，但不必复制其动画时长或视觉样式：手柄回答“能否移动”，插入线回答“将放在哪里”，完成反馈回答“实际放到了哪里”。
在第一节之前、最后一节之后也要留出明确目标。如果目录允许滚动，拖到可视区域边缘时不能突然跳过大量章节；边缘滚动的触发范围与速度需要结合真实设备调整。无论是否使用自动滚动，用户都应能通过移动菜单直接到达屏幕外的位置。
用移动菜单提供真正等价的另一条路
这份课程目录已有“更多”菜单，可以把“上移一位”“下移一位”和“移动到”放进去。选择“移动到”后，面板显示当前章节名称，再提供目标章节与“之前／之后”选项。例如：移动“结课练习”，目标为“练习讲解”，位置为“之前”。确认按钮写“移动章节”，而不是含义模糊的“确定”。
W3C 的 WCAG 2.2 拖动动作说明要求，在相应适用条件下提供不需要拖动的单指针操作方式。仅支持键盘快捷键并不自动满足这一要求；用户还应能通过点击或轻触控件完成同样的移动。该要求与键盘可操作性需要分别检查。
在这个案例里，点击菜单、选择目标、点击移动，就是非拖拽路径。键盘用户也能沿着同一组可见控件操作，无需记忆一套只有说明文档里才出现的组合键。菜单的进入和关闭行为可接着参照键盘焦点顺序设计，本例更关注移动对象和目标是否准确。
目标列表中应排除无意义的选择，例如把章节放到自己之前。已在最上方的章节不能再上移，但用户仍应能理解原因。可以保留带说明的不可用动作，或让位置选项只出现有效目标；不要让点击后什么也不发生。
完成之后，让人知道章节还在什么位置
移动成功后，目录滚动到新位置，保留“结课练习”的可辨认状态，并给出“已移到第3节，位于练习讲解之前”的反馈。位置数字帮助快速核对，相邻名称帮助理解上下文，两者比单独的“操作成功”更有用。
菜单操作结束后，焦点可以回到被移动章节的更多按钮，让用户继续调整。假如页面采用虚拟列表，原行节点可能被重建，研发仍需按章节标识找到新位置，不能只把焦点返回一个已经不存在的元素。设计标注应说清目标对象，而不只写“返回原处”。
Atlassian 的可访问拖放指南强调让用户发起动作、获知结果并继续操作。本例中的移动菜单、结果文本和新位置入口分别承担这三件事。动态通知不应在拖过每一行时反复播报，优先说明最终结果，以及用户必须处理的异常。
轻微的选中描边可以帮助定位，不必依赖一段大幅飞行动画。若用户启用了减弱动效，章节仍应到达新位置，结果文字与焦点不应一起消失。
过滤后的目录，不一定适合直接重排
如果课程目录还提供搜索或按名称排序，要先决定这些视图是否允许手动移动。按名称排列的结果与课程实际顺序不是一回事，在这个视图里拖动章节，可能刚放下就被排序规则移回原处。可以提示用户先切回“课程顺序”，再开放排序入口，而不是让拖动产生一个看不见的结果。
搜索只显示部分章节时，“放到这两节之间”还可能夹着几节被隐藏的内容。对本例，可以在移动时展示完整目录，并标出原来搜索到的章节，让用户确认真实相邻关系。若必须在过滤结果中移动，则需要在确认位置时补上完整目录中的前后章节，不能仅按当前屏幕的行号保存。这里处理的是章节位置，不是对搜索结果进行批量选择。
同一课程被同时编辑时，顺序不能只看本地画面
用户移动章节的同时，另一位编辑可能已经删除目标章节，或调整了整个目录。此时原来的“第三位”可能不再指向同一个位置。排序请求中如何标识章节和相对位置由研发实现，但界面需要预先定义结果发生变化后的处理。
对于这份课程目录，可以选择先在本地显示新顺序，并在列表顶部提示“正在保存排序”。只有得到保存结果后才改为“排序已保存”。若失败，用户需要看见当前显示的是待保存顺序还是已恢复的旧顺序，不能在列表悄悄回跳后只弹一个短暂错误。
一种便于理解的处理是恢复服务端确认的顺序，标出“排序未保存，请重试”，同时保留本次移动的章节和目标说明。另一种是保留待保存顺序，让用户主动重试或放弃。二者各有适用场景，课程编辑团队应选定一种，不要不同入口采用相反规则。
若目标章节已不存在，原样重试没有意义。可以显示“练习讲解已被移除，请重新选择位置”，重新打开位置面板，并保留“结课练习”作为移动对象。不要自动找一个相似名称的章节代替。单次请求如何反馈，可结合按钮操作反馈继续细化。
在 Pixso 中把两条路径放在同一份目录旁
打开 Pixso 原型设计，先用文字、图形和组件画出八节课程目录，保持章节名称与顺序固定。复制出“拖动到第三节之前”“移动菜单选择目标”“完成后定位”和“保存失败”几张画板，用原型连接点击路径；在拖动状态旁直接标注插入线对应的章节关系。
评审时不要只问“这个动画顺不顺”，而是让参与者完成一个具体任务：把结课练习移到练习讲解之前，再将其移回原位。观察他能否识别拖动对象，能否找到不用拖动的入口，以及完成后能否说明保存状态。将发现的问题评论在对应控件旁，后续修改就有明确位置。
最后给目录加入三种压力场景：目标在屏幕外、章节名称很长、目标在操作期间被删除。它们分别检验移动方式、目标识别和异常恢复。课程目录的视觉可以很轻，但移动对象、目标位置和保存结果必须始终说得清楚。
