上线前怎样在手机和桌面核对联系表单的输入标签和错误提示

本文概述了在网站上线前核对联系表单的输入标签和错误提示在各类设备上是否清晰易懂、便于使用的步骤，以确保顺畅的用户体验。

搭建表单核对环境

设想一位假设的作者，正在为一家小型咨询公司准备联系表单的上线前核对。手头材料包括：一个含四个字段的单页联系表单、一张宽1440像素的桌面截图、一张宽390像素的手机截图，以及一份简短的错误提示草稿清单。这些都还没有经过测试，只是自己拟出的示例，用来明确核对工作应当覆盖哪些内容。

桌面上摆着两个候选表单标题。一个写“Tell us about your project”，另一个语气更平实的写“Contact us”。前者邀请更长的输入，可能让留言字段显得必须填写；后者期望值适中，但对提交之后会发生什么几乎没说。这个选择仍未定，而它会影响下方标签应当怎么读。

三个字段标签已经拟好：“Full name”“Email address”和“What can we help with?”。第四个“Company (optional)”在一份草稿里标了可选，在另一份里没有标。在手机截图上，那个较长的问句标签折成了两行，可选说明又离它的输入框很远，快速滚动的读者可能把两者联系不起来。这处尚未解决的间距，是应当最先定下来的最明确事项。

错误提示同样只是暂定。一份草稿写“Enter a valid email”，另一份写“That email doesn’t look right — check for a typo”。前者简短，适合较窄的手机宽度；后者更友好，但在桌面上可能挤占字段空间。针对空白留言字段的第三份草稿只写了“Required”。这些都还没有给任何人看过。

这个假设场景说明，核对环境大体上是一组选择：标题语气、标签用词、可选标记和错误措辞，每一项都要在两种宽度下查看。下一步是在两种尺寸下把这些草稿并排摆开，决定哪一版继续沿用，而不是把任何草稿当成已经定稿。

核对标签的可见性与关联

每个表单控件——文本字段、复选框、单选按钮和下拉菜单——都需要一个描述其用途的标签，并且该标签必须与控件建立显式或隐式的关联。对于显式关联，label元素的for属性必须与表单控件的id完全匹配。隐式关联则把label元素同时用作控件和标签文本的容器；这种方式适合无法显式标注控件的情形，但辅助技术通常对显式标签的支持更好。¹

浏览器会把关联的标签视为更大的可点击区域，便于选择或激活控件；辅助技术在呈现控件时也能引用到正确的标签。把标签放在表单字段上方通常有助于减少低视力用户和移动设备用户的横向滚动，但来源指出这还取决于其他设计方面，例如附近字段和内容的位置，需要逐项评估。¹

检查时先从两张截图入手，而不是先逐条看字段清单：把宽1440像素的桌面视图与宽390像素的手机视图并排放好，逐个把标签与其输入框对照阅读。在手机图上，可以标出哪个标签离边缘最近，再看它是否仍能被读作属于下方的那个输入框。一个有用的自查办法是用手遮住输入框边框；如果某个标签看起来也可能属于上方的字段，就考虑在下一稿里改写措辞，或把它移得更靠近自己的输入框。

然后拿出拟好的标签草稿，把其中一个改写成两个版本，看看哪一个关联能在窄栏中站得住。例如把“What can we help with?”改成“How can we help?”，让标签占用更少的行数。在手机截图上比较两版，记下哪一版能让问号不被单独折行。你可以决定把哪一版带入下一稿；这个取舍由你定，两种做法都能说得通。

针对错误提示草稿，在两张截图上把每条都直接放到对应字段下方，只把标签和提示放在一起读。如果在手机视图里“Enter a valid email”离它的输入框太远，可以考虑换成更短的提示，例如“Check this email.”记录哪一组配对仍能被读成一个整体，再把这一组配对留作后续核对的工作版本。

检查错误提示的清晰度与位置

