92%美国城市官网无障碍不达标：ADA合规现状与改进指南

一场被忽视的数字鸿沟

近日，一个在 Hacker News 上以「Show HN」形式发布的项目引发广泛关注：经过对美国各城市政府官方网站的批量测评，结果显示高达 92% 的城市官网未能通过 ADA（美国残疾人法案）无障碍标准。这一数字虽然来自独立测评，却揭示了一个长期被忽视的现实——在数字化政务高速推进的今天，无障碍访问依然是大多数公共网站的短板。

对于普通用户而言，一个加载缓慢或排版混乱的网站或许只是体验瑕疵；但对于视障、听障、运动障碍或认知障碍人群来说，一个不符合无障碍标准的政府网站，可能意味着他们无法在线缴纳水电费、无法查询公共服务信息、无法参与本应人人平等的公共事务。这不仅是技术问题，更是公平性与合规性问题。

ADA 与 Web 无障碍标准：你需要了解的基础

ADA 的法律背景与适用范围

ADA（Americans with Disabilities Act）是美国 1990 年由老布什总统签署生效的里程碑式法律，是继 1964 年《民权法案》之后最重要的反歧视立法之一，旨在禁止对残障人士的歧视。法案分为五个标题（Title），其中 Title II 约束州和地方政府机构，Title III 约束公共场所和商业实体。

理解 ADA 的分量，需要回溯其诞生的历史背景。1990 年代之前，美国残障人士面临的不仅是身体上的障碍，更有系统性的社会排斥——公共建筑无法进入、就业机会受限、通信设施缺乏适配。ADA 的通过是残障权利运动数十年倡导的结果，其历史积淀远比一部法律深厚。事实上，1973 年《康复法》第 504 条款首次在联邦资助项目中禁止残障歧视，被视为 ADA 的直接前身；1977 年旧金山的「504 坐入」抗议（504 Sit-in）持续 28 天，是美国历史上最长的政府建筑占领行动，为后续立法奠定了社会基础。

值得深入了解的是，这场抗议能够成功，部分原因在于跨运动的社会团结——黑豹党为占领者提供了食物和后勤支援，确立了「残障即公民权利」而非「残障即医疗问题」的基本叙事框架，直接塑造了此后 ADA 的立法逻辑。抗议者最终迫使时任卫生、教育和福利部长 Joseph Califano 签署了迄今最强硬的残障权利执行细则，证明了持续的公民行动能够改变制度性障碍。

这一背景引出了 ADA 立法前夕最具象征意义的行动——著名的「爬行抗议」（Capitol Crawl）：1990 年 3 月，数百名残障活动人士放弃轮椅，用手和膝盖爬上国会大厦的 83 级台阶，其中包括年仅 8 岁、患有脑性麻痹的 Jennifer Keelan，她的画面被媒体广泛传播，直接推动了法案数月后的通过。这一事件在美国残障权利运动史上具有深远的符号意义：国会议员正在建筑内讨论一部关于无障碍的法案，而残障人士却无法进入这栋建筑本身，这种强烈的反差成为推动立法的道德催化剂——任何一位目睹画面的立法者都无法回避「我们正在讨论的问题此刻就发生在门外」的现实压力。Capitol Crawl 的历史意义还在于，它将抽象的权利诉求转化为无可回避的具体画面，这也是残障权利运动此后在倡导策略上广泛借鉴的传播逻辑。这一历史背景揭示了 ADA 不仅是技术合规框架，更是一部承载社会公平承诺的基础性法律。

在早期司法实践中，"公共场所" 主要指实体空间，但随着互联网渗透率提升，2010 年代起法院开始将网站纳入 ADA 管辖范围。2022 年，美国司法部明确发布指导意见，确认网站无障碍属于 ADA Title II 的合规要求。与此同时，针对网站无障碍的诉讼数量呈爆发式增长——仅 2023 年就超过 4000 起联邦诉讼，政府机构、零售商、医疗机构均是高频被告。政府网站因其公共服务属性，法律约束力被认为尤为明确，合规压力也持续攀升。

WCAG 技术规范详解

在具体技术层面，业界普遍采用 WCAG（Web Content Accessibility Guidelines） 作为衡量标准。WCAG 由万维网联盟（W3C）下属的 Web 无障碍倡议（WAI）工作组制定，经历了从 1.0（1999 年）、2.0（2008 年）、2.1（2018 年）到 2.2（2023 年）的持续演进，通常要求达到 AA 级。

