多人一起维护服务页时，怎样用小节标题分清服务范围、交付物和双方分工

本文讨论共享企业服务页上如何长期保持表述清楚这一问题。文章说明，描述性强的标题可以充当结构锚点，在不依赖大段说明文字的情况下交代归谁负责、边界在哪里。

先说清问题：为什么需要明确边界

先用一个假设场景说明问题。假设一个面向全公司的员工支持服务页由四个团队共同维护：一个处理请求，一个解释政策，一个管理内部工具，一个负责报告。各团队先后往页面里加了内容，现在页面上有这几个标题：“概览”“运作方式”“工具与权限”“常见问题”和“联系方式”。这五个标签看上去整齐，但从搜索结果进入页面的读者看不出哪些请求属于这项服务、每个团队应向申请人交付什么，也看不出一个团队的职责到哪里结束、另一个团队从哪里接上。比如“工具与权限”可能指开通工具账号，也可能指解释权限政策，还可能两者都包括。维护该小节的团队清楚其中的内部区别，读者却不知道。这种含糊就是本文要讨论的问题，下面出现的候选标题仅为说明这一点而虚构。

两条可能的修改路径可以让取舍更具体。第一种做法是把含糊的中间小节拆成三个更窄的标题：“可受理请求与除外情形”“按请求类型列出的交付物”和“决定权归属与交接”。第二种做法是保留原有标签，只在每个标题下补一句职责说明。第一种路径让服务范围和责任归属直接可见，第二种保留了页面现有的导航结构。还有第三种可能：把“运作方式”和“常见问题”合并到“你会得到什么、何时得到”之下，这样也许能减少重复，但可能让那些专门来找操作答案的读者找不到入口。

还有一个未定的选择：服务范围是在页面靠上位置统一说明一次，还是在每个小节里重复。重复有利于从页面中段进入的读者，却会增加跨团队维护的工作量，也提高各处表述逐渐不一致的风险。哪个风险更要紧，作者还没有决定，而这种不确定正是这个例子的用意：除非文字本身真正承诺了一条边界，否则仅靠标题无法表明职责范围。在这里，我们讨论的是多人共同维护服务页时，如何借助小节标题把服务范围、交付物和双方分工说清楚。

用层级结构界定服务范围

W3C的H69技术说明了如何用小节标题传达HTML内容的结构。它陈述的目标包括：用标题标出主内容区内的小节标题、标明主内容的起始位置，并让用户能够按小节浏览页面或跳过重复内容块。该技术说，标题的设计目的是传达逻辑层级；标题序列中跳级可能让人觉得文档结构没有经过认真考虑，或者让人以为某些标题是按视觉呈现而不是按含义来选择的。¹

该技术鼓励作者按层级嵌套标题，把最重要的信息放在最高的逻辑层级，把子节放在随后的逻辑层级，其中h2是h1的子节。它指出，这种结构有助于用户更容易理解内容的整体组织。它还指出，由于标题标明重要内容小节的开始，使用辅助技术的用户可以跳到某个标题并开始阅读。¹

在改写任何正文之前，先把当前的大纲整理成两级骨架。对于一个只有一个h1元素、标题为“员工支持服务”的页面，你可以列出“谁可以申请支持”“各团队交付什么”“一个团队的工作在哪里结束”等h2元素。在每个标题之下，只在读者需要做出不同判断的地方再加上更小的h3元素。如果“各团队交付什么”涵盖薪资咨询，就把开通与权限申请分开放在不同的h3元素下，不要把它们堆进同一个段落。

然后你可以检验这套层级在去掉下方句子后是否仍然承载含义。只按顺序读一遍标题，标出你无法判断谁做什么、或者哪类请求归哪里的地方。在一份草稿中，标题为“支持”的中间小节可以拆成“在职员工的请求”和“管理者的请求”；第二个标题会提示管理者继续读下去，第一个则不会。还要考虑每个下级标题是否收窄了上级标题，而不是引入了一个无关话题。

