# 1 如何理解HTML语义化
⚡ 30 秒速记
- 语义化是用元素表达内容角色，而不是只用
div配样式 - 对用户：辅助技术能识别地标、标题层级和控件含义；对机器：搜索引擎更容易理解页面结构
- 对团队：结构自解释，默认行为和键盘能力也更完整
- 选标签看内容含义，不要为了
SEO滥用h1、article或nav
HTML 语义化就是让标签直接表达内容和控件的角色，而不是所有结构都用 div 拼出来。 例如用 button 做提交控件，会自然获得焦点、键盘操作和读屏器可识别的按钮角色，比 <div onclick> 更完整。nav、标题层级和 article 也能帮助辅助技术、搜索引擎及维护者理解页面结构。纯布局容器仍该用 div，不要为了 SEO 滥用 h1 或 section，能用原生元素时也不应只靠 ARIA 补语义。
语义化的核心是让标签本身携带含义，而不是清一色 div 再靠 class 名去暗示用途。浏览器、搜索引擎和辅助技术读到 <nav> 就知道这是导航，读到 <button> 就知道它可点击、可聚焦、能用回车和空格触发 —— 这些行为是元素自带的，不是你写 JS 补出来的。
三层价值，面试按这个顺序讲：
- 可访问性：读屏器靠语义构建"地标列表"，用户能直接跳到导航或主内容。
<div onclick>在读屏器里就是一段普通文本，键盘Tab也停不上去；换成<button>，焦点、角色、键盘操作三样全都免费拿到。 - SEO：爬虫用标签推断内容权重和结构。
<h1>到<h6>的层级、<article>的边界、<time datetime>的机器可读时间，都会影响索引和摘要展示。 - 可维护性：结构自解释。接手的人看到
<aside>就知道这是次要内容，不用去猜class="box2"是什么。
一个具体对比：
<!-- ❌ 键盘用不了、读屏器读不出、没有 disabled 语义 -->
<div class="btn" onclick="submit()">提交</div>
<!-- ✅ 免费获得：可聚焦、回车/空格触发、disabled 状态、读屏器播报"按钮" -->
<button type="submit">提交</button>
边界 —— 语义化不等于标签越多越好：
- 纯粹为了布局包的容器就该用
div，强行套<section>反而会在辅助技术里多出一堆无名地标。 <section>必须配标题才有意义，没有标题时用div。- 别为了
SEO堆<h1>：一个页面多个h1在HTML5里合法，但标题层级错乱会让大纲失效。 ARIA是补丁不是替代品 —— 官方规则第一条就是"能用原生元素就别用role"，因为role="button"只改了播报，键盘行为还得自己补。
💬 面试官追问
-
提交按钮用
<div onclick>实现，鼠标操作正常，但客服反馈键盘按Tab找不到它；你会怎样改，为什么只补role="button"不够？应优先换成
<button type="submit">，它原生具备焦点、按钮角色、回车与空格触发以及禁用语义。role="button"主要改变辅助技术的播报，不会自动补齐焦点和键盘行为；坚持自定义元素就必须自行实现并长期维护这些交互。 -
内容页为了“更语义化”，开发把每个布局容器都改成没有标题的
<section>；代码评审时你会要求回退哪些部分？纯布局容器以及没有独立主题和标题的区域应回退为
<div>，因为<section>需要表达有标题的内容分区。滥用结构标签会产生无名区域，反而干扰辅助技术理解页面；语义化追求准确含义，不是特殊标签数量。 -
中后台没有公开搜索入口，产品因此认为
<nav>、标题层级和<button>都可以省略；你会用哪些页面角色说明价值？即使不考虑
SEO，键盘用户和读屏器用户仍依赖原生控件、标题层级与地标在复杂后台中移动。开发维护者也能从<nav>、<aside>等结构直接判断职责；但纯布局包装仍应保留<div>，避免为了可读性制造错误语义。 -
文章详情页的读屏器地标列表出现大量无名区域，视觉展示却完全正常；你会按什么顺序排查
HTML？先检查是否存在没有标题的
<section>、重复或错乱的标题层级，以及本应是布局容器却被标成地标的节点。再确认导航、主内容和次要内容的标签是否与职责匹配；视觉正常不能证明语义树正确，修复时也不要靠堆叠ARIA掩盖结构错误。 -
设计系统团队坚持用一个
<div>组件模拟按钮、链接和开关，只通过role切换；你会如何评价这项统一方案？这种统一只减少了表面组件数量，却把每种控件的焦点、键盘操作、禁用状态和播报规则都转成自研责任。应以原生
<button>、<a>等元素作为底座，再统一外观和公共接口；只有原生语义确实无法表达时才谨慎补充ARIA。
