HTML语义化在大屏数据可视化系统中的实践应用

大屏系统只能有一个main且不能包导航栏，因为main是辅助技术的语义锚点而非视觉容器，屏幕阅读器按M键跳转时依赖其唯一性；若将状态栏、菜单等导航内容塞入main，会导致跳转失效或行为不可预测，必须由根布局统一控制，仅包裹实时数据卡、图表等核心内容。

为什么大屏系统里只能有一个且不能包导航栏

大屏系统常把整个屏幕当“一张画布”，误以为是视觉上最醒目的那个容器。但它的本质是辅助技术的导航锚点——屏幕阅读器按 M 键直接跳入，跳过所有页头页脚。如果把顶部状态栏、左侧菜单、右下角倒计时都塞进，读屏工具要么只认第一个，要么全忽略，用户得手动听完整屏。

常见错误现象：Next.js 布局组件中重复渲染main；子页面自己又套一层main，导致 DOM 中出现多个；微前端子应用在 iframe 里擅自加main，脱离主文档上下文。

• 正确做法：全 DOM 树中确保唯一main，且只包裹真正要操作/阅读的核心内容（如实时数据卡片区、折线图容器、告警列表）
• 顶部状态栏、左侧设备树、右下角时间戳、底部滚动字幕——这些都不属于main，该用header、aside、footer分而治之
• 若使用 React/Vue 渲染，建议在根布局组件统一控制main出口，子模块禁止自行插入

什么时候该用，什么时候该用

大屏里一堆“实时温度”“设备在线率”“故障分布热力图”，容易一股脑全用section。但section不是div的语义升级版，它是为「有标题的独立逻辑分段」准备的；而article要求内容自包含、可独立分发。

判断依据很实际：

立即学习“前端免费学习笔记（深入）”；

• 这块内容是否自带<h2>–<h6>？没有标题就别套section
• 它能否脱离当前大屏页面被 RSS 抓取或单独推送？能→用article；不能→才考虑section
• 它是否已有专用标签？比如设备列表用table、告警日志用dl，就别再包一层section

错误写法：<section><p>当前在线设备：127台</p></section>——没标题、不可分发、无结构意义，纯属冗余嵌套。

class命名如何避免在大屏项目中失控

大屏系统迭代快、多人协作频繁，.red-alert、.big-num、.box-3 这类类名上线三个月后就失效甚至误导：红色告警变成橙色，大数字改成了小字号，box-3 被挪去显示地图图例。

实操建议：

• 聚焦功能或内容角色，如.device-status-card、.realtime-temperature-chart、.alarm-log-list
• 采用 BEM 规范，模块+元素+修饰符分层，如.dashboard__header、.chart--loading
• 禁止用样式描述词（red、left、big）、缩写、拼音、数字序号

性能影响不大，但可维护性断崖式下跌——改一个颜色，要全局搜red-alert，再逐个判断哪些其实已不是红色。

标题层级断裂比不用语义标签更伤可访问性

很多团队花力气换掉了div，却在标题上翻车：大屏首页从<h2>开始、main外堆了三个<h1>、设备详情页小节用了<h3>但主内容还没出现<h2>。这会让屏幕阅读器生成的文档大纲完全错乱，用户无法靠标题导航到关键区块。

大屏系统特别要注意：

• main内必须有明确的标题层级起点，通常用<h1>（整屏主题）或<h2>（若页面级<h1>已在header中）
• 每个section或article应自带<h2>–<h6>，且层级连续，不跳级、不回退
• 图表标题、告警标题、状态卡片标题，都该是真实h标签，而非仅靠 CSS 加粗模拟

复杂点在于：大屏常含动态加载区块，标题需随数据注入同步更新；容易被忽略的是，服务端渲染或 SSR 场景下，首屏标题结构必须一次性输出完整，不能靠 JS 后补。