STATUS IS UP网站优化 Wiki
09启用
设计与用户体验 / 启用

提高可发现性的站点导航最佳实践

规划路径、确保路由可操作,并在发布前进行预检。

提高可发现性的站点导航最佳实践 — 可视化指南
阅读
8 分钟
来源
7
重新验证
2027-03-27
已审阅
具有可访问性意识的 UX 与发布就绪评审员
简短回答

从决策开始。

以访客任务为起点,而不是按内部部门或罗列每个页面。把支持这些任务的章节按稳定顺序展示,使用能预测目的地的标签,并在页面级别提供细节链接。访客应该无需猜测即可到达下一步操作。

让路径在键盘、触控和呈现后的 HTML 链接上都能正常工作。在小屏幕和部署后测试真实任务。在 SIU(Status Is UP),导航工作是主动的可用性优化:对关键路径做预检,在客户遇到之前修复断路,并为风险发布保留回滚线路。

可视化指南

把工作看作一个系统。

使用此地图在执行具体策略前将文章中的决策联系起来。

SIU启用
01从任务和精简的信息架构开始
02使用能预测目的地的标签
03使目的地可抓取且结构清晰
04将移动菜单设计为完整的交互
01

从任务和精简的信息架构开始

信息架构是内容和功能如何分组、命名和连接。列出访客任务,然后映射每个任务的起始页、下一步页面以及成功结束状态。这能显示某个菜单项是否有用,或只是访客需要解码的内部标签。将主要导航聚焦于那些启动这些任务的章节。

导航不是网站地图。GOV.UK 建议列出有用的顶层章节,而不是服务的每一部分。当一个流程有强制顺序时,应在内容或任务列表中展示该顺序,而不是让人从全局菜单里推断。

按用户目标分组

当访客期望获得相同答案或完成相同任务时将页面放在一起,而不是仅因为某个团队负责它们。

保持首层浅显

使用着陆页和上下文链接提供细节,而不是在密集的头部放入过多选项。

02

使用能预测目的地的标签

标签是一项关于后续内容的承诺。优先使用访客熟悉的名称,例如“定价”、“文档”、“获取支持”或“管理账户”,只要它们与目的地相符。避免使用诸如“资源”或“探索”之类的模糊标签,除非访客能预测其内容。保持用词和顺序一致。

Google 建议使用简洁、相关的链接文本,并保证其在上下文外也能被理解。通用的“点击此处”和堆砌关键字的链接都无法做到这一点。给仅图标的控件提供可访问名称来描述其动作。

命名为结果

当目标是显示方案时,使用“查看方案”而不是“了解更多”。

显示位置

在视觉和程序上标记当前目的地;W3C 描述了 aria-current=page 用于当前显示页面。

03

使目的地可抓取且结构清晰

导航目的地通常应为带有可解析到真实网址的 href 的 HTML 锚点(anchor)。Google 表示,这种形式通常可被抓取,包括在渲染后保留该结构的动态插入锚点。仅靠点击处理程序或自定义属性并不是可靠的替代方案。检查呈现后的输出,而不仅是框架源代码。

在主要导航周围使用语义结构。W3C 建议使用 nav 元素,并且对于常见站点导航使用列表。如果页面有多个导航区域,应为每个区域加标签,以便屏幕阅读器用户能区分主要导航、页脚或局部导航。

检查渲染输出

确认重要的桌面和移动目的地在客户端渲染后具有锚点和 href 值。

谨慎使用 Search Console

URL 检查(URL Inspection)提供 Google 的抓取、索引和呈现信息;它不能证明访客能否找到某个页面。

04

将移动菜单设计为完整的交互

响应式导航可以折叠,但保留的目的地应在各屏尺寸间保持相同的措辞、顺序和目标。W3C 允许折叠或隐藏子导航项,同时要求保持一致性。不要因为页眉拥挤就把关键路径变为仅限桌面的;应重新安置低优先级内容或重新考虑层级结构。