错误提示应当容易理解，并给出解决问题的简单说明。行内反馈应放在表单控件处或附近；错误清单可以放在页面上表单之前的位置，其中每一项都应引用对应控件的标签。如果错误是在不重新加载页面的情况下动态出现的，来源指出清单容器应把role属性设为alert。²

发生错误时，顶部清单应有醒目的标题，每个条目应给出简洁描述、说明如何改正错误，并包含指向该控件的页内链接。表单字段可以用aria-describedby与自己的错误提示关联，就像名字输入框指向它的错误文本那样。如果提交的数据含有错误，来源提到，把焦点放到第一个出错的输入框会比较方便。²

你可以从四条错误提示草稿入手，在两张截图上分别把它们与所属字段配对。拿“Enter a valid email”来看，在390像素宽时它直接位于邮箱输入框下方，是否读起来清楚；然后在1440像素宽下再读同一组配对。如果这条提示在手机视图里折到了第二行，记下它看起来是否仍附着于该字段，还是开始像是属于下一个字段。你可以把每组配对标为清楚、含糊或位置不当，并把这条笔记放在截图旁边，而不是另建一份清单。

可以考虑在同一位置上试一种更柔和的措辞。如果你觉得草稿里的“That email doesn’t look right — check for a typo”更有帮助，可以在两张截图上设想它放在邮箱字段下方，再与较短版本比较。问一问自己：哪一个仍能在不单靠颜色的情况下指向正确字段，以及当表单处在窄栏中时，其中是否有哪一个会变得令人困惑。

对于适用于整个表单的提示，你可以拟一句话，并在每张截图上决定它应出现在哪里——字段上方还是提交控件附近。选择由你决定；目标是让这条提示在任何人不得不寻找之前，就把问题定位出来。

测试输入验证反馈

验证反馈并不只是提示文字本身。W3C 的指南指出，自定义验证必须以无障碍的方式通知用户，必填输入应当通过标签清楚标明。还可以给表单控件加上 required 属性，以程序化方式表明该项为必填；同时标签上显示“(required)”，让不使用辅助技术或使用旧版浏览器的用户也能看到。³

指南还指出，验证应当宽容对待不同的输入格式，并举例说电话号码会用不同的分隔符书写，某些国家的邮政编码也不限于数字。最后，仅靠客户端验证不能确保安全，因此数据还需要在服务器端进行验证。³

拿起错误提示草稿，在决定措辞之前，先把每一条与具体字段一一配对。你可以在每个字段旁边写一句简短备注，例如在 Email address 旁写“Enter a valid email”，然后在两张截图上分别读一遍，看看在 390 像素的窄屏视图里，提示是否仍清楚地指向它所属的字段。

可以就同一字段，在直接措辞和更柔和的措辞之间做选择。“Enter a valid email”简洁；“That email doesn’t look right — check for a typo”更亲切但也更长。在手机截图上把两者都读一遍，判断哪一条仍像是绑在邮箱字段上，而不是像一段漂浮的通用文字。如果较柔和的版本在那个宽度下仍能保持完整，你可以保留它；如果你更看重简洁，也可以继续用直接的那条。

对于涉及整张表单的提示，先拟一句话，把它放进两个候选位置——字段上方和提交控件附近——然后在每张截图上标出你更愿意保留的位置。用一两行记下理由，让这个选择在上线前有据可查。这些是自己做的比较，不是测试结果，最终措辞仍由你决定。

复核数据格式的填写说明

填写说明应当写清哪些输入是必填、哪些是选填，以及数据格式和其他相关信息。W3C的资料建议，在适用时提供适用于整张表单的总说明，例如必填与选填输入、允许的数据格式和时间限制，并把这类说明放在form元素之前，这样屏幕阅读器会在切换到表单模式之前读到它。资料中的示例说明会交代必填字段如何标记、主要数据字段的预期格式，以及在哪里找到每个输入框的额外帮助。⁴

