2026 年电信无障碍法规体系
两个监管机构,两部法规,同一运营界面。
在美国,《21世纪通信与视频无障碍法案》—— CVAA,编纂于 47 U.S.C. § 617——对高级通信服务(ACS)规定了具体的无障碍义务: VoIP、电子消息及可互操作视频会议。这些义务独立于适用公共设施网站的 ADA Title III 一般义务。 请参阅我们的 ADA Title III 指南 了解更广泛的框架——CVAA 是叠加其上的电信专项规定。
FCC 对电信无障碍的执法力度自 2022 年起持续加强。委员会相继出台了 实时文本(RTT)及 IP 网络中传统 TTY 迁移规则;视频中继服务(VRS) 和字幕电话服务(CTS)性能规则;以及手机助听器兼容性(HAC)等级规则。 执法局已公开发布同意令,点名未能满足 RTT 互操作性或无障碍声明提交 要求的运营商——这些文件公开可查,且已被原告律师所关注。
在欧盟, 《欧洲无障碍法案》 从两个方向约束运营商。第 2(2)(b) 条将"电子通信服务"——语音、短信、 基于 IP 的消息——列为适用范围。第 2(2)(c) 条涵盖"具有交互计算能力的 消费者终端设备"——手机、路由器、机顶盒——包括运营商提供的 CPE 及 其配置应用。EN 301 549 是符合性标准,并针对网页和移动端界面引用 WCAG 2.2 AA。
WCAG 2.2 AA 本身仍适用于所有面向客户的网站和移动应用——账单门户、 零售店面、支持知识库、iOS 和 Android 原生应用。CVAA 和 EAA 并不取代 WCAG;它们在网站本身须满足的基准之上叠加电信专项义务。 以下核查清单围绕这一叠加结构设计:每条均以 WCAG 2.2 AA 为基础, 并在适用处注明 CVAA/EAA 专项要求。
电信行业 30 条 WCAG 2.2 AA + CVAA 核查清单
六大界面 × 五项检查。打印、勾选,然后审计。
-
01 账户与服务管理
-
02 账单与支付
-
03 通信服务
-
04 设备与订购
-
05 故障与支持
-
06 网络功能与配额
平台说明——电信行业主要供应商
核查清单在各供应商技术栈中的实际落地情况。
Amdocs / CSG(账单与客户管理)
基于 Amdocs CES 和 CSG Ascendon 构建的自助服务门户,出厂默认配置尚可, 但通常经过大量机构定制。反复出现的问题集中在账单摘要页面(以定位 div 网格 而非语义化表格渲染)和套餐变更向导(步骤缺少 aria-current 标记, 屏幕阅读器用户无法得知当前所在步骤)。两者均可在定制层修复, 无需改动供应商代码。请要求系统集成商提供针对具体部署实例的 VPAT/EN 301 549 符合性报告,而非通用产品报告。
Salesforce Communications Cloud / Oracle Communications(CRM)
基于 CRM 的门户继承 Lightning 或 Redwood 底层框架,基础尚可。 问题出在定制界面——购物车和订单跟踪视图中的 Lightning Web Components 未设置 aria-live 区域;自定义 Apex 页面绕过平台的焦点管理; 社区站点主题覆盖了焦点指示器。须将社区/门户主题与平台分开审计, 并将任何"headless Salesforce"构建视同自定义 React 商店进行审计处理。
Cisco Webex · Microsoft Teams · Zoom Phone(统一通信平台)
统一通信平台发布了各自的 VPAT,并在字幕、ASL 固定和 RTT 支持方面投入 了大量资源——真正需要审计的是嵌入层。运营商品牌化的 Webex/Teams/Zoom 应用在供应商 SDK 外封装了自有外壳,问题往往出在外壳层: 应用内拨号器未宣告通话状态变化、联系人列表以 div 网格渲染、 在线状态指示仅通过颜色传达。供应商无障碍声明可作为底层引擎的参考, 但运营商自有外壳须单独审计。
Twilio · Vonage · RingCentral(CPaaS 界面特性)
CPaaS 供应商提供的仪表盘和可嵌入组件质量参差不齐。仪表盘本身 (Twilio Console、Vonage Dashboard、RingCentral Admin)总体表现尚可。 可嵌入组件——点击通话挂件、视频房间、聊天窗口代码片段——是运营商 和集成商最常出问题的地方。应将任何供应商提供的 JS 嵌入视为第三方 DOM 注入:其渲染在运营商页面上,位于运营商域名下,须承担相应责任, 因此必须依照与自有代码相同的核查清单进行审计。
运营商自研应用(iOS + Android 原生)
原生移动端是 EAA 约束最为严格之处——第 2(2)(c) 条涵盖配置消费者 终端设备的应用,成员国监管机构正在主动审计头部运营商应用。 反复出现的问题包括:无标签的纯图标按钮(Android 缺少 contentDescription, iOS 缺少 accessibilityLabel)、自定义应用内弹窗未捕获焦点,以及 引导轮播从未宣告幻灯片切换。请参阅我们的 移动原生无障碍 API 指南 了解平台专项模式——TalkBack、VoiceOver、Switch Control—— 质量保证团队须在真实设备(而非仅在模拟器)上进行测试。
监测与审计周期
一次性修复无法在运营商发布节奏中持续有效。
运营商资产持续变化。市场团队周二上线费率横幅,OSS/BSS 团队周四推送 账单引擎更新,iOS/Android 原生应用每两周发布一个版本。一次性无障碍修复 大约只能维持到下一次部署——正因如此,能够坚守标准的运营商团队采用 三层防护机制,而非单一层次。
首先,立即针对客户门户、账单流程和故障地图运行 免费 WCAG 2.2 扫描器,建立基准线。 其次,在每次预览构建和每次生产部署时接入持续自动化监测—— 这一层能在问题到达客户(以及 FCC 投诉队列)之前捕获回归。 第三,至少每年委托由残障人士测试人员进行一次 人工审计, 并在任何重大平台迁移后再次进行——账单系统替换 (Amdocs → CSG,或反之)是风险最高的事件,应在上线前而非上线后 委托人工审计。
具体关于监测与人工审计的衔接,我们的 监测采购指南 涵盖处理端到端扫描到审计工作流的平台—— Qualibooth、axe Monitor、 Siteimprove 和 Level Access。针对电信行业,建议重点考量三项标准: 与 CI/CD 的集成(大多数运营商发布流程使用 Jenkins 或 GitLab CI, 而非 GitHub Actions);平台的人工审计测试人员网络是否涵盖 RTT 用户 和以手语为主要沟通方式的用户——并非所有平台都具备这一能力; 以及平台是否在同一仪表盘下同时支持网页和原生移动端审计, 因为门户与应用不能采用各自独立的审计周期。
常见问题
运营商团队在决策前最常提出的问题。
CVAA 是什么?与 ADA 有何关联?
《21世纪通信与视频无障碍法案》(CVAA,47 U.S.C. § 617)是由 FCC 执法的电信专项联邦法规。其适用范围为高级通信服务(ACS)——VoIP、电子消息及可互操作视频会议——以及访问上述服务所用的设备。ADA 是由 DOJ 执法的独立、更广泛的法规,覆盖公共设施网站的一般要求。电信运营商须同时受两部法规约束:CVAA 针对服务本身,ADA Title III 针对面向客户的网站与门店。运营商既需通过 CVAA 专项测试,又须在其网页及移动端界面达到 WCAG 2.2 AA 标准。
运营商是否有义务支持实时文本(RTT)?
在美国,是的。FCC 规则要求无线运营商和手机制造商支持 RTT(47 CFR § 67),作为传统 TTY 的现代替代方案。IP 网络不再需要支持传统 TTY,但必须支持 RTT——且 RTT 链路须实现端到端互通,包括跨运营商及接入公共安全应答点(PSAP / 911)。这是网络和终端设备层面的义务,而非网站义务;但客户门户须按设备和套餐准确披露 RTT 支持情况。
EAA 是否覆盖移动运营商应用?
几乎可以确定。EAA 第 2(2)(b) 条将"电子通信服务"列为适用范围,第 2(2)(c) 条将"具有交互计算能力的消费者终端设备"列为适用范围——欧洲委员会已将此解释为涵盖与终端设备配套的面向客户的移动应用。任何在欧盟销售 SIM 卡、设备或 VoIP 服务的运营商均在适用范围内,须符合 EN 301 549(该标准针对网页和移动端引用 WCAG 2.2 AA),并须依据第 13 条发布无障碍声明。
关于 TTY 支持——目前是否仍有要求?
在 IP 网络中,不再要求。FCC 在 RTT 具备可行性后已废止无线 TTY 要求,运营商现可在 IP 网络中以 RTT 替代 TTY。传统 TDM 电路仍在运营期间,TTY 支持仍被期望保留;但新建网络(5G 语音、VoLTE、VoNR)仅需支持 RTT。客户门户中仍注明"仅支持 TTY"的文案,应更新为"RTT(实时文本)——替代 TTY",并附简短的过渡说明。
如何使故障地图符合无障碍要求?
须满足两个不可缺少的条件。其一,地图本身须具有非装饰性角色和文本替代;无 aria-label 的纯 SVG 画布无法通过 WCAG 1.1.1。其二——更为关键——须以文本列表形式发布相同的故障数据:邮编/区域、状态(已解决/正在排查/已恢复)、受影响服务及预计解决时间。键盘用户、屏幕阅读器用户及低带宽用户均依赖文本列表,而非地图。地图是增强手段,文本列表才是信息的主要来源。
VRS 口译员是否属于运营商的无障碍义务?
视频中继服务(VRS)口译员由 FCC 认证的 VRS 提供商提供,而非运营商直接负责——该服务由联邦电信中继服务(TRS)基金资助。运营商的义务在于:确保其网络和设备与 VRS 互通,客户门户的披露说明须解释 VRS 的可用性,以及运营商自身的支持渠道须为聋人和听力障碍客户提供手语口译员申请途径。口译员的来源安排不属于运营商义务;无障碍的可发现性与互操作性才是运营商的责任。
运营商应多久对客户门户进行一次审计?
自动化扫描应在每次部署时运行——运营商门户每周甚至每日都可能发生变化,未经监测的门户将出现偏差。在此基础上,建议每季度对完整资产(门户、账单、应用、故障地图)进行一次自动化报告,并每年进行一次由残障人士测试人员参与的人工审计,包括 RTT 用户和以手语为主要沟通方式的用户。在任何重大重构或平台迁移后——尤其是账单系统替换(Amdocs、CSG)之后——须在上线前而非上线后委托进行新的人工审计。
三项后续行动
根据运营商团队当前所处阶段,选择最适合的一项。
-
立即运行免费扫描器
针对任意公开 URL 运行 免费 WCAG 2.2 扫描器—— 包括客户门户、账单页面、故障地图。 如尚未建立公开界面的当前基准线,这是最佳起点。
-
对照阅读相关法规
我们的 EAA 指南 和 ADA Title III 指南 详述了各法规对运营商面向客户的网站和应用的具体要求, 以及 CVAA、EAA 第 2 条与 WCAG 2.2 的重叠之处。
-
委托人工审计
阅读我们关于委托 人工审计 的指南——了解应提出哪些要求、应预留多少预算, 以及哪些平台拥有包含 RTT 用户和以手语为主要沟通方式用户的真实测试人员网络, 而哪些平台则依赖外包完成。