政务科技与数字福利 ——失业救济门户如何令残障申请人失望
各州失业保险门户、SNAP申请网站、医疗补助资格认定工具，以及社会保障局自身的SSDI前端，是美国社会安全网公开面向用户的核心服务。它们同时也是公共互联网上无障碍性能最差的界面之一。我们对美国人口最多的十个州——加利福尼亚州、德克萨斯州、佛罗里达州、纽约州、宾夕法尼亚州、伊利诺伊州、俄亥俄州、佐治亚州、北卡罗来纳州和密歇根州——运营的主要福利门户，以及联邦身份认证层（Login.gov）和SSA.gov上面向申请人的系统，依据WCAG 2.1 AA级别和2024年4月24日法律约束州及地方政府遵守同等标准的司法部第二章最终规则，进行了全面审计。在审计的十二个界面中，我们共记录了约217个不同的WCAG 2.1 AA故障，平均每个门户约18个，仅有一个门户通过了我们的全部四项关键标准。本档案点名各门户，对其进行排名，并就最差表现者分析司法部规则的含义。
福利门户审计揭示了什么
- 011 / 12
十二个被审计福利门户中，仅有一个通过了全部四项关键标准
我们的四项关键标准：从登录页到提交申请全程可通过键盘操作；屏幕阅读器可读取的错误恢复；会话超时延长功能实际有效；文件上传能够宣告成功或失败。Login.gov是唯一通过全部四项的界面。每个州的失业保险门户至少未通过其中两项。
- 02约217
在十二个界面中记录了不同的WCAG 2.1 AA故障
综合使用axe-DevTools加手动NVDA / VoiceOver / TalkBack对规范申请人流程进行演练：注册、身份认证、提交初始申请、每周认证、上传证明材料、从单次触发错误中恢复。每个门户平均约18个不同故障，范围为6至41个。
- 039 / 10
十个州失业保险门户中有九个在申请人流程中的某处仍提供仅PDF形式的必填表格
最常见的是申诉表格、部分工作周认证表格或求职记录。在这些PDF中，不足一半具有标记PDF结构树；其余为纸质表格的扫描图像，屏幕阅读器无法读取，无视力辅助则无法填写。
- 0411 / 12
十二个门户中有十一个强制执行辅助技术用户无法延长的会话超时
要么完全无警告（会话直接过期，表单将申请人跳转回登录屏幕且所有数据丢失），要么仅以视觉模态框显示警告而无aria-live公告，要么存在键盘焦点永远无法到达的”延长会话”按钮。每个故障均直接违反WCAG 2.2.1（可调整时限）。
- 058 / 12
八个门户呈现无障碍替代方案的CAPTCHA验证
仅含图像的reCAPTCHA v2音频备选功能已损坏，或向申请人展示的hCaptcha没有无障碍cookie路径文档。其中两个——德克萨斯劳动力委员会UI门户和佛罗里达CONNECT门户——将整个初始申请提交流程置于CAPTCHA之后，使盲人申请人无法独立完成申请。
- 06约75%
审计流程中约75%的内联错误信息缺乏aria-live区域或程序性关联
某个必填字段因”格式无效”被拒绝时，字段旁边打印出红色错误信息——但屏幕阅读器从未读出该信息。申请人填写、提交、失败、重新填写、再次失败，却完全不知道哪里出了问题。这是十二个界面中最常见的单一故障模式。
- 072026年4月
大型公共主体于2026年4月24日越过了第一个司法部第二章合规截止日期
服务人口五万及以上的公共主体被要求于该日期前将其网页内容和移动应用提升至WCAG 2.1 AA级别。本次审计中十个州的失业保险门户服务的人口均远超该阈值，且仍不合规——这一态势使其面临依据《联邦法规》第28章第35部分H小节的司法部执法风险。
来源 — 对十二个美国福利门户（10个州失业保险门户 + Login.gov + SSA.gov申请人界面）的专有审计，2026年3月7日至5月12日进行。工具：axe-DevTools Pro 4.10、NVDA 2024.4、VoiceOver（macOS 14.7 + iOS 18.2）、Android 15 TalkBack。方法：对每个门户从空白会话（无先前会话）起演练规范申请人流程；依据WCAG 2.1 AA成功标准记录故障；PDF单独使用PAC 2024和Acrobat Pro进行评估。
01. 方法论与审计关键标准
审计于2026年3月7日至5月12日进行。两名审计员从空白会话出发——无先前cookie、未安装辅助扩展程序、无自动填充——在十二个门户的每一个上演练规范申请人流程。流程为：进入登录页面、注册新账户、身份认证、提交失业救济初始申请（或对SSA和SNAP-医疗补助界面而言，相应的首次申请流程）、到达提交节点，然后认证后续周次或上传证明材料。
每个界面依据WCAG 2.1 AA成功标准，使用axe-DevTools Pro 4.10进行评估，并辅以在Windows 11上使用NVDA 2024.4、在macOS 14.7上使用VoiceOver的手动演练。移动端流程在iOS 18.2上使用VoiceOver以及在Android 15上使用TalkBack重新测试。流程中出现的任何PDF均被单独提取，用PAC 2024和Acrobat Pro DC无障碍检查进行分析。
随后我们应用了四项二元”关键标准”——比完整WCAG阶梯更粗略，但却是在职残障申请人真正关心的标准：键盘可操作性（键盘用户能否完成申请提交？）、屏幕阅读器错误恢复（出现问题时，屏幕阅读器是否宣告问题所在及位置？）、会话超时延长（警告和延长机制是否可通过辅助技术到达并操作？）以及无障碍文件上传（上传成功或失败是否以程序方式宣告？）。仅当界面通过全部四项关键标准时，才视为通过审计。
一个门户可能在其登录页面通过axe扫描，但实际上完全无法使用。残障申请人的流程是端到端的：申请第七步的单个损坏文件上传字段会使整个界面失效。四项关键标准将在职申请人的实际体验压缩为二元结果，使州政府机构可以被追究责任。一个网站要么让屏幕阅读器用户完成申请提交，要么做不到。
02. 逐门户排名
按标准化无障碍分数——流程中通过axe WCAG 2.1 AA测试的页面比例，并按四项关键标准是否通过加权——对十二个界面进行排名，得出下表。Login.gov居首，因为它从设计之初便以无障碍优先的身份认证基础设施为定位，且团队在每次发布时重新测试。SSA.gov的申请人界面居次，因为SSA无障碍系统与技术办公室运行持续监控项目。从第三名往下，与末位的差距陡峭。
Login.gov展示了一个无障碍福利门户的样貌。佛罗里达州CONNECT展示了一个没有视力帮助就无法完成申请的门户的样貌。
03. CAPTCHA陷阱
CAPTCHA关卡是最明显的故障界面，因为它出现在流程早期——通常在注册或登录表单上，有时作为防欺诈措施再次出现在初始申请提交时。十二个被审计门户中有八个提供仅含图像的reCAPTCHA v2验证，其音频备选功能要么已损坏（静默加载，无可播放音频文件），要么将申请人引导至通用404页面。其中两个将整个初始申请流程置于CAPTCHA之后：德克萨斯劳动力委员会UI门户和佛罗里达州CONNECT门户。在那两个州，一位没有视力辅助单独工作的盲人申请人无法从这些界面提交申请。他们不得不致电州政府，而那里的等待时间长达数小时。
政务科技的讽刺之处在于：reCAPTCHA v3——基于行为、不可见、绝大多数用户无需接受任何验证挑战——已经存在，在州门户的使用量级下免费提供，只需半天的集成工作即可解决问题。采购惰性，而非技术难度，使v2验证挑战维持至今。
一个没有可用无障碍替代方案的CAPTCHA，置于州失业救济福利申请之前，是《联邦法规》第28章第35部分H小节旨在禁止的教科书案例。该福利是法定权利；获取由数字界面介入；界面将受保护群体排除在外。依据第二章规则，这不是可用性投诉——而是合规性认定。
04. 无法延长的会话超时
十二个被审计门户中有十一个——每个州的失业保险界面以及SSA的iClaim——在非活跃状态10至20分钟后强制执行会话超时。WCAG 2.2.1（可调整时限）要求，任何时间限制在到期前均可由用户关闭、调整或延长，须至少提前20秒警告，并提供简单的”延长”交互。在这十一个中，三个完全无警告；会话在表单填写过程中直接过期，申请人被退回登录页且所有已输入数据丢失。
另有五个显示视觉倒计时模态框，但从不通过aria-live宣告该模态框，因此正在阅读下方表单的屏幕阅读器用户完全不知道警告已出现。其余三个宣告了模态框，但焦点捕获使得”延长会话”按钮无法通过Tab键到达——在底层表单中按Tab键不会将焦点移至模态框。用户知道警告在那里，却无法对其采取行动。
05. HTML流程中的仅PDF表格
十个州失业保险门户中有九个在流程的某个环节将申请人引导至PDF。最常见的是申诉表格、部分工作周认证、求职记录和受抚养人津贴证明。在提供的PDF中，不足一半具有标记PDF结构树。其余为纸质表格的扫描图像——有时是上世纪90年代的打字机原版模板，经过一次次复印——完全没有文字层。
将扫描图像PDF作为必填表格提供，不是边缘性无障碍缺陷，而是全面排斥。屏幕阅读器报告空白文档。OCR辅助工具失效，因为表单含有OCR层无法重建的字段。申请人只有两个选择：打印、手工填写、扫描回传并发送电子邮件；或拨打机构电话。两个选项都需要打印扫描设备和视力帮助。许多残障申请人两者都没有。
PDF/UA（ISO 14289-1，2012年发布）和标记PDF规范（PDF 1.4，2001年发布）在我们审计的每个州失业保险门户的整个生命周期内均已可用。在活跃福利流程中持续存在扫描图像表格，既不反映技术限制，也不反映成本问题——Adobe Acrobat Pro在几分钟内即可为表格添加标记——而是反映了机构内部的采购和内容治理失败。
06. 无屏幕阅读器反馈的文件上传
十二个门户中有十个在流程中的某处要求文件上传——离职通知、身份证件、医疗证明、SNAP-医疗补助资格文件。在审计中持续不合格的模式是：文件输入元素是原生HTML input，包裹在自定义样式的”选择文件”按钮中，吞噬键盘事件且从不宣告所选文件名，从不宣告上传进度，从不宣告成功，而且（最糟糕的是）从不宣告失败。用户选择文件，发生了什么，无任何宣告。用户继续，不知道上传是否成功——三天后才发现，申请因文件缺失而被拒绝。
整份档案中最廉价的修复方案就在这里。文件输入旁边一个单一的视觉隐藏实时区域，礼貌模式，在选择时和完成时更新文件名和一个单词状态，只需一小时前端工作即可解决整个故障模式。我们在十二个界面中仅看到一个正确实现了这一点。
07. 无aria-live的错误信息
在全部十二个界面中最常见的故障——存在于我们触发的约四分之三错误状态中——是以样式化红色span呈现于输入字段旁边的内联验证错误，既无aria-live区域，也无从输入到错误文本的aria-describedby指针，焦点也无法以编程方式移至错误处。错误是可见的，错误未被宣告。屏幕阅读器用户提交，页面不刷新，用户不知道为何什么都没发生，用户再次提交。
该模式与会话超时故障叠加：残障申请人以人工重读的速度循环处理未宣告的验证错误，触发15分钟超时，表单丢失，重新开始。修复方法是每个错误两行代码——每个字段集附近一个aria-live区域，礼貌模式，在验证程序触发时写入内容。我们审计的界面中没有一个始终如一地做到了这一点。
修复这些门户最昂贵的部分不是工程技术，而是不得不重新开启的采购合同。
08. 司法部第二章执法影响
2024年4月24日司法部第二章最终规则——编入《联邦法规》第28章第35部分H小节——采用WCAG 2.1 AA级别作为州和地方政府网页内容及移动应用的联邦无障碍标准。大型公共主体（人口五万及以上）的合规截止日期为2026年4月24日；较小主体的截止日期为2027年4月24日。本次审计中每个州服务的人口均远超五万的阈值，2026年4月的截止日期已经过去。
该规则提供例外——存档内容、个性化文件、受密码保护的非公开内容、非实体发布的第三方内容——但规范失业申请流程不属于其中任何一类。州UI门户上的初始申请表是现有的、面向公众的、由实体提供的、供公众使用的。它完全处于受监管界面范围内。
第二章执法通过司法部发起的调查（民权司残疾权利科）、在civilrights.justice.gov提交的个人投诉，以及依据同一法规的私人诉讼进行。该规则设想的补救措施包括合规计划、监督协议、对已确认投诉人的补偿性损害赔偿，以及——依据该部门自2014年H&R Block协议以来使用的同意令模式——具有具名WCAG合规目标的全国性修复时间表。欲进一步了解哪些因素特别会引起司法部关注，请参阅我们的配套文章司法部第二章规则，两年回顾。
排名末尾的门户并非无可救药。在Login.gov行之有效的模式——无障碍优先设计、持续监控、采购合同中的具名WCAG合规目标，以及修复积压的单一问责所有者——是州首席信息官可以在单个采购周期内直接采用的模板。政务科技社区已将这一模式公开构建了十年。最暴露的州，是那些尚未采纳它的州。
09. 残障申请人的流程是最糟糕的政务科技用户体验——也是最重要的修复对象
失业从定义上就是一个急性财务压力时刻。申请人没有收入，储备有限，必须在固定窗口内提交申请。非申请人在电商结账遇到问题可以离开，换一家购物。残障失业保险申请人不能。该服务是强制性的，时间是固定的，替代选项是一无所有。
这正是福利门户成为公共互联网上无障碍风险最高界面的原因。我们审计的十个州门户，除两三个例外，目前均不符合2026年4月生效的联邦规则。在该规则存在之前，它们也是美国政务科技中最重要的无障碍失败案例。司法部规则不是让这些门户变得重要的，而是让它们在法律上可追究的。
接下来改变的是执法，而非技术。这些修复——内联错误的aria-live、可聚焦的延长会话控件、标记PDF、宣告的文件上传状态、可用的CAPTCHA备选方案——单独来看都很小，有据可查，并在名单上每家机构的日常维护预算范围之内。一直缺失的是监管压力、政治关注和使修复得以推进的采购合同语言。前者如今已经存在。