不能。css仅控制样式，无法提供html原生语义；用加css模拟或会导致屏幕阅读器、搜索引擎和键盘导航失能，aria无法补救缺失的默认行为与隐式属性。

不能。CSS 是样式层，不提供语义；用 <div> + CSS 模拟 <code><button></button> 或 <nav></nav>，页面在屏幕阅读器、搜索引擎、键盘导航中会完全失能。

为什么 role 和 ARIA 不能补救纯 CSS 语义缺失

ARIA（如 role="navigation"）只是“告诉”辅助技术“这应该是什么”，但无法替代原生语义标签的默认行为和隐式属性：

• <nav></nav> 自动获得导航地标（landmark），role="navigation" 需手动加且不触发浏览器内置导航逻辑
• <button></button> 原生支持空格/回车触发、:focus-visible、disabled 属性与表单提交绑定；<div role="button"> 全要手写事件和样式模拟 <li>搜索引擎更信任 <code><h1>–<h6></h6> </h1> 的嵌套层级，而非靠 font-size 和 font-weight “看起来像标题”的 <div> <h3>哪些场景下开发者最容易误用 CSS 替代语义</h3> <p>常见于快速原型或“视觉优先”开发，典型表现：</p> <ul><li>用 <code><div class="card"> 包裹内容，却不考虑卡片是否应为 <code><article></article>（独立内容）或 <section></section>（主题分组）
• 导航栏写成 <ul class="nav"></ul>，但没用 <nav></nav> 包裹，导致屏幕阅读器无法识别导航区域
• 表单控件用 <span></span> + contenteditable 模拟输入框，丢失 name、value、validity API 和原生验证提示

display: contents 会破坏语义吗？

会。这个声明让元素自身不生成盒模型，但其子元素直接参与父容器的格式化上下文——同时，该元素的语义也被剥离：

<nav><ul style="display: contents">
<li><a href="/home">首页</a></li>
  </ul></nav>

上面代码中，<ul></ul> 的列表语义（list / listitem 关系）被丢弃，辅助技术可能将所有 <li> 当作孤立项读出，而非有序列表项。正确做法是去掉 display: contents，或用语义正确的结构（如 <nav></nav> 直接包 <a></a>）。

语义不是“锦上添花”，而是 HTML 的底层契约：它决定内容如何被解析、交互、索引和访问。一旦用 CSS 强行覆盖结构意图，修复成本远高于初期选对标签。