表单需求没有写输入说明，Agent 怎样整理可访问性评审材料

表单需求没有写输入说明，开发出来的页面即使能提交，也可能让用户猜每个框该填什么。Agent可以将控件清单与可见标签、格式规则和必要信息逐项对照，给设计和产品准备缺口清单。本文聚焦需求材料中的输入辅助，不用一张表宣布整页可访问性达标。

从用户要填写的内容反推说明

表单字段“日期”可能是预约日期、发生日期或报告日期。仅有数据类型date不足以帮助用户。先明确字段的业务用途，再记录显示标签、选项含义、格式提示和是否必填。对于几个名字相近的输入框，标签要能在用户操作时区分，不能只靠开发内部字段名解释。

说明也不应堆得越多越好。通用日期选择器若已有明确交互，额外长段规则可能反而遮挡重点；特殊格式或不常见输入条件，才需要在适当位置给出具体帮助。评审表应记录“缺少什么必要信息”，而不只是标有没有一段文字。

官方机制说明1：3.3.2解释表单标签与输入说明；它不单独证明可访问名称关联或整页WCAG符合性。

这条准则说明标签和说明的用途，同时区分了与控件关联、可访问名称等其他要求。产品规格把说明写出来后，还要在实际页面验证是否呈现和关联正确；本文工作表只承接其中材料准备的一部分。

合成输入1。 日期字段仅显示示例2026/10/24，PRD未写格式

预期处置：生成格式说明待定项和验证样例

合成输入2。 两个输入框都叫名称，实际分别为场地和活动

预期处置：要求可见标签表达差别，保留控件定位

合成输入3。 必填星号有显示但无解释，选填项未标明

预期处置：列说明缺口，由设计确认一致表达

第一条要确认示例究竟是格式要求还是占位演示。示例日期存在，并不等于用户知道其他格式是否接受。第二条不应把两个框简单编号为名称1和名称2，而应按场地与活动含义提供候选标签。第三条将星号的意义与必填规则对应，避免用户只看到一个视觉符号。

可见文字面向所有填写者，字段元数据服务开发和自动检查；两者不宜互相替代。例如PRD说某项必填，界面却只在提交失败时才提到，评审应说明用户何时能得知，而不是只核数据库列是否非空。

工作表按控件记录原标注、候选修改、依据条款和待验证任务。一个候选标签得到产品同意后，还要保留设计采用的位置。若工具只提供屏幕图片，无法确认关联语义，应把这部分标为需实际界面检查，不从像素外观猜测程序结构。

给接手人员一个明确填写任务，例如预约一个场地并说明活动名。先看他能否从标签区分两个名字，再核格式和必填说明是否在需要时出现。验证记录保存环境、观察和证据位置，实际栏在本文附件中为空。

企业现有组件库可能已经解决很多基础标注，定制助手应该利用组件规则，优先找业务命名、特殊条件和跨页面不一致。需求评审和真实访问性测试可分两期交付：前者整理缺口，后者验证真实产品。两期之间保持控件标识，避免修了一份文档却找不到对应页面。

工作表应把“标签不明确”具体化为场地名和活动名两个控件的含义差别，给出待产品确认的候选称谓，再由设计选择实际呈现。日期项应保留已有示例及格式说明空缺，不把示例值误当唯一可输入日期。星号项则同时回查哪些字段确实必填，防止添加解释却与产品规则相反。

每项修改附一个用户任务和观察位置，接手者才能判断已补文字是否真正帮用户填写。若组件库已有统一说明，应链接其受控版本而不是每页复制一遍。本文附件仅列需求证据与人工核对，未验证读屏顺序、键盘路径或整页标准符合性；这些工作应在实际产品验证中单独记录。

下载本题合成输入与可填写工作表。附件保留实际结果、复核人和证据位置空栏。