Het telecomtoegankelijkheidsregime in 2026
Twee toezichthouders, twee wetten, één operationeel vlak.
In de Verenigde Staten legt de 21st Century Communications and Video Accessibility Act — de CVAA, gecodificeerd in 47 U.S.C. § 617 — specifieke toegankelijkheidsverplichtingen op aan geavanceerde communicatiediensten (ACS): VoIP, elektronische berichten en interoperabele videoconferentie. Deze verplichtingen staan los van de algemenere ADA Title III-verplichting die van toepassing is op websites van publieke accommodaties. Zie onze ADA Title III-gids voor het bredere kader — de CVAA is de telecomspecifieke bovenlaag daarboven.
De FCC-handhaving van telecomtoegankelijkheid is sinds 2022 aangescherpt. De Commissie heeft regels ingevoerd over realtime-tekst (RTT) en de migratie van verouderd TTY op IP-netwerken; over de prestaties van video relay service (VRS) en captioned-telephone service (CTS); en over scores voor gehoorapparaatcompatibiliteit (HAC) voor handsets. Het handhavingsbureau publiceert consentdecreten met namen van aanbieders die tekortschoten in RTT-interoperabiliteit of het indienen van toegankelijkheidsverklaringen — deze zijn openbaar en worden gelezen door advocaten van eisers.
In de Europese Unie bindt de Europese Toegankelijkheidsakte aanbieders vanuit twee richtingen. Artikel 2(2)(b) noemt "elektronische communicatiediensten" — spraak, sms, IP-berichten — als in-scope. Artikel 2(2)(c) bestrijkt "consumenteneindapparatuur met interactieve rekencapaciteit" — handsets, routers, settopboxen — wat aanbiedersgeleverde CPE en de apps die deze configureren, omvat. EN 301 549 is de conformiteitsstandaard en verwijst naar WCAG 2.2 AA voor de web- en mobiele vlakken.
En WCAG 2.2 AA zelf blijft van toepassing op elke klantgerichte website en mobiele app — factureringsportaal, winkelfront, kennisbank voor ondersteuning, native iOS- en Android-apps. De CVAA en EAA vervangen WCAG niet; ze leggen telecomspecifieke verplichtingen bovenop een basislijn waaraan u nog steeds moet voldoen voor de website zelf. De onderstaande checklist is gestructureerd rondom die bovenlaag: WCAG 2.2 AA op elke rij, met CVAA/EAA-specifieke aantekeningen waar van toepassing.
30-punten WCAG 2.2 AA + CVAA checklist voor telecoms
Zes onderdelen × vijf controles. Afdrukken, aanvinken, dan auditen.
-
01 Account- en servicebeheer
-
02 Facturering en betalingen
-
03 Communicatiediensten
-
04 Apparatuur en toestellen bestellen
-
05 Storingen en ondersteuning
-
06 Netwerkfuncties en quota
Platformaantekeningen — grote telecomleveranciers
Waar de checklist in de praktijk neerkomt in code, per leveranciersstack.
Amdocs / CSG (facturering en klantbeheer)
Selfserviceportalen gebouwd op Amdocs CES en CSG Ascendon worden geleverd met werkbare standaardinstellingen maar met zware aanpassingen door bureaus. De terugkerende problemen zijn het factuuroverzichtscherm (weergegeven als gepositioneerd div-grid in plaats van een semantische tabel) en de wizard voor planwijziging (stappen zonder aria-current-markering, waardoor schermlezers niet kunnen bepalen in welke stap de gebruiker zich bevindt). Beide zijn herstelbaar in de aanpassingslaag zonder de leverancierscode aan te raken. Vraag uw SI om een VPAT/EN 301 549-conformiteitsrapport voor uw specifieke implementatie, niet voor het standaardproduct.
Salesforce Communications Cloud / Oracle Communications (CRM)
CRM-gebaseerde portalen erven de onderliggende Lightning- of Redwood-basislijn, die redelijk is. Het aanpassingsvlak is waar problemen ontstaan — Lightning Web Components samengesteld zonder aria-live-regio in de winkelwagen- en ordertrackingweergaven, aangepaste Apex-pagina's die het focusbeheer van het platform omzeilen, en communitysite-thema's die de focusindicator overschrijven. Auditeer het community-/ portaalthema apart van het platform en behandel elke "headless Salesforce"-implementatie als een aangepaste React-winkelfront voor auditdoeleinden.
Cisco Webex · Microsoft Teams · Zoom Phone (UC-platforms)
Unified-commsplatforms publiceren hun eigen VPAT's en hebben fors geïnvesteerd in ondertiteling, ASL-vastzetten en RTT-ondersteuning — het vlak dat u daadwerkelijk moet auditen is de ingebedde wrapper. Aanbiedersgebrandmerkte Webex/Teams/Zoom-apps wikkelen de leverancier-SDK in uw eigen schil, en de schil is waar problemen optreden: een ingebouwde kiezer die oproepostatuswijzigingen niet aankondigt, een contactenlijst weergegeven als div-grid, een aanwezigheidsindicator die alleen via kleur wordt overgebracht. Vertrouw op de toegankelijkheidsverklaring van de leverancier voor de onderliggende engine, maar auditeer uw eigen wrapper.
Twilio · Vonage · RingCentral (CPaaS UI-eigenaardigheden)
CPaaS-aanbieders leveren dashboards en insluitbare componenten van wisselende kwaliteit. De dashboards zelf (Twilio Console, Vonage Dashboard, RingCentral Admin) zijn doorgaans in orde. De insluitbare componenten — click-to-call-widgets, videoruimten, chatvenstersnippets — zijn waar aanbieders en integratoren het vaakst tekortschieten. Behandel elke door een leverancier geleverde JS-inbedding als een DOM-injectie van derden: die moet worden geauditeerd op dezelfde checklist als uw eigen code, omdat het op uw pagina wordt weergegeven onder uw domein en uw aansprakelijkheid.
Ingebouwde aanbiedersapps (native iOS + Android)
Native mobiel is waar de EAA het scherpst bijt — artikel 2(2)(c) bestrijkt de apps die consumenteneindapparatuur configureren, en toezichthouders van lidstaten auditen actief de belangrijkste aanbiedersapps. De terugkerende problemen zijn icoon-only knoppen zonder label (geen contentDescription op Android, geen accessibilityLabel op iOS), aangepaste in-app modals die de focus niet vasthouden, en onboardingcarrousels die diawijzigingen nooit aankondigen. Zie onze gids over native toegankelijkheids-API's voor mobiel voor de platformspecifieke patronen — TalkBack, VoiceOver, Switch Control — die uw QA-team op echte apparaten moet testen, niet alleen op de simulator.
De monitoring- en auditcyclus
Een eenmalige fix overleeft de releaseketen van een aanbieder niet.
Aanbiedersomgevingen veranderen continu. Marketing plaatst een tariefbanner op dinsdag, het OSS/BSS-team levert een factureringssysteemupdate op donderdag, en de native iOS/Android-apps brengen om de twee weken een release uit. Een eenmalige toegankelijkheidsfix gaat ongeveer net zo lang mee als uw volgende deploy — daarom houden telecomteams die de lijn vasthouden dit in drie lagen bij, niet in één.
Gebruik eerst een gratis WCAG 2.2-scanner op uw live klantenportaal, factureringsproces en storingskaart om een basislijn vast te stellen. Sluit daarna continue geautomatiseerde monitoring aan op elke preview-build en elke productiedeploy — dit is de laag die regressies opvangt voordat ze de klant bereiken (en voordat de FCC-klachtwachtrij dat doet). Laat ten derde minimaal jaarlijks een handmatige toegankelijkheidsaudit uitvoeren door testers met een beperking, en na elke grote migratie — vervanging van een factureringssysteem (Amdocs → CSG of omgekeerd) is het hoogste-risicogebeurtenis en rechtvaardigt een handmatige audit vóór de livegang, niet erna.
Voor de overdracht van monitoring naar handmatige audit specifiek behandelt onze monitoringkoopersgids de platforms die de workflow van scan naar audit end-to-end afhandelen — Qualibooth, axe Monitor, Siteimprove en Level Access. Voor telecoms specifiek weegt u uw keuze op drie criteria: integratie met uw CI/CD (de meeste aanbiedersreleaseketen draaien op Jenkins of GitLab CI, niet GitHub Actions); of het handmatige-audittesternetwerk van het platform RTT-gebruikers en gebruikers voor wie gebarentaal de voorkeurstaal is omvat — niet alle platforms doen dat; en of het platform zowel web als native-mobiel auditen onder één dashboard ondersteunt, omdat uw portaal en uw app niet op aparte cadansen kunnen zitten.
Veelgestelde vragen
De vragen die aanbiedsteams stellen voordat ze akkoord gaan.
Wat is de CVAA en hoe verhoudt die zich tot de ADA?
De 21st Century Communications and Video Accessibility Act (CVAA, 47 U.S.C. § 617) is een telecomspecifieke federale wet die door de FCC wordt gehandhaafd. De wet is van toepassing op geavanceerde communicatiediensten (ACS) — VoIP, elektronische berichten, interoperabele videoconferentie — en op de apparatuur die voor toegang daartoe wordt gebruikt. De ADA is een aparte, bredere wet die door het DOJ wordt gehandhaafd en websites van publieke accommodaties in het algemeen bestrijkt. Telecomaanbieders vallen onder beide wetten: de CVAA voor de dienst zelf, de ADA Title III voor de klantgerichte website en winkel. Een aanbieder moet de CVAA-specifieke tests doorstaan ÉN voldoen aan WCAG 2.2 AA op de web- en mobiele UI.
Zijn wij verplicht realtime-tekst (RTT) te ondersteunen?
Ja, in de VS. FCC-regels verplichten draadloze aanbieders en handsetfabrikanten RTT te ondersteunen (47 CFR § 67) als moderne vervanger van TTY. Netwerken hoeven verouderd TTY niet meer te ondersteunen, maar moeten RTT ondersteunen — en het RTT-pad moet end-to-end werken, ook tussen aanbieders en naar het publieke veiligheidsmeldpunt (PSAP/911). Dit is een netwerk- en handsetverplichting, geen websiteverplichting, maar uw klantenportaal moet de RTT-ondersteuning per toestel en per abonnement nauwkeurig vermelden.
Valt mijn mobiele-aanbieder-app onder de EAA?
Vrijwel zeker. EAA artikel 2(2)(b) noemt "elektronische communicatiediensten" als in-scope, en artikel 2(2)(c) noemt "consumenteneindapparatuur met interactieve rekencapaciteit" — wat de Europese Commissie heeft uitgelegd als de klantgerichte mobiele app die bij die eindapparatuur hoort. Elke aanbieder die simkaarten, toestellen of VoIP in de EU verkoopt, valt in scope, moet voldoen aan EN 301 549 (dat voor web en mobiel verwijst naar WCAG 2.2 AA) en moet een toegankelijkheidsverklaring publiceren op grond van artikel 13.
En TTY-ondersteuning — is dat nog verplicht?
Nee, niet op IP-netwerken. De FCC heeft de verplichting voor draadloos TTY afgeschaft zodra RTT haalbaar werd, en aanbieders mogen op IP-netwerken RTT gebruiken in plaats van TTY. TTY-ondersteuning wordt nog steeds verwacht op verouderde TDM-circuits waar deze in gebruik blijven, maar nieuwe implementaties (5G-spraak, VoLTE, VoNR) hoeven alleen RTT te ondersteunen. Portaaltekst die nog steeds "alleen TTY" vermeldt, moet worden bijgewerkt naar "RTT (realtime-tekst) — vervangt TTY" met een korte uitleg over de overgang.
Hoe maak ik de storingskaart toegankelijk?
Twee onmisbare onderdelen. Ten eerste moet de kaart zelf een niet-decoratieve rol en een tekstalternatief hebben; puur SVG op canvas zonder aria-label voldoet niet aan WCAG 1.1.1. Ten tweede — en nog belangrijker — moet u dezelfde storingsdata als tekstlijst publiceren: postcode/regio, status (opgelost / wordt onderzocht / hersteld), getroffen diensten, verwachte hersteltijd. Toetsenbordgebruikers, schermlezers en gebruikers met een trage verbinding vertrouwen op de lijst, niet op de kaart. De kaart is een aanvulling; de lijst is de primaire informatiebron.
Behoren VRS-tolken tot de toegankelijkheidsverplichting van de aanbieder?
Tolken voor Video Relay Service (VRS) worden geleverd door FCC-gecertificeerde VRS-aanbieders, niet rechtstreeks door de aanbieders — en de dienst wordt gefinancierd via het federale Telecommunications Relay Services (TRS) Fund. De verplichting van een aanbieder is te zorgen dat zijn netwerk en toestellen interoperabel zijn met VRS, dat de klantenportaalverklaringen de beschikbaarheid van VRS uitleggen, en dat de eigen ondersteuningskanalen van de aanbieder een route bieden voor het aanvragen van een gebarentaaltolk voor dove en slechthorende klanten. De tolksourcing ligt niet bij de aanbieder; de vindbaarheid en interoperabiliteit wel.
Hoe vaak moet een aanbieder zijn klantenportaal auditen?
Geautomatiseerde scanning moet bij elke deploy worden uitgevoerd — aanbiedersportalen veranderen wekelijks, soms dagelijks, en een onbewaakt portaal zal afwijken. Combineer dat met een kwartaalrapport via geautomatiseerde monitoring over de volledige omgeving (portaal, facturering, app, storingskaart) en een jaarlijkse handmatige toegankelijkheidsaudit door testers met een beperking, inclusief RTT-gebruikers en gebruikers voor wie gebarentaal de voorkeurstaal is. Na elke grote herontwerp of migratie — en zeker na vervanging van een factureringssysteem (Amdocs, CSG) — dient een nieuwe handmatige audit vóór de livegang te worden uitgevoerd, niet erna.
Drie volgende stappen
Kies de stap die past bij waar uw aanbiedsteam nu staat.
-
Start de gratis scanner nu
Een live gratis WCAG 2.2-scanner op een willekeurige publieke URL — uw klantenportaal, uw factureringspagina, uw storingskaart. Het beste startpunt als u nog geen huidige basislijn heeft voor de publieke vlakken.
-
Lees de regelgeving naast elkaar
Onze EAA-gids en ADA Title III-gids behandelen wat elke wet vereist van aanbiedersgerichte websites en apps — en waar CVAA, EAA artikel 2 en WCAG 2.2 elkaar overlappen.
-
Laat een handmatige audit uitvoeren
Lees onze gids over het opdracht geven voor een handmatige toegankelijkheidsaudit door testers met een beperking — wat u moet vragen, wat u moet budgetteren, en welke platforms een echt testernetwerk met RTT-gebruikers en gebruikers voor wie gebarentaal de voorkeurstaal is omvatten versus dat uitbesteden.