一项能力能否长期维护，不取决于演示是否成功，而取决于团队能否解释每个状态、每次重试和每一份残留数据。 拖放区若只是 div 加 click，键盘用户无法触发或理解。使用原生 file input 与 label，拖放只是增强，所有动作保留可聚焦按钮。
无障碍不是发布前补一组 aria 属性，而是让键盘、屏幕阅读器、缩放、减弱动态和高对比度用户完成同一任务闭环，并在错误后找得到下一步。
设计时必须回答的问题
实现之前先列出不可违反的不变量，再为性能与体验留出调节参数。参数可以灰度，身份、权限和终态规则不能在运行时随意漂移。
- 任务行使用真实按钮和描述关联，新增任务不抢焦点；取消后焦点回到稳定任务标题或列表容器，快捷键不覆盖系统行为。
- 把协议事实、用户意图和自动恢复分层；自动化只能恢复事实，不能推翻用户明确选择。
- 上线参数必须有保守默认值、服务端上限和灰度开关，不能把浏览器传来的数字直接当作资源预算。
“只用键盘完成文件传输：选择、确认、进度和取消的闭环”的交付标准是正常路径可用、异常路径收敛、资源有界，并且用户能理解系统为何采用当前状态。 这样得到的不是演示代码，而是能解释、能降级、能回滚的生产能力。
边界情况不是附加项
失败路径需要与成功路径共享同一套状态模型。只弹一个错误提示却不释放资源、不传播终态，下一次恢复就会继承脏状态。
- 文件 input display:none 可能失去辅助技术可达性；列表更新重建 DOM 会把键盘焦点丢回 body。
- 只修正界面状态而没有清理底层资源，下一次操作继承队列、锁或过期凭据并再次失败。
- 只在理想数据量下测试，真实的大文件、长会话或高并发会越过隐含上限并产生级联故障。
用证据确认它真的可用
测试不能以“最后成功了”结束。还要测量经历了多少次副作用、等待多久、是否泄露内容，以及失败后再次执行能否从干净基线开始。
- 不使用鼠标完成单文件、多文件、拒绝、暂停、取消和重试，在任务插入删除期间焦点与读出上下文保持正确。
- 让刷新、取消、超时和远端完成在同一调度窗口发生，断言系统只产生一个终态和一次副作用。
- 发布前记录成功率、p50/p95/p99 延迟、错误分类和资源高水位，并为回退条件设定明确阈值。
当实现能够安全降级、重复执行不产生额外副作用、故障指标早于投诉出现时，这项能力才算具备长期维护价值。