选哪一层级由你决定。当只有一项职责发生变化时，你也可以保留三个h2元素，并在每个小节内部使用加粗的前导语。在动笔修改之前，记录一位从页面中段进入的同事需要看到哪些标题，再把这份清单与你的骨架对照。这仍然是一项计划好的检查，并不证明该结构已经对读者有效。

用描述性标题标注交付物

按照 WCAG 2.4.6，标题和标签必须描述主题或目的，该指南把这视为在提供了此类标题或标签时应满足的条件。充当标题的内容在描述性措辞上可能合格，却仍不满足 1.3.1 中独立的标记要求；反过来也可能出现这种情况：两项要求分别评估。²

W3C 的指南指出，描述性标题尤其有助于那些因残障而阅读缓慢的用户，以及短期记忆有限的用户，因为小节标题让他们能预判每个小节包含什么内容。指南还补充说，标题和标签不必冗长——一个词、甚至单个字符，只要能为查找和导航内容提供恰当线索，就可能足够。让措辞紧扣该小节实际涵盖的内容，不要为了简短而把线索丢掉。²

从草稿中找出一句描述交付物的话，例如“支持包括入职帮助和持续指导”，先把它改写成标题：“入职帮助与持续指导”。然后你可以决定小节正文是应当界定每个术语、写明由谁获得，还是说明申请人需要提供什么。如果“持续指导”涵盖三种不同的活动，可以考虑把这个标题拆成两个，因为一个掩盖差异的标签会把细节推回正文。

对职责清单也可以做同样处理。像“A 团队负责设置，B 团队负责解答问题，C 团队负责后续跟进”这样一行，可以改成“设置、问题解答与后续跟进：各自由谁负责”。这个标题告诉读者该小节解决什么问题，又不让页面变成一张流程图。如果问题解答仍由多个团队共同承担，你也许更愿意用更窄的版本“谁负责设置与后续跟进”；选哪个由你决定，取决于你能把责任说得多明确。

改写两三个标签之后，把原来的句子放在旁边对照阅读。如果某个标题现在逐字重复了那句话，这句话也许可以删掉；如果标题增加了原句从未做出的区分，就保留两者，让正文来解释这个区分。

通过小节组织落实责任归属

按照技术G141，内容按小节组织的页面应当为每个小节设置一个能标识该小节的标题。该技术指出，在HTML中可以用h1至h6这些标题元素来实现，使用户代理能够自动识别小节标题。因此，一个小节承载什么样的职责，首先就通过它自己的标题表达出来。³

该技术还谈到了嵌套：为了便于导航并让人理解文档的整体结构，作者应使用正确嵌套的标题，比如h1后面接h2，h2后面接h2或h3。其示例就采用这种模式：用h1元素作总标题，用h2元素标出主要小节，再用h3元素标出其中一个小节下的子小节。³

一项相关的测试程序要求你检查一个内容分节的页面，确认每个小节都存在对应的标题。³

你可以在写下任何点名团队的句子之前，先利用标题层级本身来表明谁负责哪个小节。设想一个共享支持页面的草案提纲：一个h1元素“员工支持服务”，后面跟四个h2元素。如果资格判定、开通和跟进这三个小节分属不同团队，你可以在每个h2元素下再设一级，用来说明工作内容而不是负责人，然后把负责团队的名字放在该小节第一句话的开头。这样，扫读提纲的读者不必读正文就能看出责任在哪里发生变化。

看看这个假设的修改。修改前：“开通和跟进的办理方式取决于你的请求类型。”修改后，在同一个h2元素下拆分，你可以把“初始账号开通”写成一个h3元素，把“开通后的跟进”写成另一个h3元素，并让每个小节的开头一句分别以“开通团队负责……”或“跟进团队负责……”起头。标题现在标出了边界，句子则指明负责人。团队名称是否放进标题本身，由你决定；放在开头一句里，可以在责任归属变化时让标题保持稳定。

作为核对，只按顺序读h2和h3元素，记下每一处你无法判断负责人是否变化的地方。你可以把这些点记在提纲旁边，之后再决定是用一个新标题还是一个更清楚的开头句来解决每一处。

在无障碍与业务清晰之间取得平衡

