企业与服务网站：如何提高站内搜索与筛选的可用性（多设备访问）

企业与服务网站往往依靠搜索与筛选工具，帮助用户找到服务或产品。然而，这些工具在移动设备上，或对依靠键盘操作的人来说，可能并不好用。本文给出一些实际做法，让搜索输入更清楚、交互更可预期，使访客无论使用哪种设备或输入方式，都能有效地浏览网站。

理解可访问搜索输入在企业与服务网站中的作用

作为一个假设示例，设想一家中型服务公司的撰稿人正在为列出咨询、维护和培训服务的网站准备搜索框。他们从早期线框图中拿到了三个占位标题：“查找服务”、“搜索我们的服务项目”和“您需要哪方面的帮助？”每个标签暗示的范围略有不同。第一个听起来像目录查询，第二个暗示宽泛的目录，第三个则邀请用平实语言描述问题。撰稿人尚未决定哪种措辞与内容结构相符，而这一选择会影响输入框本身的外观。

同一份草稿包含两个候选筛选组。一个是简短的服务类别，如咨询、现场支持和培训。另一个是受众类型，如小团队、部门和公共部门群体。将两者合并在一个面板中，会在窄屏手机上形成密集的网格；而将它们放在不同步骤中，则可能让有用的选项藏在额外的一次点击之后。尚未解决的问题是：首屏应只显示类别，还是同时提供两组选项并给出清晰的进一步缩小范围的方式。

对于输入控件，草稿勾勒了一个单行字段，配有可见标签、一个按钮和下方的一行简短提示。提示文本仍标记为占位符：“尝试输入服务名称或简短描述。”尚未决定提示在开始输入后是否保持可见，还是应当折叠以节省垂直空间。在手机上，持续显示的提示可能把结果推到首屏之外；在桌面上，移除提示则可能让字段显得空洞。

撰稿人还在这字段旁附了一条粗略的无障碍备注：一个在程序上与输入框保持关联的标签、一个具有明确名称的按钮，以及一个用于显示“无结果”或“加载中”的状态消息区域。该备注尚未说明筛选条件变化时状态区域如何表现，也没有确定建议词是出现在字段下方还是结果列表内。这些是用于说明问题的草稿选择，并非来自实际网站或已完成测试的发现。

实现可预期的自动补全行为，方便用户操作

W3C的combobox模式把自动补全视为一种行为选择，而不是唯一的默认做法。其文档描述了四种形式：无自动补全、带手动选择的列表自动补全、带自动选择的列表自动补全，以及带行内自动补全的列表。当combobox可编辑且具有任一形式的列表自动补全时，弹出框可能随着用户输入而出现和消失；例如，一个不匹配任何建议的字符串可能使其关闭，任何行内补全字符串也会消失。¹

该模式还为触发条件和键盘使用设定了预期。弹出框默认隐藏，展开条件因具体实现而异，例如按下向下箭头或激活一个打开按钮。Escape键关闭可见的弹出框，如果弹出框此前已隐藏，则可选择清空combobox。¹

对于你自己草稿中的自动补全建议列表，可以先写出六个候选条目，然后逐一缩短。一个草稿条目如“为需要帮助部署新内部系统的团队提供的培训服务”可以改成“新系统团队培训”。如果缩短后的条目不再匹配访客会输入的内容，你可以把更完整的说法保留为辅助文本，而不是作为建议本身。

你也可以在定稿前先在纸上比较排序方案。假设这六个条目包括两种服务类型和四个地点。你可以先列出服务类型，再列出地点，并在列表旁写一行说明该选择的理由。另一种顺序也合理；重要的是这个顺序遵循一条你能清楚说明并保持一致的原则。

对于空结果，可以考虑草拟一条简短消息加两个备选操作，例如扩大查询范围或浏览某个类别。写出两个版本，选择在你的页面语境中读起来自然的那个。在更完整的页面草稿完成前，你可以把选定的消息标记为暂定。

最后，记下值得稍后回头处理的问题：建议条目是否应随访客输入而更新，以及列表在小屏幕上过长时应如何表现。把这些记为待定事项，而不是已解决的答案。

确保键盘焦点指示清晰可见

键盘用户需要能够把键盘焦点指示与视觉设计的其他部分区分开，因为焦点移动引起的细微变化可能让用户丢失焦点位置。相关页面指南建议依赖浏览器提供的默认焦点指示；如果要覆盖默认值，指南提到颜色和渐变在高对比度模式下可能消失，并且焦点必须与选中状态保持可区分，尤其是当一个包含已选中元素的组件本身不持有焦点时。²

