Telekomtilgængelighedsregimet i 2026
To regulatorer, to love, én driftsoverflade.
I USA pålægger 21st Century Communications and Video Accessibility Act — CVAA, kodificeret i 47 U.S.C. § 617 — specifikke tilgængelighedspligter for avancerede kommunikationstjenester (ACS): VoIP, elektroniske beskeder og interoperabel videokonference. Disse pligter er uafhængige af den mere generelle ADA Title III-pligt, der gælder for websites for offentlige indkvarteringssteder. Se vores ADA Title III-guide for den bredere ramme — CVAA er det telekomspecifikke lag oven på den.
FCC's håndhævelse af telekomtilgængelighed er strammet siden 2022. Kommissionen har indført regler om realtidstekst (RTT) og migreringen væk fra ældre TTY på IP-netværk; om ydeevne for video relay service (VRS) og captioned-telephone service (CTS); og om høreapparatkompatibilitetsvurderinger (HAC) for håndsæt. Håndhævelsesbureauet publicerer samtykkeerklæringer, der navngiver operatører, som ikke har overholdt RTT-interoperabilitet eller tilgængelighedserklæringsindgivelser — disse er offentlige og læses af sagsøgeres advokater.
I Den Europæiske Union binder det europæiske tilgængelighedsdirektiv (EAA) operatører fra to retninger. Artikel 2(2)(b) nævner "elektroniske kommunikationstjenester" — tale, SMS, IP-baserede beskeder — som inden for anvendelsesområdet. Artikel 2(2)(c) dækker "forbrugerterminalsudstyr med interaktiv computerkapacitet" — håndsæt, routere, set-top-bokse — hvilket inkluderer operatørleveret CPE og de apps, der konfigurerer det. EN 301 549 er overensstemmelsesstandarden og refererer til WCAG 2.2 AA for web- og mobiloverflader.
Og WCAG 2.2 AA gælder stadig for ethvert kundevendt website og mobilapp — faktureringsportal, detailbutik, supportvidensbase, native iOS- og Android-apps. CVAA og EAA erstatter ikke WCAG; de lægger telekomspecifikke pligter oven på et udgangspunkt, som man stadig skal opfylde for selve websitet. Tjeklisten nedenfor er struktureret omkring dette lag: WCAG 2.2 AA på hver række, med CVAA/EAA-specifikke noter fremhævet, hvor de er relevante.
30-punkts WCAG 2.2 AA + CVAA-tjekliste for telekommunikation
Seks overflader × fem kontroller. Udskriv den, sæt kryds, og auditér den.
-
01 Konto- og servicestyring
-
02 Fakturering og betaling
-
03 Kommunikationstjenester
-
04 Udstyr og bestilling af enheder
-
05 Nedbrud og support
-
06 Netværksfunktioner og kvoter
Platformsnoter — vigtige telekoudbydere
Hvor tjeklisten faktisk lander i koden, per leverandørstack.
Amdocs / CSG (fakturering og kundestyring)
Selvbetjeningsportaler bygget på Amdocs CES og CSG Ascendon leveres med brugbare standardindstillinger, men med omfattende bureautilpasning. De tilbagevendende fejl er fakturasammenfatningsskærmen (gengivet som et positioneret div-gitter i stedet for en semantisk tabel) og plan-skift-guiden (trin uden en aria-current-markør, så skærmlæserbrugere ikke kan se, hvilket trin de er på). Begge kan rettes i tilpasningslaget uden at røre leverandørkoden. Bed din SI om en VPAT/EN 301 549-overensstemmelsesrapport for dit specifikke deployment, ikke for standardproduktet.
Salesforce Communications Cloud / Oracle Communications (CRM)
CRM-forankrede portaler arver det underliggende Lightning- eller Redwood-udgangspunkt, som er rimeligt. Tilpasningsoverfladen er, hvor tingene bryder sammen — Lightning Web Components sammensat uden et aria-live-område på kurv- og ordreopfølgningsvisninger, brugerdefinerede Apex-sider, der omgår platformens fokusstyring, og community-site-temaer, der overstyrer fokusindikatoren. Auditér community/portal-temaet separat fra platformen, og behandl enhver "headless Salesforce"-bygning som et brugerdefineret React-butiksfacade til auditformål.
Cisco Webex · Microsoft Teams · Zoom Phone (UC-platforme)
Unified-comms-platforme publicerer deres egne VPAT'er og har investeret kraftigt i undertekster, ASL-pin og RTT-support — den overflade, du faktisk skal auditere, er embeddet. Operatørbrandede Webex/Teams/Zoom-apps pakker leverandør-SDK'en i dit eget chrome, og chromen er, hvor problemerne opstår: en in-app-opkaldsvælger, der ikke annoncerer opkaldstilstandsændringer, en kontaktliste gengivet som et div-gitter, en tilstedeværelsesindikator formidlet kun via farve. Læn dig op ad leverandørens tilgængelighedserklæring for den underliggende motor, men auditér din wrapper.
Twilio · Vonage · RingCentral (CPaaS UI-quirks)
CPaaS-udbydere leverer dashboards og indlejrbare komponenter af varierende kvalitet. Dashboardene selv (Twilio Console, Vonage Dashboard, RingCentral Admin) er generelt fine. De indlejrbare — klik-for-at-ringe-widgets, videorum, chat-vinduesuddrag — er, hvor operatører og integratorer oftest fejler. Behandl enhver leverandørleveret JS-indlejring som en tredjepartsDOM-injektion: den skal auditeres mod den samme tjekliste som din egen kode, fordi den gengiver på din side under dit domæne og dit ansvar.
Interne operatørapps (native iOS + Android)
Native mobil er, hvor EAA-biddet er skarpest — artikel 2(2)(c) dækker apps, der konfigurerer forbrugerterminalsudstyr, og medlemsstatsregulatorer auditerer aktivt de bedste operatørapps. De tilbagevendende fejl er umærkede ikon-kun-knapper (ingen contentDescription på Android, ingen accessibilityLabel på iOS), brugerdefinerede in-app-modaler, der ikke fanger fokus, og onboarding-karruseller, der aldrig annoncerer slid-skift. Se vores guide til native tilgængeligheds-API'er til mobil for de platformspecifikke mønstre — TalkBack, VoiceOver, Switch Control — som dit QA-team skal teste på rigtige enheder, ikke kun simulatoren.
Overvågnings- og auditcyklussen
En engangsoprydning overlever ikke en operatørs release-tog.
Operatørejendomme ændrer sig kontinuerligt. Marketing skubber et tarif-banner tirsdag, OSS/BSS-teamet leverer en faktureringsmotoropdatering torsdag, og native iOS/Android-apps klipper en release hver anden uge. En engangs tilgængelighedsrettelse holder omtrent så længe som dit næste deploy — derfor holder telekomteam, der fastholder niveauet, det i tre lag, ikke ét.
Kør først en gratis WCAG 2.2-scanner mod din live kundeportal, faktureringsforløb og nedbrudkort i dag for at etablere et udgangspunkt. Derefter tilslut kontinuerlig automatiseret overvågning mod hvert preview-build og hvert produktionsdeploy — dette er laget, der fanger regressioner, før de når kunden (og før FCC-klagekøen gør det). Bestil endelig en manuel tilgængelighedsaudit af testere med handicap mindst én gang om året og efter enhver større replatform — en faktureringsystemudskiftning (Amdocs → CSG eller omvendt) er begivenheden med højest risiko og berettiger en manuel audit inden lancering, ikke efter.
For overvågnings- og manuel-audit-overleveringen specifikt dækker vores overvågningskøberguide de platforme, der håndterer scan-til-audit-arbejdsgangen ende til ende — Qualibooth, axe Monitor, Siteimprove og Level Access. For telekommunikation specifikt skal du vægte dit valg på tre kriterier: integration med din CI/CD (de fleste operatørens release-tog er Jenkins eller GitLab CI, ikke GitHub Actions); om platformens manuelle audit-testnetværk inkluderer RTT-brugere og ASL-primære brugere — ikke alle gør; og om platformen understøtter både web- og native-mobilauditering under ét dashboard, fordi din portal og din app ikke kan være på separate kadencer.
FAQ
Spørgsmålene operatørteam stiller, inden de køber ind.
Hvad er CVAA, og hvordan forholder den sig til ADA?
21st Century Communications and Video Accessibility Act (CVAA, 47 U.S.C. § 617) er en telekomspecifik føderal lov håndhævet af FCC. Den gælder for avancerede kommunikationstjenester (ACS) — VoIP, elektroniske beskeder, interoperabel videokonference — og for det udstyr, der bruges til at få adgang til dem. ADA er en separat, bredere lov håndhævet af DOJ, der generelt dækker websites for offentlige indkvarteringssteder. Teleoperatører er underlagt begge: CVAA for selve tjenesten, ADA Title III for det kundevendte website og butik. En operatør skal bestå de CVAA-specifikke tests OG opfylde WCAG 2.2 AA på sin web- og mobil-UI.
Er vi forpligtet til at understøtte realtidstekst (RTT)?
Ja, i USA. FCC-reglerne kræver, at trådløse operatører og håndsætproducenter understøtter RTT (47 CFR § 67) som den moderne erstatning for TTY. Netværk behøver ikke længere at understøtte ældre TTY, men de skal understøtte RTT — og RTT-stien skal fungere ende til ende, herunder på tværs af operatører og ind i den offentlige sikkerhedssvarscentral (PSAP / 911). Dette er et netværks- og håndsætpligt, ikke et websitepligt, men din kundeportal skal nøjagtigt oplyse RTT-support pr. enhed og pr. plan.
Dækker EAA min mobiloperatørapp?
Næsten helt sikkert. EAA artikel 2(2)(b) nævner "elektroniske kommunikationstjenester" som inden for anvendelsesområdet, og artikel 2(2)(c) nævner "forbrugerterminalsudstyr med interaktiv computerkapacitet" — som Europa-Kommissionen har fortolket til at dække den kundevendte mobilapp, der parres med det terminaludstyr. Enhver operatør, der sælger SIM-kort, enheder eller VoIP i EU, er inden for anvendelsesområdet, skal opfylde EN 301 549 (der refererer til WCAG 2.2 AA for web og mobil) og skal publicere en tilgængelighedserklæring i henhold til artikel 13.
Hvad med TTY-support — er det stadig påkrævet?
Nej, ikke på IP-netværk. FCC afviklede kravet om trådløs TTY, da RTT blev levedygtig, og operatører kan nu bruge RTT i stedet for TTY på IP-baserede netværk. TTY-support forventes stadig på ældre TDM-kredsløb, hvor de fortsat er i drift, men nye byggerier (5G-tale, VoLTE, VoNR) behøver kun at understøtte RTT. Kundeportaltekst, der stadig siger "kun TTY", bør opdateres til "RTT (realtidstekst) — erstatter TTY" med en kort migreringsforklaring.
Hvordan gør jeg nedbrudkortet tilgængeligt?
To ikke-forhandlingsbare dele. Først skal selve kortet have en ikke-dekorativ rolle og et tekstalternativ; ren SVG-på-canvas uden aria-label opfylder ikke WCAG 1.1.1. For det andet — og vigtigere — skal du publicere de samme nedbruddata som en tekstliste: postnummer/region, status (løst / undersøges / genoprettet), berørte tjenester, anslået tid til løsning. Tastaturbrugere, skærmlæserbrugere og brugere med lav båndbredde er alle afhængige af listen, ikke kortet. Kortet er en forbedring; listen er sandhedskilden.
Er VRS-tolke en del af operatørens tilgængelighedspligt?
Video Relay Service (VRS)-tolke leveres af FCC-certificerede VRS-udbydere, ikke direkte af operatørerne — og tjenesten finansieres af den føderale Telecommunications Relay Services (TRS)-fond. En operatørs pligt er at sikre, at dens netværk og enheder er interoperable med VRS, at kundeportaloplysninger forklarer VRS-tilgængelighed, og at operatørens egne supportkanaler tilbyder en ASL-tolkanmodningsrute for døve og hørehæmmede kunder. Tolkkilden er ikke operatørens ansvar; synlighed og interoperabilitet er.
Hvor ofte bør en operatør auditere sin kundeportal?
Automatiseret scanning bør køre ved hvert deploy — operatørportaler ændrer sig ugentligt, sommetider dagligt, og en uovervåget portal vil drive. Par det med en kvartalsvis automatiseret rapport mod hele ejendommen (portal, fakturering, app, nedbrudkort) og en årlig manuel tilgængelighedsaudit af testere med handicap, herunder RTT-brugere og ASL-primære brugere. Efter enhver større redesign eller replatform — og især efter en faktureringsystemudskiftning (Amdocs, CSG) — bestil en ny manuel audit inden lancering, ikke efter.
Tre næste skridt
Vælg det, der passer til, hvor dit operatørteam er i dag.
-
Kør den gratis scanner nu
En live gratis WCAG 2.2-scanner mod enhver offentlig URL — din kundeportal, din faktureringsside, dit nedbrudkort. Bedste udgangspunkt, hvis du ikke har et aktuelt udgangspunkt for de offentlige overflader.
-
Læs reglerne side om side
Vores EAA-guide og ADA Title III-guide dækker, hvad hver lov kræver af operatørvendte websites og apps — og hvor CVAA, EAA artikel 2 og WCAG 2.2 overlapper.
-
Bestil en manuel tilgængelighedsaudit
Læs vores guide til at bestille en manuel tilgængelighedsaudit af testere med handicap — hvad du skal bede om, hvad du skal budgettere, og hvilke platforme der inkluderer et rigtigt testnetværk med RTT- og ASL-primære brugere, kontra dem der outsourcer det.