语音网页上的音量滑块向右移动,旁边数字也改变了,是否就能说明所有用户都知道当前音量?交付验收还需要看界面把什么状态提供给辅助技术,以及这些信息如何对应可见表示。这里讨论假设的网页控件,不测量真实声音,不连接扬声设备,也不把一个数字解释成声压结果。
滑块可能表达应用内部设定,而不是设备输出的物理量。接收方应请供方说明它的用途、允许范围,以及数字与可见位置的关系。若页面同时显示“静音”等状态,也需要解释这些提示和滑块值怎样关联,不能仅按视觉位置自行推断。
假设演示页面展示一个音量数字,却没有说明它是百分比、内部刻度还是其他含义,采购记录就应保留这个问题。不要根据常见播放器习惯替供方填写单位,也不要从一个界面截图断言外接设备已经按这个设定播放。界面语义和实际声音属于不同证据。
WAI的滑块设计模式说明了滑块角色、当前值、最小值、最大值等状态关系,并讨论必要时使用更易理解的值文本。本文据此提出资料问题,不把模式示例当成任何真实产品已经通过检查的证明。
交付方应说明页面中可见值与对外提供的当前状态是否来自同一含义。当两种表示不同,应解释差别而不是简单复制数字。若一个内部刻度本身不能让读者理解其含义,就需要审阅相关可读说明;不能为了填满字段而提供一个看似准确却没有上下文的值。

WAI-ARIA 1.2规范对包括aria-valuenow在内的语义属性作出说明。接收方应把这些状态视为需要核对的接口信息,而不只是装饰性文字。一张滑块截图可以帮助定位对象,却不能单独说明程序向辅助技术提供了什么。
若约定包含实际辅助技术演示,应由责任方明确页面版本、浏览器、辅助技术及观察任务,再保留真实结果。本文没有执行该演示,也不声称某个控件在所有组合下都有相同表现。界面可以看起来正确,而交付资料仍缺少状态关联的说明,此时就应如实记录待核。
同样,提供了语义属性不等于音频播放已经发生。声音输出还涉及应用、设备及使用环境等具体条件。这里的审阅只关注控件表示,不用接口状态替代听音结果,更不能把某个值写成未经测量的物理声压或舒适程度结论。
如采购要求演示键盘操作,可以先约定观察哪些控件行为,并将实际按键响应与状态变化分别记下。若只收到供方操作视频,应说明它是供方提供的材料,不把它改写成接收方完成的测试。未观察的环节保持待进行,避免为了让表格完整而沿用别人的结论。
修订后复查应回到原控件及原问题:可见数字是否与说明一致,当前状态是否得到解释,允许范围是否清楚。只调整滑块样式,可能改善外观而未回应语义问题;只修改说明,也可能尚未覆盖真实交互。每项变更都应按实际内容记录。

最终记录应指出所审阅的页面对象、值含义和状态关系,以及尚未完成的交互或辅助技术观察。不要把网页控件验收写成声学性能验收。若后续确需检查实际播报,应由有责任的人员依据约定任务安排,形成独立记录。
文中两图是原创状态关系示意,没有真实音量值或测试图。相关材料可见语音交互资料栏目与文章目录。让可见数字、状态语义和实际声音各自有明确说明,接收方才知道本次交付究竟确认了哪一层。