WCAG 的诞生有其深刻的历史脉络。1994 年，Tim Berners-Lee 创立 W3C 时便将「让所有人都能使用网络」列为核心愿景。WAI 工作组于 1997 年成立，其成员不仅包括技术专家，还有残障用户代表和辅助技术厂商。

从版本演进来看，WCAG 1.0 以 HTML 技术特性为导向，规则高度依赖特定技术实现，随 Web 2.0 和 Ajax 应用兴起迅速过时。WCAG 2.0 的关键创新是引入「技术无关性（Technology Neutrality）」原则——成功标准描述用户能够实现的目标，而非规定具体的 HTML 标签或 CSS 属性写法。这一原则产生了深远影响：标准得以在 HTML5、CSS3、React、Vue 等技术栈迭代中保持稳定，不随框架更迭而失效；同时，由于成功标准具备明确的可测试性，配套发布的「技术文档（Techniques）」将每条标准映射为具体的代码模式，使得自动化检测工具的大规模普及成为可能——axe、WAVE 等工具的规则引擎，本质上是对这些可编程验证的成功标准的系统性实现。WCAG 2.1 新增 17 条成功标准，重点覆盖移动端触控交互和低视力场景；WCAG 2.2 在 2023 年进一步新增了若干关注认知障碍的标准，例如「焦点不被遮挡（Focus Not Obscured）」和「拖拽动作替代（Dragging Movements）」，标志着行业关注边界从视障场景持续向认知障碍和运动障碍扩展。目前 WCAG 3.0 的早期草案已在讨论中，拟引入评分制替代当前的通过/失败二元判定，以更细腻地反映实际用户体验。

WCAG 设有三个合规等级（A、AA、AAA）：A 级涵盖最基础的要求（如图片必须有 alt 属性）；AA 级在此基础上增加了色彩对比度至少 4.5:1、文本可缩放至 200% 不丢失功能等约束；AAA 级则包含如手语视频翻译等较为严苛的要求，在实际工程中通常被视为可选增强。当前业界和法规普遍要求的正是这一中间层——AA 级。

WCAG 的核心原则可概括为四点：

可感知（Perceivable）：为图片提供替代文本，为音视频提供字幕；
可操作（Operable）：确保键盘可完全导航，避免仅依赖鼠标；
可理解（Understandable）：清晰的表单标签与错误提示；
健壮性（Robust）：兼容屏幕阅读器等辅助技术。

92% 的不达标率，往往并非某一项极端缺陷导致，而是大量网站在这些基础要求上普遍存在积累性的小问题——缺失的 alt 属性、对比度不足的文字、无法键盘操作的菜单、未标注的表单字段等。

政府网站无障碍问题为何如此普遍

技术债与长期维护缺位

"技术债"（Technical Debt）是软件工程师 Ward Cunningham 提出的隐喻：就像金融债务会产生利息，开发过程中为追求短期目标而采取的妥协方案，会在未来造成持续的维护成本。政府网站的无障碍技术债尤为典型。

许多城市官网建立于 2000 年代初期，采用老旧的 CMS 系统（如早期的 Drupal、Joomla 乃至各类定制系统），彼时均未将无障碍输出纳入模板默认行为。这意味着哪怕今天的内容编辑有良好意识，底层主题生成的 HTML 结构也可能天然不合规。加之政务系统更换周期长（通常 5–10 年），采购合同中往往也未将 WCAG 合规列为验收指标，问题由此长期堆积。

政府网站的采购机制本身也是滋生技术债的温床。美国地方政府通常遵循严格的政府采购法规，项目必须经过公开招标，中标往往以最低价为导向而非质量优先。根据美国政府问责局（GAO）2019 年报告，联邦政府约 80% 的 IT 支出用于维护老旧遗留系统，地方政府情况更为严峻。

尤其值得关注的是合同周期的设计缺陷。典型的政务网站合同包含「建设期」和「保障期」两个阶段，保障期通常仅覆盖安全补丁和 bug 修复，并不包含功能迭代或合规更新。当 WCAG 从 2.0 升级至 2.1、2.2 时，合同中若无明确条款，承建商没有法律义务跟进标准更新。这种「建完即走」的合同模式，加之政府换届导致的优先级重置，使得无障碍合规维护在制度设计层面就缺乏持续驱动力。承建商在合同期内交付网站后，长期维护责任模糊，缺乏持续改进的激励机制。加之市政 IT 部门人手普遍不足，波士顿大学的一项研究显示，美国小城市平均 IT 人员配置不足 5 人，既要维护内部系统，又要管理对外网站，无障碍合规自然沦为低优先级事项。