活动元素必须始终带有可见的焦点指示，作者需要管理那些移除或隐藏活动元素的事件，例如关闭对话框或从列表中删除某项，以免焦点回落到body元素上。由于菜单和网格等ARIA组件的交互依赖代码而不是浏览器默认行为，该指南也涵盖了何时应让禁用状态的交互元素可获得焦点这一判断。²

从你自己的草稿中取出导航区块，标出访客用键盘能够到达的每一个元素——标志链接、主菜单项、子菜单链接，以及打开移动菜单的按钮。然后在每个条目旁加一句简短书面说明，写清访客用Tab键移到它上面时，可见的焦点提示应当是什么样子。你可以选择适合本站配色方案的提示：对比色两像素轮廓、与文字保持间距的实线下划线，或标签背后的色块。无论选哪种，都在同一组件的桌面版和移动版上应用同一种提示，使访客在不同设备间切换时遇到一致的信号。

接下来，在改动其他标签之前，先修改一个具体标签。假设你的草稿在主导航中写的是“服务与解决方案”。你可以把它缩短为“服务”，把较完整的说法留在页面标题中，然后检查焦点环是否仍然舒适地贴合较短的词而不被裁切。这个小改动能显示你的提示在文字长度变化后是否仍然成立；如果它挤到了字母，就把偏移量加宽。你可以逐项决定提示用轮廓还是下划线，但把选择写在每个条目旁边，能让整组保持连贯。

作为纸面练习，画出移动菜单展开、列出十个条目的状态。标出焦点提示落在第一个、中间和最后一个条目上的位置，以及访客能否判断哪一个处于活动状态。你可能会记下最后一项的提示与菜单边缘重叠；如果是这样，就在草图中调整间距，而不是改动提示本身。这些笔记是准备工作，不是已完成的测试——把它们和草稿放在一起，让下一次修订从书面选择而不是猜测开始。

使用标准HTML属性标明输入用途

H98技术为每个表单字段添加适当的autocomplete标记，使被标识的输入框在程序上可被确定。其明确目标是把一个预先定义并公开发布的分类术语关联到输入框，使输入框也能被机器解释；这样一来，无论页面使用何种语言、屏幕上显示何种可见标签，输入框都带有共同、可引用且可识别的值。³

该技术适用于对应用户界面组件输入用途的HTML表单字段。按该成功准则的说明，对于不对应HTML autocomplete属性规范所述字段的表单字段，不假定应使用autocomplete；如果字段描述的是自定义分类而非规范所述分类，该规则可能产生不正确的结果。该技术只应在询问填写表单者本人的数据时使用，而不应用于其他人的数据。³

从自己的草稿中选一个搜索输入框，写下它预期接收哪类信息：服务名称、地点、参考编号还是电子邮件地址。然后你可以用与该用途相符的平实词语重命名字段。例如，草稿标签“搜索全部内容”在字段同时接受服务和地点时，可以改为“搜索服务或地点”；而只接受编号的字段可以写成“输入参考编号”。选择与手头材料最匹配的措辞即可。

接着，把可见标签与下方提示文本对照。如果两者重复同一条说明，你可以让标签保持简短，由提示说明值的格式，例如“尝试输入服务名称或城市”。你还可以记下该字段是否把几类输入合并到一个框中；如果确实如此，可以考虑把草稿拆成两个带标签的字段，再比较哪个版本能让读者凭记忆完成填写。

为每个字段添加一条私下备注，写明预期的输入类型，以及标签单独阅读时是否仍然说得通。试着遮住周围段落，只把标签和提示读出声；如果用途不清楚，就修改措辞，而不是增加更多解释。

增强交互组件时保持原生语义

W3C的Using ARIA文档为组件作者设定了一个有条件的优先次序：如果原生HTML元素或属性已经提供了所需的语义和行为，就应当使用它，而不是改造一个元素并添加ARIA role、state或property。文档列出了少数可能无法这样做的情况：HTML功能虽然存在但未被实现或缺乏无障碍支持，视觉设计限制使得无法使用原生元素，或者该功能目前在HTML中尚不可用。⁴

第二条规则要求除非确有需要，不要改变原生语义。文档给出的例子是开发者要构建一个充当标签页的标题：它反对在h2元素上放role=tab，而是展示一个带role=tab的div，其中包含h2标题。一条相关说明指出，如果用非交互元素作为交互元素的基础，开发者必须用ARIA补充语义，并用脚本补充相应的交互行为；对于按钮而言，使用原生HTML按钮更好也更简单。⁴

