全局可用性必须通过可测量的HTML结构指标落地，如语义标签覆盖率、aria属性缺失率、tabindex异常节点数、lang声明一致性等；需用axe-core扫描DOM并聚合统计违规频次，定向抓取onclick无role/tabindex、img缺alt、lang不合规等高危模式，动态内容须等框架就绪后扫描。
直接说结论：全局可用性不是靠加个 global class 或写个“全站通用”注释就能体现的，它必须通过可测量、可追踪、可回溯的 HTML 结构行为来落地——比如语义标签覆盖率、aria- 属性缺失率、tabindex 异常节点数、lang 声明一致性等硬指标。
怎么把“全局可用性”变成可量化的 HTML 指标
可用性不能停留在“看着像能用”，得拆成浏览器能解析、辅助技术能读取、键盘能遍历的具体行为。常见误判是把“没报错”当成“可用”，但 div 套 div 再加 onclick 的按钮，即使功能正常，对屏幕阅读器就是不可见的。
- 核心指标必须包含：
role与元素默认语义是否冲突（如<button role="link"></button>）、aria-hidden="true"是否误用于焦点元素、alt为空但非装饰性图片 - 工具链要能自动提取：用
axe-core扫描 DOM 后导出 JSON，再用 JS 聚合统计违规类型频次，而非人工点开 DevTools 逐条核对 - 不要只看 WCAG 条款编号（如 1.1.1），要映射到具体 HTML 特征：比如“非文本内容需有替代文本” → 统计所有
<img alt="建立以全局可用性为中心的前端HTML代码质量可视化大屏" >中alt为空或缺失的数量占比
HTML 结构层如何暴露可用性问题
大屏上最该亮红灯的，不是某个图表加载慢，而是整个页面里有 37 个 <div onclick="submit()> 却没加 role=" button> 和 <code>tabindex="0" —— 这类结构缺陷在视觉稿里完全看不见，但会直接卡住键盘用户操作流。
- 用
document.querySelectorAll定向抓取高风险模式：'[onclick]:not([role]):not([tabindex])'、'img:not([alt]):not([aria-hidden="true"])'、'[lang]:not([lang^="zh"]):not([lang^="en"])' - 避免用 class 名判断语义（如
.btn不等于按钮），必须依赖原生标签或显式role；<span class="heading"></span>永远不等于<h2></h2> - 动态生成的内容（如 Vue/React 渲染后）要等框架就绪后再扫描，否则
document.body.innerHTML里还全是占位符，测了也白测
ECharts 图表里的可用性盲区
可视化库默认不处理键盘导航和屏幕阅读器支持，echarts.init() 创建的 canvas 是个黑盒，除非你主动注入 ARIA 层。很多人以为“图表能显示”就算达标，但色觉障碍用户看不到渐变色差，键盘用户点不到图例切换按钮，这些都算可用性故障。
立即学习“前端免费学习笔记（深入）”；
- 必须手动为每个图表容器添加
aria-label，且描述要含数据维度（如aria-label="2024年各季度碳排放量柱状图，单位：万吨"） - 禁用
renderer: 'canvas'时的 SVG 模式（renderer: 'svg'），SVG 元素天然支持focusable和title，比 canvas 更易做语义增强 - 图例交互要用真实
<button></button>替代div+click，否则tab键根本跳不过去
真正难的不是写检测脚本，而是让开发习惯在写第一个 <div> 前就问：这个元素在没有样式的纯文本浏览器里，能被正确识别吗？能被键盘 tab 到吗？能被屏幕阅读器读出上下文吗？大屏上闪红灯的那一刻，问题其实早已埋在三天前那行看似无害的 HTML 里。</div>