对于显示/隐藏菜单,使用按钮来控制链接组并传达其是否打开。W3C 的 disclosure-navigation 示例使用 aria-expanded 和 aria-controls,并记录了 Tab、Shift+Tab 和 Escape 的行为。该示例具指导性,因此需用目标受众常用的组合来测试你的组件。

分离两个动作

当父页面和其子链接都需要时,应将页面链接与展开控制区分开来。

避免仅悬停可访问

任何由指针悬停展示的内容必须能通过键盘聚焦和触控找到。

05

支持方向感和键盘导航

键盘访问不是锦上添花。WCAG 2.1 成功准则 2.1.1 要求功能应可通过键盘界面操作(路径依赖输入除外)。在页眉中,访客应能使用 Tab 遍历控件、看到聚焦、激活链接和按钮,并能离开而不被困住。

重复的页眉链接会让页面逐页遍历变慢。一个靠近开头的跳过链接(skip link)能为键盘用户提供直达主内容的路径。GOV.UK 解释该链接在键盘使用时才可见。测试它是否落到一个有意义的目标上。

保持聚焦可见

不要移除浏览器的聚焦指示器,除非提供了在放大后仍可见的明确替代方案。

运行路径测试

从页眉到目标页面使用 Tab、Shift+Tab、Enter、Space 和 Escape 进行操作。

06

在发布前后测试可发现性

请具有代表性的用户完成现实任务,例如查找取消说明或比较方案。观察他们期望去往何处、误读哪些标签,以及他们是否因导航失败而求助搜索。不要引导他们到预期的标签。记录每个阻碍和最小的改动以消除它。

将任务测试与技术检查配对。W3C 的 Easy Checks 建议在不使用鼠标的情况下测试,包括聚焦可见性、Tab 顺序、键盘陷阱和下拉菜单。在窄屏和放大文字大小下重复核心任务。自动化检查可以标记标记问题,但不能证明标签是否通顺。

先定义成功

在测试前记录预期终点和支持的设备或输入方式。

公平比较版本

对旧路由和新路由用相同任务进行测试,而不是依据相关方偏好判定。

07

把导航变更视作对可用性敏感的发布

页眉可能会加载,但关键路径实际上不可用:结账、登录、支持入口或文档页面可能被错误状态、过期链接或错误重定向阻隔。在发布前,清点关键目的地,测试桌面和移动路径,并确认渲染后的链接指向预期页面。对需授权或区分区域的路径,请在授权环境中验证。

SIU 的职责是主动修复:运行预检、在部署后验证关键路径,并使更改可逆。保留版本化的菜单配置,明确能恢复它的人员,并验证恢复后的路径。这能限制发布影响;但不能替代可用性研究或实时状态监控。

设定发布门控

当关键目的地缺失、错误或无法通过键盘和触控到达时阻止发布。

准备回滚

在重构前记录先前配置、负责人、触发条件和验证步骤。

行动 / 验证

你的实用待办指南。

  1. 01

    列出优先访客任务

    为每个重要结果映射起始页、路线和结束状态。

    验证: 一位队友无需参考内部组织结构表就能追踪每个任务。
  2. 02

    减少主要选择项

    将区别明确的高价值章节保留在头部;将细节移到着陆页或上下文链接。

    验证: 每个主标签都支持一个特定的访客任务。
  3. 03

    重写模糊标签

    用以目的地为中心的措辞替换通用提示和内部术语。

    验证: 新人能预测每个标签将打开的内容。
  4. 04

    验证渲染后的链接

    检查渲染后的桌面和移动导航。

    验证: 每条关键路径在渲染后都是带有可用 href 的锚点。
  5. 05

    操练移动显示/隐藏菜单

    用触控和键盘打开、关闭并遍历紧凑菜单。

    验证: 其状态被传达,Escape 可关闭,且没有必要路径仅限桌面访问。
  6. 06

    进行键盘专用检测

    放下鼠标,使用 Tab、Shift+Tab、Enter、Space 和 Escape。

    验证: 聚焦可见、逻辑、完整且不会被困住。
  7. 07

    验证跳过链接

    提供绕过大量重复导航到主内容的路径。

    验证: 该链接在键盘聚焦时出现并移动到有用的主内容。
  8. 08

    观察任务完成情况

    在你支持的界面上测试现实的可发现性任务。

    验证: 记录到的混淆和绕行被排序并重新测试。
  9. 09

    预检并做好可逆准备

    在发布前测试关键路径、分配负责人并保留先前配置。

    验证: 有文档化的回滚可以恢复并重新检查先前的导航。
