企业发出的制度、报价表和培训材料，除了版面完整，还应让目标读者能够找到内容、理解含义并完成操作。采购办公软件时，如果只要求“支持无障碍检查”，容易漏掉最后这一步：检查器没有报错，使用屏幕阅读器或主要依靠键盘的同事，是否真的能完成工作？
建议把验收拆成两份结果：一份记录工具发现的问题如何处理，另一份记录目标读者在约定环境中完成了什么任务。微软的辅助功能检查器规则明确说明，工具无法检测所有问题，仍需人工审查。通过检查器不能直接当作符合某项无障碍标准的证明。
先选读者任务，再准备测试文件
“全员可用”很难直接测试。可以先选一项具体任务：员工找到制度中的报销期限，采购人员读懂报价表的列名与单位，培训学员理解幻灯片上的流程。由业务负责人确定必须传达的信息，再与相关使用者确认阅读方式和终端；记录操作系统、办公应用、辅助技术及版本，不把一个环境的结果推到所有客户端。
样本应保留日常文档的结构，并使用脱敏内容。例如，一份培训通知含有章节、数据表、流程图和报名链接。验收不是让参与者猜测作者的意图，而是看他们能否找到报名条件、理解流程分支，并进入正确的报名入口。参与者不必向采购团队披露与任务无关的个人健康信息。
检查器适合找什么，人工还要问什么
微软的使用说明介绍了查看错误和警告、定位相关对象并应用修复建议的流程。不同 Office 应用、版本和客户端的入口与检查项会有差异，应对照实际环境使用。以下将官方规则与建议的人工复核并列，供团队设计验收样本。
| 内容 | 工具提供的线索 | 人工复核的问题 |
|---|---|---|
| 图片与图表 | 替换文字是否存在 | 描述有没有表达这张图在本文中的用途和结论？ |
| 数据表 | 标题信息、表格结构 | 逐项阅读时，能否知道数字对应的项目和单位？ |
| 工作表 | 名称是否有意义 | 读者能否选中需要的工作表并找到目标数据？ |
| 演示文稿 | 标题、对象阅读顺序 | 按实际阅读顺序接收信息，是否仍能理解因果关系？ |
这些是跨应用的规则示例，不表示每个客户端都执行全部检查。人工复核也不应只确认“填了文字”。例如，一张流程图的替换文字写着“审批流程图”，虽然有文字，仍未说明驳回后回到哪里；可在正文提供必要的步骤与分支说明，再判断图片描述是否足够。
颜色尤其容易遗漏。微软在限制说明中列出“仅使用颜色传达信息”：如果表格只用红底和绿底表示未通过、已通过，读者未必能分辨状态。可以同时提供明确的文字标记，并实际核对含义。是否检出某种具体颜色格式，不能替代对整份文件信息表达的检查。
让真实阅读过程暴露工具之外的问题
在约定的辅助技术和客户端组合中，让熟悉相应阅读方式的参与者完成样本任务。观察能否进入需要的内容、按合理顺序阅读，并理解链接或控件的用途。涉及填写或跳转时，再测试键盘能否到达目标并完成操作；仅阅读的材料不必强加编辑任务。
记录应具体到阻碍，而不是只写“体验一般”。例如，“能读到各行数字，但无法确认其所属列”“到达报名链接后，名称不足以判断去向”。内容作者负责修正文案与结构；若问题来自应用或辅助技术组合，则交给 IT 与供应商复现。不要用讲解员临场提示，掩盖文件自身无法表达的信息。
没有条件测试某种辅助技术时，将对应环境标为未验证，补充测试安排。由普通读者目测一遍，可以发现部分问题，却不能替代使用者在目标环境中的验证。若涉及正式标准符合性要求，应另行明确适用标准、评估范围和专业评估方式。
验收对象必须是最后交出的那份文件
编辑器内阅读、下载 Office 文件和导出 PDF，是不同的交付路径。应按实际使用方式分别测试；不要把源文档的检查报告直接贴到转换后的文件上。修改图片说明、调整表格、转换格式或更换模板后，重新检查受影响部分，并确认最终交付版本与记录一致。
完成记录可以包含文件版本、目标任务、客户端与辅助技术组合、工具问题及处理、实际任务结果、未覆盖项和负责人。关键任务受阻时先修复，或与接收方约定可用的替代交付方式；有明确限制的结果应连同限制一起交付。这样，采购看到的就不只是一个功能名称，而是该方案能支持哪些人、在哪些环境中完成哪些工作。
评估石墨办公套件私有部署等方案时，可将目标读者、代表性文件和交付路径带入方案演示，请方案方在拟交付版本中确认检查能力与辅助技术适配情况。本文引用的微软检查器能力只适用于相应微软产品，不据此推定其他办公软件提供同名功能或相同兼容性。也可以先看私有化部署方案，了解部署形态与交付范围。