为什么现在要谈官网无障碍
无障碍（Accessibility，常缩写为 A11Y）在过去被当成"公益项目"，只和盲人有关。这两年它变成了一个很实际的问题：政府采购、国企采购、外企供应商准入，越来越多地把 WCAG 2.1/2.2 AA 写进招标文件；欧盟的 European Accessibility Act 从 2025 年 6 月起对面向消费者的数字服务生效；国内《无障碍环境建设法》2023 年 9 月施行，明确要求政务与公共服务网站提供无障碍版本。
把这些放一边，还有一个更朴素的理由：官网的访问者里有相当一部分并不是"标准用户"。他们可能在通勤路上用单手刷手机，可能在强光下的工地上看屏幕，可能是五十岁以上、把浏览器字号调到 150% 的采购负责人，也可能用读屏软件在核对你的参数表。无障碍做得好，这些人就留得住；做得不好，他们不会投诉，只会关掉页面。
先分清三件事：无障碍、可用性、SEO
三者经常被混为一谈，实际是三条不同的验收线：
| 维度 | 核心问题 | 验收依据 |
|---|---|---|
| 无障碍 | 有障碍的用户能不能完成操作 | WCAG 2.2 AA 的 50 条成功准则 |
| 可用性 | 普通用户完成操作有多费劲 | 任务完成率、耗时、误操作率 |
| SEO | 搜索引擎能不能理解并收录内容 | 索引量、排名、结构化数据校验 |
好消息是三者的技术底座高度重合：语义化标签、图片替代文本、清晰的信息层级、可读的对比度。所以无障碍改造往往顺带把 SEO 和移动端体验一起修了，这也是它性价比最高的地方。
六步落地：从体检到回归
第一步：先跑一遍自动体检，拿到基线分
不要一上来就改代码。先用工具跑一遍，把问题清单化。免费且够用的组合是：
- Lighthouse（Chrome DevTools 内置）：看 Accessibility 分数和具体失败项，适合首页、栏目页、详情页各抽一页。
- axe DevTools 浏览器插件：规则比 Lighthouse 更细，能扫出表单标签缺失、aria 误用这类问题。
- WAVE 在线工具：可视化标注，方便把问题截图发给不写代码的同事。
一个经验值：企业官网首轮自动扫描通常能扫出 30 到 80 个问题，其中六成集中在三类——图片没有 alt、表单控件没有可访问名称、颜色对比度不足。这三类也是最容易批量修的。
需要提醒的是，自动工具最多只能覆盖 WCAG 准则的三到四成。它能告诉你"哪里不合规"，但判断不了"读屏软件读出来是不是一句人话"，所以后面必须有手工验证。
第二步：把语义结构补齐，这是收益最大的一步
语义结构的核心只有一句话：让页面在没有 CSS 的情况下依然读得懂。具体动作：
- 每页只保留一个 h1，且 h1 就是页面主题；h2 用来分节，h3 只在 h2 内部细分，不要为了字号跳级。
- 导航、主内容、页脚分别用 nav、main、footer 包起来；一个页面只有一个 main。
- 列表用 ul/ol，不要用一连串 div 加圆点图标假装列表。
- 表格必须有表头（th）并声明 scope，参数表尤其重要——读屏用户靠表头判断"这一格是什么"。
- 纯装饰性图标加 aria-hidden="true"，功能性图标（比如只有图标的搜索按钮）加 aria-label。
这一步不需要改设计稿，纯前端就能做，通常是整轮改造里投入产出比最高的部分。做完之后你会发现页面的 DOM 结构变清爽了，搜索引擎抓取也更顺。
第三步：把所有"看不见的信息"补上
无障碍的本质是"信息不能只靠一种感官传达"。四类常见缺失：
- 图片：内容型图片写 alt，描述图片承载的信息而不是文件名；装饰图 alt 留空（alt=""），不要省略 alt 属性。
- 视频：提供字幕；有讲解的加文字稿，纯背景视频加 muted 和 aria-hidden。
- 颜色：正文与背景对比度至少 4.5:1，大字号（18pt 以上或 14pt 加粗）可以 3:1；状态不能只靠颜色区分，红色报错旁边要有文字或图标。
- 焦点：键盘 Tab 到任何可操作元素时，必须有可见的焦点框。很多官网为了"好看"全局写了 outline:none，这是最常见也最致命的一处。
对比度可以直接用浏览器 DevTools 的取色器看比值，也可以在设计稿阶段就用插件检查，避免返工。
第四步：把表单做到"错了也知道怎么改"
官网的表单通常就两三个：留言、询盘、订阅。数量少，但问题密集：
- 每个输入框都要有 label，并用 for 与 id 关联；placeholder 不能代替 label，因为它一输入就消失。
- 报错信息要同时做到三件事：说明哪个字段错了、错在哪、怎么改；紧贴字段出现；用 aria-live 让读屏软件读出来。
- 不要用"点击图片验证码"这种纯视觉验证，至少提供语音或短信备选。
- 必填项在 label 里注明，不要只用红色星号——星号对读屏用户是"星号"两个音节。
表单是无障碍改造里唯一直接影响转化的部分。一个读屏用户在你的询盘表单里卡住，损失的是一个真实线索。
第五步：手工验证，别跳过
自动工具跑完、代码改完，必须手工过一遍。最低成本的验证组合：
- 只用键盘：拔掉鼠标，从地址栏开始按 Tab，能不能走完"首页→栏目→详情→提交表单"的全流程，焦点有没有跑丢、有没有掉进看不见的陷阱。
- 系统读屏：Windows 用 Narrator（Win+Ctrl+Enter），macOS 用 VoiceOver（Cmd+F5）。不用成为专家，听三分钟就能发现"这个按钮读出来是 button"这类硬伤。
- 放大到 200%：浏览器缩放 200%，看内容是否被截断、是否出现横向滚动。
- 关掉 CSS：DevTools 里禁用样式，看内容顺序是否仍然合理。
这四项加起来不到一小时，能覆盖自动工具扫不出来的大部分问题。
第六步：写进验收清单，让它不再退化
无障碍最常见的失败不是"没做"，而是"做完三个月又坏了"——新上线的活动页没有 alt，新加的弹窗不能 Esc 关闭。所以要把它变成流程的一部分：
- 在提测清单里加四条：图片 alt 齐全、键盘可走通、对比度达标、表单有 label。
- CI 里挂一个 axe-core 或 pa11y 的自动检查，失败了让构建亮红。
- 每季度用同一套工具复扫一次，和基线分对比。
这样做的好处是成本极低：一次改造的投入，靠流程固化摊薄到后续所有页面。
一个常被忽略的点：无障碍声明页
如果网站面向公共服务或大型企业客户，建议单独做一个"无障碍声明"页面，写清楚：当前符合的等级（如 WCAG 2.2 AA）、已知的不足、反馈渠道、最近一次评估时间。这不是形式主义——它是采购方审核时的必查项，也是出问题时最有效的沟通入口。
常见问题
改造要不要重做网站？
多数情况不需要。语义结构、alt、对比度、表单标签都属于前端层改造，可以在现有站点上分批做，按栏目优先级推进。只有当模板本身把标题层级写死、或者表单是第三方iframe嵌进来的时候，才需要动模板。
要花多久？
一个 50 到 200 页的企业官网，纯前端层面的 AA 改造，通常 3 到 6 周可以完成主体，之后进入回归和流程固化。时间主要花在内容侧（补 alt、补字幕）而不是代码侧。
会不会影响设计效果？
会有一点约束，但不会毁掉设计。对比度、焦点框、字号下限这些是硬边界，其余（布局、留白、动效）都能保留。真正需要改的是那些"浅灰字配白底""图标代替文字"的习惯。
和 SEO 有什么关系？
语义化标签、alt、清晰层级本来就是 SEO 的基础项，改造后通常能看到索引和点击率的正向变化。但无障碍不是排名手段，把它当 SEO 技巧做，很容易做成"给爬虫看的无障碍"，反而失真。
从哪开始
如果只做一件事，先跑 Lighthouse 拿基线分，把"图片 alt + 对比度 + 焦点框"这三类批量修掉——通常一周内能让分数从 60 出头到 85 以上，且几乎不涉及设计改动。剩下的表单、读屏验证、流程固化，再按栏目排期推进。