讨论主题

比较各种权衡,而不是私有数据。

与团队或网站所有者社区一起使用这些提示。共享方法与经验,但切勿粘贴凭证、客户记录或非公开的基础设施细节。

  1. 01

    哪些标签在你的团队和首次访客之间分歧最大?任务测试如何解决这一分歧?

  2. 02

    哪个关键客户任务依赖导航而非搜索,你会如何在发布后验证该路径?

  3. 03

    当移动菜单拥挤时,你会在添加另一级之前做出什么信息架构决策?

热门 / 权威资源

打开来源材料。

Google Search CentralLink best practices for Google ↗

关于可抓取锚点、href 值和描述性链接文本的官方指导(Google 资料)。

已审阅 2026-09-27
W3C Web Accessibility InitiativeMenu Structure ↗

关于语义 nav 与列表结构、标签、当前页指示及响应式一致性的 W3C 建议。

已审阅 2026-09-27
W3C Web Accessibility InitiativeExample Disclosure Navigation Menu ↗

披露状态、键盘支持和生产测试注意事项的示例与说明(W3C)。

已审阅 2026-09-27
GOV.UK Design SystemHelp users to Navigate a service ↗

以任务为导向的信息层级建议以及反对将导航当作网站地图的意见(GOV.UK)。

已审阅 2026-09-27
W3C Web Accessibility InitiativeEasy Checks – A First Review of Web Accessibility ↗

关于焦点、顺序、陷阱和下拉菜单的手动检查建议(W3C Easy Checks)。

已审阅 2026-09-27
W3C Web Accessibility InitiativeUnderstanding Success Criterion 2.1.1: Keyboard ↗

键盘可操作性期望与可访问性目的的说明(WCAG 说明)。

已审阅 2026-09-27
GOV.UK Design SystemSkip link ↗

关于跳过主内容链接目的和行为的资料(例如 GOV.UK 解释)。

已审阅 2026-09-27

来源政策。 声明基于以上列出的 Google、W3C 与 GOV.UK 的官方资料(访问时已阅读)。内部链接和 SID 链接与导航相关,但并不构成证据本身。

快速说明

常见问题。

主导航应该包含多少个链接?

没有通用的数字。将首层保持为能启动高价值任务的不同章节。如果标签变得模糊或访客必须扫视很长一排,请使用着陆页、上下文链接或调整层级,而不是把页眉当作网站地图。

移动菜单是否必须与桌面导航完全相同?

保留的目的地应在各屏尺寸间保持相同的顺序、措辞和目标。你可以重新安置低优先级内容,但不要仅因移动空间受限就隐藏关键路径。在小屏幕上测试任务路径。

JavaScript 导航链接对 SEO 或可访问性有害吗?

不一定有害。Google 表示,当渲染后的标记使用带 href 的锚点时,动态插入的锚点通常可被抓取。风险在于用脚本事件或自定义控件替换目的地链接。检查渲染输出并测试键盘与触控交互。

Status Is UP Editorial Team · 可用性使能编辑 (Uptime Enablement Editors)

由 具有可访问性意识的 UX 与发布就绪评审员 审阅。发布于 2026-09-27;更新于 2026-09-30。