语义 HTML： Accessibility、SEO 和 AI 的共同语言

一个页面可能看起来清晰无比，但在结构上仍然模棱两可。

视觉设计为有视力的用户提供了强有力的线索：尺寸、颜色、间距、位置、图标和动效。当同一个页面通过无障碍树被读取、被爬虫解析、被审计工具检查、或被 AI 系统提取时，这些线索就会减弱或消失。

这正是语义化 HTML 的价值所在。它不能保证排名、AI 引用或无障碍合规。它做的是更基础的事：减少每个读者需要猜测的程度。

一个可访问的页面，首先是一个更容易被解读的页面。这是一种清晰度优势，而非自动的可见性承诺。

同一页面，四种不同读者

同一个界面会根据阅读者——或什么东西在阅读——暴露不同的信号。

重叠的部分不是"为机器优化"。而是明确的沟通。

诱人的说法——以及有用的机制

语义化 HTML 常常被过度承诺所包裹：

❌ 否：可访问性保证更好的 Google 排名。

✅ 是：可访问性可以使页面在解析、审计和理解上更加健壮。

❌ 否：ARIA 和语义化 HTML 是一种 GEO 策略。

✅ 是：清晰的文档结构支持内容、实体、链接，以及其他系统可用的证据。

❌ 否：有效的标记证明一条用户旅程是无障碍的。

✅ 是：有效的标记为人工测试创建了更强的基础。

实际机制是减少歧义。标题不应需要从大字体中推断。按钮不应需要从图标中推断。数据表不应需要从视觉对齐中重建。

一张看起来没问题但几乎不传达任何信息的卡片

以一个服务卡片为例，包含标题、图标、邮箱字段和提交操作。

<div class="card" onclick="location.href='/audit'">
  <div class="big">Accessibility audit</div>
  <img src="/icon-check.svg">
  <input placeholder="Your email">
  <button><svg><!-- ... --></svg></button>
</div>

有视力的用户可能从布局中重建意图。其他读者的理解则弱得多：

• 视觉上的标题不是真正的标题；
• 卡片像链接一样行为但没有链接语义；
• 图片没有定义的角色；
• 字段没有持久标签；
• 按钮没有可访问的名称；
• 点击行为不等同于清晰的表单提交。

现在让关系变得明确：

<article aria-labelledby="accessibility-audit-title">
  <h3 id="accessibility-audit-title">Accessibility audit</h3>

  <img src="/icon-check.svg" alt="" aria-hidden="true">

  <p>
    Identify keyboard, form, and HTML structure blockers.
  </p>

  <form action="/audit/request" method="post">
    <label for="audit-email">Work email</label>
    <input
      id="audit-email"
      name="email"
      type="email"
      autocomplete="email"
      required
      aria-describedby="audit-email-help"
    >
    <p id="audit-email-help">
      We will use this address only to answer your request.
    </p>
    <button type="submit">Request the audit</button>
  </form>

  <a href="/audit/accessibility">
    Read the accessibility audit method
  </a>
</article>

第二个版本不仅仅是"添加无障碍属性"。它用原生 HTML 描述了内容、动作、目的地和输入关系。

注意它没有做什么：它没有对已经有正确语义的元素添加 ARIA。原生的 HTML 已经承载了大部分模型。

降低结构歧义的九个信号

这不是一份完整的 WCAG 审计。这是一层紧凑的结构层，可以快速暴露薄弱页面。

1. 一致的标题、H1 和标题大纲

浏览器标题、H1 和 H2 应该描述同一个主题。不要用标题元素来获取视觉尺寸，也不要用样式化的 div 元素作为标题。

2. 一个可识别的主区域

对页面的主要内容使用单个 main。在角色真实有用的地方添加原生地标，如 nav、header、footer 和 aside。

3. 在段落之外仍保留含义的链接

"Read the WCAG audit method" 携带了目的地。五个名为"learn more"的链接迫使每个读者重建上下文。

4. 以实际动作为名称的按钮

使用"Open filters"、"Close dialog"或"Submit the audit request"这样的标签。图标可以支持标签，但不应是唯一的意义来源。

5. 基于目的的图片替代文本

信息性图片需要一个传达其所添加内容的替代文本。装饰性图片应使用空的替代文本，并保持在无障碍树之外。

6. 连接到标签、帮助和错误的表单字段

占位符不是标签。连接持久标签和相关帮助文本，并确保错误消息同时识别问题和修正方法。

7. 保留给实际数据的表格

当表格表达比较或数据集时，使用允许单元格无需仅依赖位置就能被理解的标题和标题注脚。不要用表格来做页面布局。

8. 声明的文档语言

lang 属性影响发音、辅助技术、词汇解释和文本处理工具。同样标记页面内部语言的实际变化。

9. 不依赖 CSS 仍保持逻辑的 DOM 顺序

如果页面在 DOM 顺序下阅读时失去含义，设计就隐藏了一个结构弱点。视觉重排序不应产生与源码顺序不同的故事。

20 分钟结构可读性测试

选择一个重要页面——服务页面、注册流程、联系表单或文档条目——并检查以下内容：

这个测试故意很短。它的目的是找出需要深入调查的页面，而不是发布合规声明。

自动化仍然无法证明的事

Lighthouse、axe、WAVE、HTML 验证器和自定义脚本在可重复检查方面表现出色。它们可以报告缺失的标签或未命名的按钮。它们无法可靠地决定：

• 选择的标签对目标用户是否有意义；
• 错误消息是否帮助某人完成表单；
• 标题结构是否反映真实的信息层级；
• 键盘顺序是否匹配任务；
• 图片替代文本是否传达了正确的信息；
• 结构化数据是否准确表示可见的主张。

因此，强大的审查至少结合四层：

• DOM 和无障碍树检查；
• 键盘和辅助技术测试；
• 真实的端到端用户旅程。

自动化提供覆盖范围。人工测试赋予意义。

SEO 和 AI 实际适合的位置

清晰的 HTML 不是通往可见性的捷径。搜索和 AI 可见性取决于许多其他因素：有用性、来源、证据、实体、内部链接、声誉、可索引性，以及选择检索或引用哪些文档的系统。

语义结构准备了一个更低的层。在问一个页面是否值得被排名、提取或引用之前，确保其内容和操作可以在不从头重建的情况下被读取。

有用的问法不是：

"语义化 HTML 会让 AI 引用这个页面吗？"

而是：

"当页面在不依赖其视觉设计的情况下被读取时，会丢失多少含义？"

这个问题为人们首先产生更好的界面——同时为所有其他读者产生更可靠的文档。

AI 协助披露：本 DEV 版本是在我原始 Edikka 文章的基础上，借助 AI 协助进行结构和英文编辑改编而成。技术观点、示例、验证和发布决定仍由我负责。