近年来，美国联邦政府发布了《21 世纪综合法案》（21st Century IDEA Act，2018 年），要求所有联邦机构的新建和改版网站满足 WCAG 2.0 AA 标准，并采用以用户为中心的设计方法，但执行细则的落地进展参差不齐，州和市级政府的约束力度更是参差不齐。对比之下，欧盟的《网络无障碍指令》（Web Accessibility Directive，2016 年）对成员国公共部门网站设定了硬性合规期限，并要求定期发布无障碍声明和反馈机制，执行力度相对更为统一——这也是此次批量测评中城市官网问题集中的结构性原因。

缺乏自动化检测意识

无障碍问题有一个显著特点——「不测就看不见」。目前最主流的自动化工具包括：axe（由 Deque Systems 开发，同时作为底层引擎集成进 Chrome DevTools）、Lighthouse^广告（Google 开发的综合性网页质量分析工具，无障碍模块同样基于 axe-core）、WAVE（由 WebAIM 开发，以可视化方式直接在页面上标注问题位置）。这些工具通过对 DOM 结构进行静态分析，检查 ARIA 属性、颜色对比度、表单标签关联等可编程验证的规则。

深入了解这些工具的技术原理，有助于理解其检测边界。axe-core 的设计哲学强调极低的误报率——它选择只报告「确定违规」，将「最佳实践建议」和「需要人工判断」的项目单独分类，避免开发者被噪音信息淹没。更重要的是，axe-core 在浏览器运行时访问实时 DOM（而非静态 HTML 源码），能够捕获 JavaScript 动态渲染后的状态，这对 React、Vue 等现代框架构建的 SPA（单页应用）尤为重要。WAVE 则采用「就地可视化」策略，直接在页面上叠加图标标注，帮助内容编辑（而非仅是开发者）识别问题位置，大幅降低了工具的使用门槛。

要深入理解这些工具所检测的问题为何重要，还需要了解辅助技术的运作生态。屏幕阅读器（Screen Reader）是视障用户最核心的辅助工具，其工作原理涉及三个层次的协同：操作系统无障碍 API（Windows 的 UI Automation、macOS 的 NSAccessibility API）将应用程序状态暴露为可查询的结构化数据；浏览器基于 DOM 和 ARIA 标注构建「无障碍树（Accessibility Tree）」，作为网页内容与操作系统 API 之间的桥梁；屏幕阅读器最终通过调用操作系统 API 读取无障碍树，将节点信息转化为语音输出或盲文点显器的触觉反馈。

无障碍树本身值得特别关注。浏览器在构建无障碍树时，会过滤掉纯视觉装饰性内容（如 aria-hidden="true" 的元素），只保留对辅助技术有意义的节点和属性。Chrome DevTools 的 Elements 面板中可直接查看任意元素对应的无障碍树节点，这是调试屏幕阅读器行为最直接的入口。理解无障碍树的关键在于，屏幕阅读器「看到」的网页与视觉用户「看到」的完全不同——一个嵌套三层 div 模拟的按钮，在无障碍树中可能呈现为无语义的通用容器，屏幕阅读器无从得知它是可交互元素，用户也因此无法与之交互。

主流屏幕阅读器产品包括 Windows 上的 NVDA（免费开源）和 JAWS（商业付费）、macOS 与 iOS 的 VoiceOver（系统内置），以及 Android 的 TalkBack。根据 WebAIM 年度调查，NVDA 和 JAWS 合计桌面端市场份额长期超过 60%。值得注意的是，不同屏幕阅读器对同一 HTML 结构的解析行为存在差异，JAWS 和 NVDA 在处理复杂 ARIA 组件时可能给出不同的语音输出，这意味着仅针对一种工具测试并不充分。

ARIA（Accessible Rich Internet Applications）规范（当前版本 WAI-ARIA 1.2）定义了 role、aria-label、aria-describedby 等属性，作为 HTML 原生语义的补充桥梁，允许开发者为自定义组件赋予屏幕阅读器可识别的语义角色。然而，ARIA 的使用也存在「越描越乱」的风险——错误的 ARIA 属性叠加往往比完全不使用 ARIA 更糟糕，因此 W3C 专门发布了「ARIA 实践指南（APG）」提供最佳实践模板，并附有键盘交互模式的参考实现。当网站缺少 alt 属性、表单无 label 关联，或使用非语义化的 div 元素模拟按钮时，屏幕阅读器要么播报出毫无意义的信息（如将按钮读成「div div div」），要么完全跳过关键交互元素，导致用户陷入信息黑洞，无法完成任何实质性操作。

