企业官网无障碍不是公益加分项，而是一组可测量、可验收的技术指标。设计基线取 WCAG 2.2 AA，验收口径对齐 GB/T 37668-2019，核心落在五件事上：正文对比度 ≥ 4.5:1、全功能键盘可达、焦点可见且不被吸顶元素遮挡、指针目标 ≥ 24×24 CSS 像素、结构与控件具备正确的语义和可访问名称。改造工作量由组件库决定，而不是由页面数量决定。
▲ 无障碍验收的实际场景：页面结构、焦点指示与文字对比度是三个必测面
一、先把定义对齐：无障碍测的是"可计算的工程指标"
很多项目在立项会上把无障碍谈成价值观问题，于是讨论永远停在第十分钟。把它还原成工程语言之后，双方其实只需要对齐三件事：用哪个标准版本、测哪些条目、缺陷到什么等级算不通过。标准是 WCAG 2.2 AA，测试口径是国内政企采购普遍引用的 GB/T 37668-2019，两者在绝大多数条目上重合，差异集中在新版新增的焦点遮挡、最小点击区与免重复输入三条。
一个容易被忽略的前提：无障碍条目里真正需要"人"来判断的只有少数——焦点顺序是否合理、读屏朗读是否通顺、错误提示是否被感知。其余绝大多数是可以用公式和断言判定的，这恰恰是把它写进交付合同的前提。
二、WCAG 2.2 AA 在真实项目里对应哪几条硬指标
把整份准则压缩成一份可执行的检测清单，下面九条覆盖了企业官网约八成的高发缺陷。验收时按这九条逐项留证，比笼统地说"符合 AA 级"要有说服力得多。
| 条款 | 要求 | 检测方法 | 失效高发位置 |
|---|---|---|---|
| 1.4.3 对比度（最低） | 正文文字对比度 ≥ 4.5:1，18pt 以上或 14pt 加粗 ≥ 3:1 | 计算前景/背景相对亮度比 | 品牌色文字、灰色辅助说明、图片上的叠加标题 |
| 1.4.11 非文本对比度 | 控件边界、图标、状态指示 ≥ 3:1 | 取控件与相邻背景计算 | 输入框边框、开关状态、图表图例 |
| 2.1.1 键盘 | 全部功能可仅用键盘完成，无焦点陷阱 | 只用 Tab / Shift+Tab / Enter / 方向键走查 | 自定义下拉、轮播、弹窗、富文本编辑器 |
| 2.4.7 焦点可见 | 键盘焦点必须有可见指示 | 观察到焦点样式被 outline:none 清除 | 全局 reset 样式、按钮 hover 样式覆盖 |
| 2.4.11 焦点不被遮挡（2.2 新增） | 获得焦点的组件不得被作者内容完全遮挡 | 键盘走到页面底部并配合吸顶导航观察 | 吸顶头部、底部浮层、Cookie 提示条 |
| 2.5.8 最小点击区（2.2 新增） | 指针目标至少 24×24 CSS 像素 | 测量可点区域的外接尺寸 | 图标按钮、面包屑、表格内操作链接 |
| 3.3.7 免重复输入（2.2 新增） | 同一流程中已提交信息不得要求重复填写 | 走通多步表单与找回流程 | 多步询盘、报价申请、账号找回 |
| 1.3.1 信息与关系 | 结构用语义标签表达，标题层级不跳级 | 检查 heading 序列与 landmark 区域 | 用 div 堆出来的卡片、伪标题 |
| 4.1.2 名称、角色、值 | 控件有可访问名称与正确角色 | 读屏或可访问性树检查 | 图标按钮无 aria-label、自定义组件 |
九条里有四条属于"一次改组件、全站生效"的类型：对比度、焦点可见、最小点击区、可访问名称。也就是说，判断一个站点改造贵不贵，看的是组件库有没有统一入口，而不是看它有多少个页面。
三、立项阶段最常被问到的五个问题
- 企业官网无障碍是不是只跟盲人用户有关？我们客户群体里几乎没有视障者。
- 无障碍的第一受益群体不是视障者，而是手机小屏用户、中老年用户、强光下的户外用户和只用键盘操作的人。视障者只是测试时最容易暴露问题的一类。真正决定体验的是对比度、点击区大小、焦点顺序和语义结构——这些指标同时影响搜索引擎与 AI 引擎对页面的理解。
- 国内项目按什么标准验收？WCAG 还是国标？
- 国内政企与国企采购通常引用 GB/T 37668-2019《信息技术 互联网内容无障碍可访问性技术要求与测试方法》，其技术条目源自 WCAG 2.0 AA；同时《无障碍环境建设法》自 2023 年 9 月 1 日起施行，把信息无障碍纳入法定义务。实务做法是以 WCAG 2.2 AA 作为设计基线，再按国标条目出具测试报告，两者在绝大多数条目上重合，多做的是 2.4.11 焦点不被遮挡、2.5.8 最小点击区、3.3.7 免重复输入这三条 2.2 新增项。
- 改造要花多少钱？是不是等于重做一遍网站？
- 不是重做。工作量取决于站点是不是组件化模板：同一套组件库改一次，全站继承。真正昂贵的项目往往是因为历史页面由编辑器逐页手工排版，样式内联在正文里，只能逐页修补。评估时先数组件种类而不是数页面数量，结论会完全不同。
- 法务和采购在合同里通常会怎么写？
- 常见写法是把无障碍作为交付验收项，明确标准版本、测试工具、抽检页面范围和缺陷等级处置方式；也有项目写入运维期条款，要求改版或新增模块后重新回归测试。合同不写清楚标准版本，验收阶段就会退化成主观判断。
- 上线以后维护责任归谁？
- 归内容运营与前端模板共同承担。运营侧负责图片替代文本、链接文案、标题层级；技术侧负责组件库、焦点管理、表单错误提示。多数上线后回退并不是代码坏了，而是运营在富文本编辑器里直接粘贴了带内联样式的段落，把对比度和字号一起破坏掉。
四、对比度不是审美问题，是一道除法
相对亮度按 sRGB 通道线性化后加权计算，最终比值是 (L1+0.05)/(L2+0.05)。同一套品牌色，换一个组合就可能从合格掉到严重不合格。下面这张表是像素科学内页视觉体系（主色 #1458E4、强调色 #00C9FF）的实测结果，可以直接当作配色决策的依据。
| 配色组合 | 实测对比度 | 判定 |
|---|---|---|
| #1458E4 底 / #FFFFFF 字 | 5.92:1 | 通过（正文可用） |
| #1458E4 底 / #E6F4FF 字 | 5.29:1 | 通过（正文可用） |
| #1458E4 底 / #B9C6DC 字 | 3.43:1 | 仅通过大字（≥18pt 或 14pt 加粗） |
| #FFFFFF 底 / #1458E4 字 | 5.92:1 | 通过（正文可用） |
| #FFFFFF 底 / #00C9FF 字 | 1.94:1 | 不通过（禁止作正文，只可作装饰） |
| #0B1B3A 底 / #00C9FF 字 | 8.76:1 | 通过（深底青色为最佳组合） |
| #0B1B3A 底 / #8FA6C8 字 | 6.86:1 | 通过（正文可用） |
| #0B1B3A 底 / #FFFFFF 字 | 17.04:1 | 通过（AAA 级） |
五、验收怎么做：自动扫描只是第一段
把验收拆成三段，责任边界才清楚：自动扫描负责可计算项，键盘走查负责交互路径，读屏实听负责语义表达。三段都留证，才算完成一次真正意义上的无障碍验收。
- 自动化工具能查出多少问题？
- 行业内的共识是自动化工具只能覆盖约三到四成的问题，能稳定查出的是对比度、缺失替代文本、表单标签缺失、语言声明缺失、重复 id 这类可计算项；查不出的是焦点顺序是否合理、读屏朗读是否通顺、错误提示是否被感知。所以验收必须是「自动扫描 + 键盘走查 + 读屏实听」三段式。
- 为什么我们的品牌蓝配白字在设计稿上很好看，检测却不过？
- 因为审美判断的是视觉舒适度，标准判断的是亮度差。以像素科学内页主色 #1458E4 为例，与纯白文字的对比度是 5.92:1，正文达标；但同一套视觉里把强调色 #00C9FF 直接用作白底文字，对比度只有 1.94:1，属于严重不合格——青蓝色天生亮度高，只适合做背景块、描边或深底上的文字。设计阶段就要固定一张「允许配色对」清单。
- 键盘用户能不能正常提交询盘表单？
- 关键看三件事：Tab 顺序与视觉顺序一致、焦点框在滚动容器与吸顶导航下不被遮挡（2.4.11）、错误提示出现在焦点所在位置附近并被读屏播报。很多站点的表单在自定义下拉框上就断了——用 div 模拟 select，键盘无法展开，读屏也读不出选项。
- 改造会不会拖慢页面、影响 Core Web Vitals？
- 正确的改造几乎不增加运行时成本，因为它要求的是语义化标签、原生控件和可见焦点，而不是再加一层 JS。反而是「用 JavaScript 补无障碍」的偷懒做法会同时拖慢 LCP 并引入焦点陷阱。经验上，语义化改造往往顺带减少 DOM 节点与脚本体积。
- 改版和新增页面之后怎么保证不回退？
- 把无障碍检查放进发布流水线：模板变更后用 axe-core 跑一遍关键模板，对比度与点击区作为阻断项；同时在设计规范里固化字号阶梯、最小点击区和允许配色表。规则写在设计系统里，回退概率远低于写在文档里。
六、把它写进设计系统，才不会在三个月后回退
无障碍改造最脆弱的地方不在上线当天，而在上线之后的第一次内容更新。富文本编辑器里粘贴一段带内联样式的正文，对比度和字号可以在一分钟内被破坏干净；运营新增一个图标按钮，可访问名称就丢了。可持续的做法只有一条：把约束前置到设计系统与模板层——固定的字号阶梯、固定的允许配色对、组件库统一提供可访问名称与焦点样式、发布流水线跑一遍关键模板扫描。
像素科学在十二年企业官网交付里反复验证的一件事是：任何依赖"人记得"的质量要求都会衰减，只有写进组件与流水线的要求会留下。无障碍如此，性能预算与 TDK 规范同样如此。
