大屏投影环境放大HTML语义错误后果：结构错误导致屏幕阅读器忽略landmark、导航失效、标题层级断裂、内容切换无感知；必须确保为直系子元素、含可聚焦项、配精确aria-label、动态更新标题并播报，严禁用CSS或role替代原生语义。
大屏投影环境本身不改变 HTML 语义化的基本规则，但会放大结构错误的后果——投影时字体变大、间距拉宽，视觉线索弱化，而屏幕阅读器（如 NVDA 在投屏 PC 上运行）或语音反馈设备仍完全依赖 DOM 结构。语义标签写错，用户就真“看不见也听不见”。
为什么 <main></main> 嵌套在 <div> 里会导致投影场景下导航彻底失效
<p>投影系统常搭配远程键盘或遥控器操作，用户依赖快捷键（如 <code>Ctrl+Alt+O）跳转到主体内容。<main></main> 若被包裹在框架生成的 <div class="layout"> 或 SSR 渲染的容器中，浏览器不会将其暴露为 landmark，辅助技术直接忽略该节点。
<ul><li>React/Vue 框架默认输出的 DOM 可能是 <code><div id="root"><main>...</main></div>，必须用 CSS display: contents 或 JS 运行时移除外层 <div>，确保 <code><main></main> 是
<main></main>（如 SPA 路由切换后）若未手动触发 document.title 更新和 aria-live 区域播报，用户无法感知内容已切换role="main" 修补——它不替代原生 <main></main> 的 landmark 行为，Lighthouse 和 axe 工具仍报错
<nav></nav> 在投影界面里必须含可聚焦链接，不能只靠视觉样式“看起来像导航”
投影画面中按钮或链接可能因反光、色弱导致视觉不可辨，用户全靠键盘 Tab 导航或语音指令（如 “点击第二个导航项”）。如果 <nav></nav> 里只有 <span>首页</span> 这类无交互能力的元素，读屏器会跳过整个区域。
-
<nav></nav>内部至少一个真实可聚焦元素：<a href="https://www.php.cn/link/8dc3c265ec144154a766774669fa35b8">首页</a>、<button>菜单</button>，或带tabindex="0"的容器（仅当必须用 div 布局时） - 多个
<nav></nav>必须配aria-label，且值具体：“主导航”“页脚资源导航”，而非泛泛的 “Navigation”——语音指令依赖精确名称匹配 - 避免用
<ul></ul>包裹纯文本；投影环境下方向键导航依赖列表隐式语义，<div> + <code>role="list"不保证所有读屏器支持方向键遍历标题层级断裂在大屏上更致命：用户没法靠“扫一眼”补救
小屏用户还能缩放、拖动查看上下文，大屏投影一旦标题跳跃（如
<h1></h1>后直接<h4></h4>），屏幕阅读器报出的“大纲”就断成碎片，用户被迫逐行听读整页——尤其在会议演示、远程协作等高压场景下体验极差。
Wechat Article Html下载将 Markdown 文章转换为微信公众号兼容的纯 HTML 格式。当用户要求"转成微信格式"、"生成公众号文章 HTML"、"排版到微信草稿箱"、"微信粘贴格式"时触发。输出带内联样式的纯 HTML，微信编辑器可直接渲染，无需额外适配。支持标题、段落、列表、粗体、行内代码、表格、引用块、代码块、配图的完整转换。
立即学习“前端免费学习笔记（深入）”；
- 每个页面严格一个
<h1></h1>，代表当前视图核心主题（如 “销售数据看板”），不是 logo 文本 - SPA 页面路由切换后，必须重置标题层级：用 JS 动态修改
document.querySelector('h1').textContent，并触发aria-live="polite"区域播报新标题 - 禁止用 CSS 改变
<h2></h2>外观来模拟<h3></h3>——视觉大小 ≠ 语义层级，投影时字号拉大反而加剧混淆
真正难的不是写对标签，而是让语义在动态渲染、框架封装、多端同步的全流程里不被覆盖或降级。投影环境把“结构即功能”这个事实赤裸地摆出来：DOM 错了，声音就断了，遥控器按了也没反应——没有视觉兜底，错误无处藏身。
- 每个页面严格一个