开发者若不主动使用上述工具进行扫描，很难在日常开发中发现这类缺陷。此次批量测评项目的价值恰恰在于：把「隐形」问题量化、可视化，用一个刺眼的 92% 唤起公众和决策者的重视。

理性看待测评方法的局限

需要客观指出的是，自动化检测工具天然存在局限：它无法判断图片的 alt 描述是否语义准确、键盘焦点顺序是否在逻辑上合理、屏幕阅读器播报内容是否存在歧义。这些语义层面的问题，必须结合辅助技术进行人工审查，以及纳入真实残障用户的测试。业界普遍接受的数据是，自动化工具能捕获约 30%–40% 的 WCAG 2.1 AA 问题。

因此，92% 的失败率来自自动化扫描，它能有效反映「基础问题的普遍性」，但不应被解读为「所有网站都完全不可用」。这个数字更适合作为警示信号，而非绝对结论。

开发者与政务机构的无障碍改进路径

将无障碍检测左移至开发早期

"左移"（Shift Left）是 DevOps 领域的重要理念，指将测试和质量检查尽早引入开发生命周期的早期阶段，而非等到上线前才进行。在无障碍领域，左移意味着：在设计阶段使用 Figma 插件（如 Stark、Able）检查色彩对比度；在开发阶段集成 axe-core 的 ESLint 插件（如 eslint-plugin-jsx-a11y）即时提示违规；在 CI/CD 流水线中，通过 cypress-axe、playwright-axe 等框架，在每次 Pull Request 合并时自动对关键页面运行无障碍扫描，在单元测试阶段则可借助 jest-axe 对组件渲染结果直接运行 axe 规则检测。

「左移」理念在无障碍领域的落地，近年来随着「无障碍即设计系统」的趋势而加速。Shopify 的 Polaris、IBM 的 Carbon Design System、微软的 Fluent UI 等主流设计系统，均已将 WCAG AA 合规内置为组件的默认属性，开发者使用这些组件构建界面时，底层的 ARIA 角色、键盘交互模式、焦点管理逻辑已自动满足规范要求。这代表了行业对无障碍问题的一种系统性解法：与其在每个项目中从零开始解决相同的合规问题，不如将最佳实践固化在可复用的基础设施层，从而将单次无障碍工程投入转化为覆盖所有下游产品的持续收益。然而，设计系统并非万能的银弹——错误的组件组合、自定义覆盖样式（尤其是对 outline 属性的清除，会直接破坏键盘焦点可见性）或不当的 ARIA 属性叠加，依然可能破坏原有的无障碍特性。设计系统团队与业务开发团队之间持续的知识传递，是确保这一机制真正奏效的关键。

这也引出了组织文化层面更本质的挑战。Deque Systems 的研究表明，在从未接受过无障碍培训的开发团队中，即便引入全套工具，问题修复率也仅提升约 15%；而结合系统性培训的团队，修复率可达 70% 以上。Google 的「无障碍工程师嵌入（Accessibility Engineer Embedding）」项目，将专职无障碍工程师分配至各产品团队而非集中于单独部门，被认为是推动文化转变最有效的组织设计之一。IBM 的研究则估算表明，在问题的「出生地」修复，成本比上线后修复低约 100 倍。这套机制的建立需要将无障碍合规明确写入开发规范和供应商合同，否则仍会在采购新系统时重蹈覆辙。

按优先级分阶段修复存量问题

对于存量网站，与其追求一次性完全达标，不如按影响优先级分阶段推进：优先解决键盘导航、表单标签、图片替代文本（alt 属性）、颜色对比度等高频且影响面广的问题，快速提升可用性基线。

将无障碍视为产品质量标准

值得强调的是，无障碍优化往往对所有用户都有益。清晰的页面结构、良好的色彩对比度、支持键盘操作的界面，同样能提升普通用户的体验，并有助于 SEO 排名与页面性能。把无障碍当作产品质量的组成部分，而非额外负担，才是可持续的长远之道。

结语

这个 Show HN 项目本身规模不大，但它触及的问题极具现实意义。当政府服务全面迁移至线上，Web 无障碍就不再是「加分项」，而是公共服务平等的底线。92% 的不达标率提醒我们：技术的进步不应把任何人挡在门外。对于每一位开发者而言，认真写好一行 alt 文本、修复一个键盘焦点问题，或许就是为更包容的数字世界铺平道路的一小步。