一个假设场景：你做了一个在线清单，用户改完名称，右上角出现两秒“保存成功”。视觉上似乎交代清楚了，但如果用户正在看页面另一端，或用读屏软件操作，这条信息是否被接收到，仍然没有答案。
这篇讨论的是设计方案，不是我的线上实验或用户调研结果。我的建议是：先写清楚每种操作结束后用户需要知道什么，再选 toast、行内文本或弹窗。
先区分三件事
“按钮按下了”“请求发出去了”“数据已经保存”是不同状态。假设编辑的是家庭采购清单，如果界面在请求发出时就显示“已保存”，用户立即关页，界面就给出了尚未证实的承诺。
可以先为这项功能写一份约定：编辑后显示“有未保存修改”；开始提交后显示“正在保存”；收到服务端成功确认后显示“已保存”；明确失败则显示“保存失败，修改仍保留在这里”。如果请求结果暂时无法确认，就说“尚未确认保存结果”，不要擅自替它判定成功或失败。
这里的关键不是多加几个提示，而是让文案与系统实际掌握的信息一致。对自动保存产品，还要规定“已保存”对应哪一版内容：用户继续输入时，上一版请求返回，不能顺手把当前未提交的内容也标为已保存。
一条资料结论：看得见，也应能被程序识别
W3C 对 WCAG 4.1.3 的解释指出：对于不改变上下文的状态消息，应通过角色或属性让辅助技术识别，在不接收焦点的情况下呈现。文档也提醒，过多播报会打扰用户。它并不是要求所有页面变化都新增通知。
据此，我会把“清单已保存”这类普通反馈先设计成不抢焦点的状态区，再结合实际读屏测试调整。错误如果需要用户回到某个字段修正，应把字段、原因和修正入口一起交代；不能只留下一个孤立的红色感叹号。具体采用哪一种语义标记，需要按组件和错误处理流程判断。
给自己一张验收卡
以“编辑清单名称”为例，验收可以直接这样写：
- 焦点停在名称输入框，发起保存后仍能继续输入；普通成功提示不把焦点拉到页面顶部。
- 成功反馈包含对象：“清单名称已保存”，不要只播报一个脱离上下文的“成功”。
- 请求进行中继续编辑，旧请求完成后，最新输入仍显示未保存或保存中。
- 明确失败后，输入内容仍在，用户能找到重试入口；不要要求重新输入整段内容。
- 开启目标平台的读屏软件，走一遍成功、失败、再次编辑；记录听到的具体文案和顺序，而不只检查页面源码有没有属性。
- 快速连续改动时，检查是否出现连续播报。能否合并非紧急状态，需要通过实际操作判断。
这张卡的用途是暴露歧义，不代表通过六项就符合全部无障碍要求。键盘操作、对比度和字段标签等仍是独立问题。
什么时候不用做成通知
如果用户主动打开详情页，新页面本身已经承载了结果，就不一定还要弹一条“打开成功”。如果一项任务包含二十个内部步骤，也不必把每一步都报给用户。先问：用户需要根据这条消息采取行动吗？不告知是否会误以为操作已经完成？
我更愿意保留少量、可验证的承诺。一个普通小工具的信任感，有时来自一句说得准确的“修改还没有保存”。
资料：W3C《Understanding SC 4.1.3: Status Messages》https://www.w3.org/WAI/WCAG21/Understanding/status-messages 。这是标准解释资料，并非今日新闻；查阅日期为 2026-11-05。上述状态约定、假设清单场景与验收卡为本文建议，未经真实用户实验验证。
