git blame可快速定位a11y问题源头：执行git blame index.html -l 45,50，精准获取问题行的提交哈希、作者与时间；结合结构化html注释（如）和a11y专用分支规范，实现责任、上下文与修复范围的清晰追溯。
Git 本身不识别可访问性好坏，但配合语义化注释、结构化提交和分支策略，能清晰锁定每次 a11y 修复的范围、责任人和上下文。
怎么用 git blame 快速定位可访问性问题源头
当屏幕阅读器用户反馈“步骤向导跳过了第三步”，别急着改代码——先用 git blame 看那行 <li role="tab"> 是谁、什么时候、为什么加的 role 属性。
- 执行
git blame index.html -L 45,50（假设问题在 45–50 行），直接看到每行最后修改的提交哈希、作者和时间 - 如果附近有注释如
<!-- FIXME: tablist 缺失 aria-label | 提交 a1b2c3d -->，就能立刻关联到对应 commit，跳转查看git show a1b2c3d - 注意：
git blame对重排版敏感。若某次提交只是把<div class="step"> 换成 <code><section aria-labelledby="step2-title"></section>，但没动注释，就容易误判——所以注释必须随语义变更同步更新如何设计 a11y 专用分支与提交规范
把可访问性修复混在功能分支里，等于埋雷：下次
git diff main..feature-login会淹没在 200 行样式改动中，根本看不出哪几处加了aria-describedby。- 为每个 a11y 任务建独立分支，命名带前缀：
a11y/fix-step-nav、a11y/add-alt-to-logo - 提交信息强制包含 WCAG 条款编号，例如：
fix(main): ensure single <main> per page (WCAG 1.3.1)</main>或chore(a11y): bind label to email input (WCAG 3.3.2) - 禁止在 a11y 分支里夹带非相关改动。CI 可配置检查：若提交含
aria-或<main></main>，则要求 commit message 包含WCAG字样，否则拒绝合并
为什么 HTML 注释要写成机器可读格式
人工写的
<!-- 修复了导航菜单的键盘焦点 -->对人有用，但对自动化审计没用；而结构化注释能让脚本自动提取、统计、告警。- 采用固定字段格式：
<!-- a11y: [WCAG 4.1.2] | target: #skip-link | fixed-in: v2.4.1 --> - 配合简单脚本（如 Python + BeautifulSoup）可批量扫描全站 HTML，生成《a11y 修复覆盖率报告》：哪些页面还没加
skip link，哪些img的alt仍为空字符串 - 风险点：注释里不能写分支名（如
branch: a11y/fix-skip-link），因为分支可能被删除或重命名，导致链接失效；应只写已发布的版本号或提交 ID
老旧 HTML 项目做 a11y 迭代最易忽略的兼容陷阱
给一个用了十年的
<table> 布局页面加 <code>role="presentation"很容易，但真正麻烦的是 CSS 选择器耦合。- 原样式可能是
table tr td.title { font-weight: bold; }，你加了role="presentation"后，视觉没问题，但屏幕阅读器会跳过整张表——而开发者以为“加了 role 就万事大吉”，其实该表本该语义化为<dl></dl>或<section></section> - 所有 a11y 修改必须同步检查 CSS：用浏览器开发者工具禁用 CSS 后，再用 VoiceOver 测试，看结构是否仍线性可读；否则所谓“修复”只是障眼法
- 不要依赖
!important强行覆盖旧样式来保视觉——它会让后续用prefers-reduced-motion或高对比度模式的用户彻底失去控制权
- 为每个 a11y 任务建独立分支，命名带前缀：
