必须将可访问性检查嵌入提交前和CI流程：用axe-core配置脚本+husky预提交拦截+GitHub Actions构建失败门禁，并通过html-validate、eslint-plugin-jsx-a11y等工具统一校验alt/ARIA/语义标签，制定Wiki判定标准与MR模板分级规则。
怎么让不同团队写的HTML都通过axe或WAVE可访问性扫描
靠人工检查或口头约定没用，必须把可访问性检查嵌入到提交前和CI流程里。axe-core 和 WAVE 都是检测工具，但它们只报错，不阻止错误代码合入——真正起作用的是把它变成一道门禁。
- 在
package.json里加一条脚本："accessibility:check": "axe *.html --reporter=json --tags=wcag2a,wcag2aa"，确保覆盖所有 HTML 文件 - 用
husky+lint-staged在pre-commit阶段运行该命令；失败则禁止提交，比 Code Review 早一步拦截 - CI 中（如 GitHub Actions）执行相同命令，并把
--exit-code=1加上，让构建失败——别让“暂时忽略”变成默认行为 - 注意：axe 默认不检查内联 SVG 或 Shadow DOM 内容，若项目含这些，得显式加
--include="iframe,svg,*"参数
alt、role、aria-label 这些属性怎么统一写法
不同团队对同一类元素的 ARIA 处理方式常不一致，比如图标按钮有人写 aria-label，有人靠 title，还有人直接不写——结果就是 axe 报一堆 “button has no accessible name”。
- 强制所有
<button></button>必须带aria-label或包裹可读文本（<span>删除</span>），禁用空title或纯<i class="icon-delete"></i> -
<img alt="怎么在多团队协作中统一HTML可访问性规范" >的alt值必须满足：非装饰图 ≠ 空字符串，装饰图 =alt=""，且不允许出现alt="logo"这种无意义值 - 用
eslint-plugin-jsx-a11y（配合eslint）在 JS/TSX 中校验；HTML 模板则靠html-validate配置require-alt-text、require-aria-props规则 - 在模板文件（如
_button.html）里预置带注释的合规写法：<!-- @a11y: icon-only button must have aria-label --><button aria-label="关闭">×</button>
为什么团队总在语义化标签上反复扯皮
不是不想用 <nav></nav>、<main></main>，而是没人定义“什么算导航区”“什么时候该拆出 <section></section>”。没有边界，就只能靠争论解决。
html-to-pptx-converter
下载
使用 PptxGenJS 和 Python 解析，将结构化的 HTML/CSS 幻灯片内容转换为原生、可编辑的 PowerPoint（.pptx）演示文稿。
- 直接在团队 Wiki 里写死判定标准，例如：“连续出现 3 个以上同级链接，且有共同业务意图（如‘常用服务’），必须包在
<nav></nav>里” - 用
html-validate的valid-lang、heading-order、no-redundant-role等规则自动报错，而不是等 CR 时才提 - 禁止在 CSS 中用
[class^="nav-"]替代<nav></nav>——这类选择器会绕过屏幕阅读器的区域识别逻辑 - 特别注意：
<div role="navigation"> 不等于 <code><nav></nav>，前者需手动补全键盘导航逻辑，后者原生支持；团队规范里要明确“优先用语义标签，仅在无法替换时才用 ARIA”表单可访问性最容易被忽略的三个点
表单是可访问性问题高发区，但多数团队只关注 label 是否存在，却漏掉更关键的交互链路。
立即学习“前端免费学习笔记（深入）”；
-
<label for="id"></label>和对应<input id="id">必须严格匹配——大小写、空格、特殊字符都要一致；html-validate可配label-has-for规则自动查 - 错误提示不能只靠颜色区分（如红字），必须用
aria-invalid="true"+aria-describedby="error-id"关联到具体输入框 - 动态加载的表单（如异步弹窗）必须触发
aria-live="polite"区域更新，否则屏幕阅读器不会播报新字段；这个没法靠 lint 工具发现，得靠手动测试 checklist 强制覆盖
实际落地时，最麻烦的不是规则多，而是各团队对“紧急程度”的判断不一致。比如一个
alt缺失，在 A 财务团队算 P0 阻断项，在 B 营销团队可能被标为“下个迭代修复”。解决办法只有一个：把可访问性缺陷分级写进 MR 模板，P0 类（如无 label 的表单控件、缺失 lang 属性）必须修复才能合并，不接受例外。 -