在多人共同维护的服务页上，业务清晰与无障碍可以是同一套结构要达成的两个目标。无障碍写作指引指出，简短的标题应把相关段落归组并清楚描述各小节，好的标题能提供内容大纲。对于超过三四个段落的文档，标题和子标题对可用性和无障碍都很重要，因为它们帮助读者把握整体大纲，并导航到具体信息。⁴

该指引还区分了一点，这在标题承担范围或职责信息时尤其要紧：视觉读者可能通过扫描字号更大或样式不同的文字来识别标题，但使用辅助技术的读者看不到这些视觉变化，因此只改变样式并不足以构成提示。标题必须在语义上被标记出来，辅助技术才能识别它们；也只有这样，标题才能同时用于导航。同一份指引把标题级别划为一到六级，其中一级标题往往对应页面标题或主要文档章节。⁴

从草稿里的一句同时点名服务和团队的话开始，例如“平台团队支持入职并解答权限问题”。你可以把它改写为把活动与负责方并列的标题，例如“入职支持与权限问题”，再把团队名称放在标题下的第一句。这样标题说明该小节涵盖什么，正文则让责任归属保持可见，可能比把两者硬塞进一个标签读起来更清楚。

如果草稿已经在多个标题里重复负责方，你可以保留一个只讲范围的标题，让第一行承担团队信息。比较这一组前后写法：“平台团队处理权限问题”与“权限问题”外加一句点明平台团队的开头句。把两者都读一遍，记下哪一种更能让从页面中段进入的读者不必向上滚动就理解该小节；最终选用哪一种由你决定。

跨团队核对标题的一致性

核对跨团队标题时，来源对页面中的固定区域（例如侧边栏）提出了明确要求：这些区域里的标题层级不应随内容区的层级变化。来源说明，在这些情况下，跨页面的一致性更重要。⁵

来源还把跳级列为应当尽量避免的做法，并举例说明：一个h2元素后面直接跟着一个h4元素。来源也提到一种允许的情况：在结束子小节时可以跳级，例如用h2开启一个新小节，而它前面是一个h4，用来结束上一个小节。⁵

当标题用于标注页面区域时，来源说明可以用aria-labelledby属性把标题与其区域关联起来，并指出可见的标题能让所有用户都容易识别各个区域。⁵

检查你当前的标题列表，再与同事维护的同一服务页版本作比较。不必合并文件也能做：把两份大纲并排放，标出每个在层级、归属或措辞上不同的标题。假设有一对版本，一份写的是“权限请求”和“权限跟进”，另一份把两者都收进“权限支持”；记下这一差别，就能看出读者可能在哪里失去范围边界。

接着，你可以为每个概念选定一种措辞，记录在大纲旁边，并注明哪些团队依赖该小节。这是你的编辑选择，不是强加给其他团队的规则。如果两个标题对同一项交付物仍使用不同标签，可以考虑保留更清楚的那个，把另一种写法移入下方的句子中。

最后，单独重读修改后的列表。如果你能看出每个小节由哪个团队负责、交付什么，这一轮一致性核对就达到了目的；如果看不出来，标出这些标题，在下一次修订发布前与相关责任人把措辞定下来。

常见问题

在改写正文之前，怎样把现有提纲整理成两级骨架？

先把你现有的提纲整理成两级骨架，再动笔改写正文。以一个 h1 元素“员工支持服务”为例，你可以在下面列出若干 h2 元素，例如“谁可以提出支持请求”“各团队交付什么”“一个团队的工作在哪里结束”。

怎样从一句同时写明服务与团队的话出发，把它改写成标题？

先在草稿中找出一句同时写出服务和团队的话，例如“平台团队支持入职并解答权限问题”。你可以把它改写成把活动与负责方并列的标题，例如“入职支持与权限问题”，再把团队名称放在标题下的第一句里。

怎样在不合并文件的情况下，把自己的标题清单和同事的版本对照一遍？

拿你现有的标题清单，和同事就同一共享页给出的版本对照。不必合并文件：把两份提纲并排放好，标出每一个在层级、负责方或措辞上出现差异的标题。