The telecom accessibility regime in 2026
Two regulators, two statutes, one operating surface.
In the United States, the 21st Century Communications and Video Accessibility Act — the CVAA, codified at 47 U.S.C. § 617 — imposes specific accessibility duties on advanced communications services (ACS): VoIP, electronic messaging, and interoperable video conferencing. These duties run independent of the more general ADA Title III duty that applies to public-accommodation websites. See our ADA Title III guide for the broader framework — the CVAA is the telecom-specific overlay on top of it.
FCC enforcement of telecom accessibility has tightened since 2022. The Commission has stood up rules on real-time text (RTT) and the migration off legacy TTY on IP networks; on video relay service (VRS) and captioned-telephone service (CTS) performance; and on hearing-aid compatibility (HAC) ratings for handsets. The enforcement bureau publishes consent decrees naming carriers that have fallen short on RTT interoperability or accessibility-statement filings — these are public, and they are read by plaintiffs' counsel.
In the European Union, the European Accessibility Act binds carriers from two directions. Article 2(2)(b) names "electronic communications services" — voice, SMS, IP-based messaging — as in-scope. Article 2(2)(c) covers "consumer terminal equipment with interactive computing capability" — handsets, routers, set-top boxes — which sweeps in carrier-shipped CPE and the apps that configure it. EN 301 549 is the conformance standard, and it references WCAG 2.2 AA for the web and mobile surfaces.
And WCAG 2.2 AA itself still applies to every customer-facing website and mobile app — billing portal, retail storefront, support knowledge base, native iOS and Android apps. The CVAA and EAA do not replace WCAG; they overlay telecom-specific duties on top of a baseline that you still have to meet for the website itself. The checklist below is structured around that overlay: WCAG 2.2 AA on every row, with CVAA/EAA-specific notes called out where they apply.
30-point WCAG 2.2 AA + CVAA checklist for telecoms
Six surfaces × five checks. Print it, tick it, then audit it.
-
01 Account & service management
-
02 Billing & payments
-
03 Communication services
-
04 Equipment & device ordering
-
05 Outage & support
-
06 Network features & quotas
Platform notes — major telco vendors
Where the checklist actually lands in code, by vendor stack.
Amdocs / CSG (billing & customer management)
Self-care portals built on Amdocs CES and CSG Ascendon ship with workable defaults but heavy agency customisation. The repeat failures are the bill-summary screen (rendered as a positioned div grid instead of a semantic table) and the plan-change wizard (steps without an aria-current marker, so screen-reader users cannot tell which step they are on). Both are fixable in the customisation layer without touching vendor code. Ask your SI for a VPAT/EN 301 549 conformance report on your specific deployment, not on the vanilla product.
Salesforce Communications Cloud / Oracle Communications (CRM)
CRM-anchored portals inherit the underlying Lightning or Redwood baseline, which is decent. The customisation surface is where things break — Lightning Web Components composed without an aria-live region on the cart and order-tracking views, custom Apex pages that route around the platform's focus management, and community-site themes that override the focus indicator. Audit the community/portal theme separately from the platform, and treat any "headless Salesforce" build as a custom React storefront for audit purposes.
Cisco Webex · Microsoft Teams · Zoom Phone (UC platforms)
Unified-comms platforms publish their own VPATs and have invested heavily in captioning, ASL-pin and RTT support — the surface you actually have to audit is the embed. Carrier-branded Webex/Teams/Zoom apps wrap the vendor SDK in your own chrome, and the chrome is where issues land: an in-app dialler that does not announce call-state changes, a contacts list rendered as a div grid, a presence indicator conveyed by colour alone. Lean on the vendor's accessibility statement for the underlying engine, but audit your wrapper.
Twilio · Vonage · RingCentral (CPaaS UI quirks)
CPaaS providers ship dashboards and embeddable components that vary in quality. The dashboards themselves (Twilio Console, Vonage Dashboard, RingCentral Admin) are generally fine. The embeddables — click-to-call widgets, video rooms, chat-window snippets — are where carriers and integrators most often fail. Treat any vendor-provided JS embed as a third-party DOM injection: it has to be audited against the same checklist as your own code, because it renders into your page under your domain and your liability.
In-house carrier apps (native iOS + Android)
Native mobile is where the EAA bite is sharpest — Article 2(2)(c) covers the apps that configure consumer terminal equipment, and member-state regulators are actively auditing the top carrier apps. The recurring failures are unlabelled icon-only buttons (no contentDescription on Android, no accessibilityLabel on iOS), custom in-app modals that do not trap focus, and onboarding carousels that never announce slide changes. See our guide to mobile-native accessibility APIs for the platform-specific patterns — TalkBack, VoiceOver, Switch Control — that your QA needs to test on real devices, not just the simulator.
The monitoring + audit cycle
A one-time fix doesn't survive a carrier release train.
Carrier estates change continuously. Marketing pushes a tariff-banner on Tuesday, the OSS/BSS team ships a billing-engine update on Thursday, and the native iOS/Android apps cut a release every two weeks. A one-time accessibility fix lasts about as long as your next deploy — which is why telecom teams that hold the line do it in three layers, not one.
First, run a free WCAG 2.2 scanner against your live customer portal, billing flow, and outage map today to establish a baseline. Second, plug in continuous automated monitoring against every preview build and every production deploy — this is the layer that catches regressions before they reach the customer (and before the FCC complaint queue does). Third, commission a manual audit by testers with disabilities at least annually, and after any major replatform — a billing-system replacement (Amdocs → CSG, or vice versa) is the highest-risk event and warrants a pre-launch manual audit, not a post-launch one.
For the monitoring + manual-audit handoff specifically, our monitoring buyer's guide covers the platforms that handle the scan-to-audit workflow end-to-end — Qualibooth, axe Monitor, Siteimprove, and Level Access. For telecoms specifically, weight your choice on three criteria: integration with your CI/CD (most carrier release trains are Jenkins or GitLab CI, not GitHub Actions); whether the platform's manual-audit tester network includes RTT users and ASL-first users — not all of them do; and whether the platform supports both web and native-mobile auditing under one dashboard, because your portal and your app cannot be on separate cadences.
FAQ
The questions carrier teams ask before they buy in.
What is the CVAA, and how does it relate to ADA?
The 21st Century Communications and Video Accessibility Act (CVAA, 47 U.S.C. § 617) is a telecom-specific federal statute enforced by the FCC. It applies to advanced communications services (ACS) — VoIP, electronic messaging, interoperable video conferencing — and to the equipment used to access them. The ADA is a separate, broader statute enforced by the DOJ that covers public-accommodation websites generally. Telecom carriers are subject to both: CVAA for the service itself, ADA Title III for the customer-facing website and storefront. A carrier needs to pass the CVAA-specific tests AND meet WCAG 2.2 AA on its web and mobile UI.
Are we required to support real-time text (RTT)?
Yes, in the US. FCC rules require wireless carriers and handset manufacturers to support RTT (47 CFR § 67) as the modern replacement for TTY. Networks no longer have to support legacy TTY, but they must support RTT — and the RTT path must work end-to-end, including across carriers and into the public-safety answering point (PSAP / 911). This is a network-and-handset duty, not a website duty, but your customer portal must accurately disclose RTT support per device and per plan.
Does the EAA cover my mobile-carrier app?
Almost certainly. EAA Article 2(2)(b) names "electronic communications services" as in-scope, and Article 2(2)(c) names "consumer terminal equipment with interactive computing capability" — which the European Commission has interpreted to cover the customer-facing mobile app that pairs with that terminal equipment. Any carrier selling SIMs, devices, or VoIP into the EU is in-scope, must meet EN 301 549 (which references WCAG 2.2 AA for web and mobile), and must publish an accessibility statement under Article 13.
What about TTY support — is it still required?
No, not on IP networks. The FCC sunset the wireless-TTY requirement once RTT became viable, and carriers may now use RTT in place of TTY on IP-based networks. TTY support is still expected on legacy TDM circuits where they remain in service, but new builds (5G voice, VoLTE, VoNR) need only support RTT. Customer-portal copy that still says "TTY-only" should be updated to "RTT (real-time text) — replaces TTY" with a brief migration explainer.
How do I make the outage map accessible?
Two non-negotiable parts. First, the map itself must have a non-decorative role and a text alternative; pure SVG-on-canvas with no aria-label fails WCAG 1.1.1. Second — and more importantly — you must publish the same outage data as a text list: postcode/region, status (resolved / investigating / restored), affected services, estimated time to resolve. Keyboard users, screen-reader users, and users on low-bandwidth connections all rely on the list, not the map. The map is an enhancement; the list is the source of truth.
Are VRS interpreters part of the carrier's accessibility duty?
Video Relay Service (VRS) interpreters are provided through FCC-certified VRS providers, not directly by carriers — and the service is funded by the federal Telecommunications Relay Services (TRS) Fund. A carrier's duty is to ensure its network and devices interoperate with VRS, that customer-portal disclosures explain VRS availability, and that the carrier's own support channels offer an ASL-interpreter request path for deaf and hard-of-hearing customers. The interpreter sourcing is not on the carrier; the discoverability and interoperability are.
How often should a carrier audit its customer portal?
Automated scanning should run on every deploy — carrier portals change weekly, sometimes daily, and an unmonitored portal will drift. Pair that with a quarterly automated report against the full property (portal, billing, app, outage map) and an annual manual audit by testers with disabilities, including RTT users and ASL-first users. After any major redesign or replatform — and especially after a billing-system replacement (Amdocs, CSG) — commission a fresh manual audit before launch, not after.
Three next steps
Pick the one that matches where your carrier team is today.
-
Run the free scanner now
A live free WCAG 2.2 scanner against any public URL — your customer portal, your billing page, your outage map. Best place to start if you have no current baseline against the public surfaces.
-
Read the regulations side-by-side
Our EAA guide and ADA Title III guide cover what each statute requires of carrier-facing websites and apps — and where CVAA, EAA Article 2, and WCAG 2.2 overlap.
-
Commission a manual audit
Read our guide to commissioning a manual audit by testers with disabilities — what to ask for, what to budget, and which platforms include a real tester network with RTT and ASL-first users versus contracting it out.