在键盘使用方面，第三条规则规定所有可交互的ARIA控件都必须能用键盘操作。如果用户可以点击、轻触、拖动、放下、滑动或滚动某个组件，他们也必须能够导航到该组件并用键盘执行等效操作。文档指出，交互组件必须编写脚本以在适用时响应标准按键或按键组合；其role=button示例要求该元素能够获得焦点，并且操作可以通过enter或return键以及空格键激活。⁴

第四条规则禁止在可聚焦元素上使用role=presentation或aria-hidden=true，因为部分用户会把焦点落在空无一物的地方。对可见交互元素的父元素或祖先元素应用aria-hidden同样需要警惕。文档指出，通过display:none或visibility:hidden隐藏的元素不可聚焦，也不在无障碍树中，因此再设置aria-hidden=true或tabindex=-1没有必要。⁴

拿你自己草稿中的交互组件，在改变其外观之前先标出一个结构性问题：当脚本或样式被剥离后，底层控件会是什么？对于搜索字段，你可以决定它仍然是一个带标签的文本输入框加一个提交按钮，然后把任何建议列表当作附加功能，而不是获取结果的唯一路径。对于筛选组，你可以写下选项是复选框、链接还是一组分组的选项，并注明哪一种在没有自定义行为时仍能传达选中状态。

做一个简短的纸面练习：选择一个组件，为其朴素形态草拟两个版本。假设你的筛选面板有三个服务类别和一个地点选项。版本A可以保留类别为带可见组标签的复选框；版本B可以把同样的选项呈现为指向结果页面的链接。比较哪个版本在朗读或用无样式方式浏览时更能让当前选中项一目了然。这是你自己的比较，不是对任何用户会如何反应的断言。

你还可以改写组件附近的一行文字，让操作名称更直白。如果草稿标题写着“细化你的结果”，可以考虑改成“按类型和地点筛选服务”。选择权在你，并私下记一笔：当脚本层被移除后，该组件是否仍然说得通。

通过基础交互检查验证多设备兼容性

检查你自己的页面草稿中的搜索框和筛选面板，并在它们旁边写一段简短的操作脚本：访问者从进入页面到读到一条结果，会进行哪些点击、输入和滚动。现阶段用纸面记录，并给每一步标注你设想的设备——手机、平板还是桌面。这样你就得到一份具体清单，在改动任何布局之前可以逐项核对。

对于搜索框，你可以把步骤写成带编号的序列。草稿片段可以这样写：点按字段，输入“维护”，等待建议，点按第二条建议，滚动结果，打开一条。然后读一遍，标出拇指会遮住提示文字的位置，或者建议列表会把结果推得太靠下的位置。如果设想的是竖屏手机，记录字段和它的按钮是否仍能排在一行内，还是按钮会折到下方。考虑这种折行是否可以接受，或者标签是否应当缩短——由你选择。

对于筛选面板，写一段对应的序列：打开筛选，选择一种服务类型，选择一个地点，应用，然后清除。记录点按次数，以及应用操作是否位于长列表的底部。你还可以记下一个稍后自己回答的问题：应用之后面板是否保持打开，这会有帮助还是有妨碍？每个答案写一句话，然后选出你更倾向的版本，并修改草稿与之保持一致。

最后，选择一条结果行，写下访问者做决定时需要看到什么：服务名称、地点、价格或时长，以及一个操作。像在电话里向同事描述那样把它读出声来。如果有任何一项感觉缺失或顺序不对，就调整草稿中的该行文字，并在旁边记下改动。其余页面暂时可以不动，把这一行作为其他行的参照。

常见问题

在改名之前，我怎样才能弄清自己的搜索框期望接收哪类信息？

从自己的草稿中取一个搜索输入，写下它期望哪类信息：服务名称、地点、参考编号，还是电子邮件地址。然后就可以用与这一用途相符的平实词语给该字段重新命名。

对于每个字段，我可以添加怎样一条关于其预期输入类型以及标签能否独立成立的私人备注？

为每个字段添加一条私人备注，写明预期的输入类型，以及标签单独出现时是否仍然说得通。

我应该怎样为自己页面草稿中的搜索框和筛选面板起草一份交互脚本？

从自己的页面草稿中取出搜索框和筛选面板，在旁边写一份简短的交互脚本：访客从进入页面到读到一条结果会进行的点击、输入和滚动。先把它留在纸面上，并给每一步标出设想的设备——手机、平板或桌面。