语音网页验收：关闭弹窗后还能找到播报控制吗

设想采购一套语音服务网页：页面进入时出现一个弹窗，弹窗里有声音控制，关闭弹窗以后声音却仍在继续。验收者需要知道接下来如何控制它，而不只是确认初始画面上曾有一个按钮。本文用这个虚构界面讨论观察路径，没有实际测试任何网站，也不描述机器人硬件能力。

先记清声音如何开始，再讨论控制入口

建议验收人员把进入页面、声音开始和关闭弹窗分别记录。这样可以区分声音是否由使用者主动触发，以及关闭动作之后页面处于什么状态。不要为了套用某条准则，事后把主动播放改写成自动播放；也不要把操作系统静音当成网页自己的控制能力。

在当前W3C音频控制说明中，自动播放超过三秒的网页音频应有暂停、停止或独立于系统音量的控制机制。这里概述的是该成功准则的有限范围，不表示本文已经判断虚构网页满足整套WCAG，也不把准则扩大成所有声音都必须采用相同按钮。

在这个假设界面里，接收人员可以提出一条明确观察任务：弹窗关闭且声音仍继续时，约定使用者如何找到控制机制？若必须重新打开弹窗，应让供方说明可发现的入口；若另有页面控制，应核对它实际影响的是哪段声音。本文不预设唯一设计，也不要求某个平台具有尚未约定的功能。

图一展示的是入口变化后的审阅顺序。不要在复查时直接跳回最初画面，忽略原问题发生在弹窗已经关闭的状态。若无法定位下一步，可以如实记录停点，请供方补充路径说明，而不是由测试者凭对产品的熟悉替使用者猜操作。

W3C键盘操作说明关注通过键盘接口操作功能，并保留本质依赖移动路径的输入例外。对本例的普通声音控制，可以按真实约定核对键盘操作路径；这并不是说每个可见按钮在所有实现中都必须采用一种固定焦点方案。

建议分别记录控制入口能否被找到、功能怎样被触发，以及触发后的实际声音状态。看见一个暂停图标，与观察到声音真的暂停，是两个不同信息。若本次只完成界面走查，就准确写出观察范围，不填一项没有进行的听取或操作结果。

继续假设情境，若页面还可能出现另一项播报，接收者需要询问当前控制影响哪一项，以及其他声音的控制如何呈现。这是新增的提问分支，不声称某个真实系统同时播放多个来源。无论设计采用单独控制还是其他约定机制，验收记录都应对应实际可观察的行为。

图二将控制入口与结果状态并列。入口明确但效果未核对时，保留后一项待观察；声音停止但不知道触发原因时，也不急于将其记成按钮测试通过。这样的区分避免用一个看起来合理的界面替代操作证据。

建议问题记录包括关闭弹窗后的页面状态、希望执行的声音控制动作，以及当时停在哪一步。修订后应从同一状态重新核对，而不是只展示新图标。本文提出的是局部界面验收建议，不能据一条路径宣布整个网页无障碍合规或语音识别表现优秀。

其他交互资料见本站语音网页技术文章，更多独立话题可由文章目录查阅。本例没有采集用户声音，也没有任何真实准确率、访问量或用户测试数据。