相关说明也可以写进标签中，例如标明必填字段和数据格式；在简单场景下，把说明放在标签内可能已经够用，就像“Expiration date (MM/YYYY)”这个标签一样。把说明放在标签之外，定位更灵活，但可能被漏看，而且一些未实现WAI-ARIA的旧浏览器和辅助技术不支持这种做法。一种做法使用aria-labelledby属性，但资料指出，撰写时它尚未被所有浏览器和辅助技术完全支持，因此示例里同时使用for和id属性以保持向后兼容。另一种做法使用aria-describedby，它引用的信息会在标签和其他信息播报之后提供给用户。⁴

拿四个字段标签，在窄屏截图上做一次有意的改写。你可以把“What can we help with?”缩短为“How can we help?”，再看手机视图，确认较短的标签是否仍然贴近它的输入框，让人一眼看出二者的配对。如果仍然贴近，就把这个选择也记在桌面版旁边；如果标签明显游离了，可以保留较长写法，接受两行标签。

接着决定选填字段如何自我说明。与其给每个字段都加标记，你可以只把“Company”标为选填，其余三个不加标记，然后对照两张截图，检查这种区分在不加额外解释时是否仍然可见。

对于适用于整张表单的提示，拟一句话，例如“Please check the highlighted fields”，在两个位置比较：第一个字段上方，以及提交控件正上方。选择已经滚动到按钮的读者仍能看到它的那个位置，并记下你这样选的理由。

完成跨设备无障碍核对

可以把这一轮收尾，做法是把你自己那个含四个字段的表单、两张截图和错误提示草稿清单集中到一份可以随手批注的对比材料里。先定下哪些部分在改动前视为固定：字段顺序、可选标记和提交按钮的措辞。把这三项决定写在记录开头，以免后面改文字时不声不响地把它们重新打开。

拿你已经为窄屏缩短过的三个标签，逐个对着手机截图上的对应回答读一遍。对每一对都可以问：不看桌面那一栏的上下文，这个标签是否仍然点明了期待的是哪一类回答。如果某个标签现在显得太含糊，可以考虑补回一个描述性的词，而不是整句短语。一个实用的作者做法是把两个版本并排放着，选那个在更窄宽度下仍然成立的，而不是那个在大屏上更好听的。

接着把可选字段定下来。你可以决定只有公司字段带可选标记，其余三个不加标记。在两张截图上各检查一次这个选择：先不带标记读一遍每个标签，再带着标记读一遍。如果没有标记的字段可能被读成可选，可以在表单上方加一句简短说明，而不是在每个标签上重复那个词。

对于错误提示，选一个字段，把一种措辞定下来。假设你保留直接的“Enter a valid email”。在两张截图上对着它的字段读一遍，问它是否点明了问题所在和期待的回答，而不需要再回头读标签。如果你改选更柔和的版本，就一次决定好，并在你的草稿中把这个字段的提示统一成那一版。

最后，选定整表说明句放在哪里。在一张截图上把选好的句子放在字段上方读一遍，在另一张上放在提交按钮旁边读一遍，然后挑一个你不再改动也能站得住的位置。把这一选择记为这轮核对的终点，而不是又留下一个待重新打开的问题。

常见问题

在看字段列表之前，我应该如何开始比较这两张截图？

从两张截图而不是字段列表开始：把 1440 像素宽的桌面视图放在 390 像素宽的手机视图旁边，逐一核对每个标签与其输入框。在手机截图上，你可以标出哪个标签离边缘最近，并记下它是否仍然读起来属于下方的输入框。

在决定错误提示草稿的措辞之前，我应该怎么处理这些草稿？

在决定措辞之前，先把错误提示草稿逐条与具体字段配对。

我应该如何选择整表提示句的位置？

最后，选定整表提示句的位置。在一张截图上把选定的句子放在字段上方读一遍，在另一张截图上把它放在提交控件旁边读一遍，然后选择那个无需进一步改动你也能站得住脚的位置。