Il regime di accessibilità nelle telecomunicazioni nel 2026
Due autorità di regolamentazione, due normative, un'unica superficie operativa.
Negli Stati Uniti, il 21st Century Communications and Video Accessibility Act — il CVAA, codificato al 47 U.S.C. § 617 — impone obblighi specifici di accessibilità ai servizi di comunicazione avanzata (ACS): VoIP, messaggistica elettronica e videoconferenza interoperabile. Tali obblighi sono indipendenti dal più generale obbligo del Titolo III dell'ADA applicabile ai siti web delle strutture aperte al pubblico. Si consulti la nostra guida al Titolo III dell'ADA per il quadro generale — il CVAA è il livello sovrapposto specifico per le telecomunicazioni.
L'applicazione da parte dell'FCC dell'accessibilità nelle telecomunicazioni si è intensificata dal 2022. La Commissione ha definito norme sul testo in tempo reale (RTT) e la migrazione dal TTY legacy sulle reti IP; sulle prestazioni del Video Relay Service (VRS) e del servizio di telefonia con sottotitoli (CTS); e sugli indici di compatibilità con apparecchi acustici (HAC) per i terminali. L'ufficio esecutivo pubblica decreti con consenso che citano gli operatori inadempienti in materia di interoperabilità RTT o dichiarazioni di accessibilità — sono pubblici e vengono letti dagli avvocati dei ricorrenti.
Nell'Unione europea, la Legge europea sull'accessibilità vincola gli operatori su due fronti. L'articolo 2(2)(b) cita i «servizi di comunicazione elettronica» — voce, SMS, messaggistica basata su IP — come rientranti nell'ambito. L'articolo 2(2)(c) copre le «apparecchiature terminali di consumo con capacità di elaborazione interattiva» — terminali, router, decoder — comprendendo le CPE fornite dagli operatori e le app che le configurano. EN 301 549 è lo standard di conformità e fa riferimento a WCAG 2.2 AA per le superfici web e mobile.
E WCAG 2.2 AA si applica ancora a qualsiasi sito web e app mobile rivolti ai clienti — portale di fatturazione, vetrina al dettaglio, base di conoscenza per l'assistenza, app native iOS e Android. Il CVAA e l'EAA non sostituiscono WCAG; vi sovrappongono obblighi specifici per le telecomunicazioni su una base che è comunque necessario rispettare per il sito web in sé. La checklist di seguito è strutturata attorno a tale sovrapposizione: WCAG 2.2 AA in ogni riga, con note specifiche CVAA/EAA richiamate dove applicabili.
Checklist WCAG 2.2 AA + CVAA in 30 punti per le telecomunicazioni
Sei aree × cinque verifiche. Stamparla, spuntarla, poi verificarla.
-
01 Gestione account e servizi
-
02 Fatturazione e pagamenti
-
03 Servizi di comunicazione
-
04 Ordine di apparecchiature e dispositivi
-
05 Interruzioni e assistenza
-
06 Funzionalità di rete e quote
Note sulle piattaforme — principali vendor telco
Dove la checklist si traduce concretamente in codice, per stack vendor.
Amdocs / CSG (fatturazione e gestione clienti)
I portali self-care basati su Amdocs CES e CSG Ascendon vengono forniti con impostazioni predefinite funzionali ma con pesanti personalizzazioni da parte delle agenzie. Le criticità ricorrenti sono la schermata di riepilogo fattura (resa come griglia div posizionata anziché come tabella semantica) e la procedura guidata di cambio piano (passaggi senza indicatore aria-current, per cui gli utenti di screen reader non riescono a capire in quale step si trovano). Entrambi sono risolvibili nel livello di personalizzazione senza toccare il codice del vendor. Si richieda al system integrator un report di conformità VPAT/EN 301 549 per la specifica installazione, non per il prodotto standard.
Salesforce Communications Cloud / Oracle Communications (CRM)
I portali basati su CRM ereditano la base Lightning o Redwood sottostante, che è discreta. La superficie di personalizzazione è dove le cose si rompono — Lightning Web Components composti senza region aria-live nelle viste carrello e tracciamento ordini, pagine Apex personalizzate che aggirano la gestione del focus della piattaforma, e temi di community che sovrascrivono l'indicatore di focus. Si verifichi il tema community/portale separatamente dalla piattaforma, e si tratti qualsiasi build «headless Salesforce» come un'implementazione React personalizzata ai fini della verifica.
Cisco Webex · Microsoft Teams · Zoom Phone (piattaforme UC)
Le piattaforme di comunicazione unificata pubblicano i propri VPAT e hanno investito molto in sottotitoli, pin ASL e supporto RTT — la superficie che si deve effettivamente verificare è l'integrazione. Le app Webex/Teams/Zoom brandizzate dall'operatore racchiudono l'SDK del vendor nel proprio wrapper, ed è nel wrapper che emergono i problemi: un telefono integrato che non annuncia i cambiamenti di stato della chiamata, un elenco contatti reso come griglia div, un indicatore di presenza trasmesso solo tramite colore. Ci si affidi alla dichiarazione di accessibilità del vendor per il motore sottostante, ma si verifichi il proprio wrapper.
Twilio · Vonage · RingCentral (peculiarità UI CPaaS)
I provider CPaaS distribuiscono dashboard e componenti integrabili di qualità variabile. Le dashboard stesse (Twilio Console, Vonage Dashboard, RingCentral Admin) sono generalmente adeguate. I componenti integrabili — widget click-to-call, stanze video, snippet di finestra chat — sono dove operatori e integratori falliscono più spesso. Si tratti qualsiasi embed JS fornito dal vendor come un'iniezione DOM di terze parti: deve essere verificato con la stessa checklist del proprio codice, perché si renderizza nella propria pagina sotto il proprio dominio e sotto la propria responsabilità.
App native degli operatori (iOS + Android nativi)
Il mobile nativo è dove la normativa EAA ha il morso più affilato — l'articolo 2(2)(c) copre le app che configurano le apparecchiature terminali di consumo, e le autorità di regolamentazione degli Stati membri stanno attivamente verificando le principali app degli operatori. Le criticità ricorrenti sono i pulsanti con sola icona privi di etichetta (nessun contentDescription su Android, nessun accessibilityLabel su iOS), modal in-app personalizzati che non tracciano il focus, e caroselli di onboarding che non annunciano mai i cambi di slide. Si consulti la nostra guida alle API di accessibilità mobile native per i pattern specifici della piattaforma — TalkBack, VoiceOver, Switch Control — che il team QA deve testare su dispositivi reali, non solo sul simulatore.
Il ciclo di monitoraggio + verifica
Una correzione una tantum non sopravvive al ritmo di rilascio degli operatori.
I portafogli degli operatori cambiano in modo continuo. Il marketing rilascia un banner tariffario il martedì, il team OSS/BSS distribuisce un aggiornamento del motore di fatturazione il giovedì, e le app native iOS/Android pubblicano una release ogni due settimane. Una correzione di accessibilità una tantum dura circa quanto il deploy successivo — ecco perché i team degli operatori che mantengono il livello lo fanno su tre livelli, non uno.
In primo luogo, si esegua uno scanner WCAG 2.2 gratuito sul proprio portale clienti, flusso di fatturazione e mappa delle interruzioni oggi, per stabilire una baseline. In secondo luogo, si attivi il monitoraggio automatizzato continuo su ogni build di preview e su ogni deploy in produzione — questo è il livello che intercetta le regressioni prima che raggiungano il cliente (e prima che lo faccia la coda dei reclami all'FCC). In terzo luogo, si commissioni una verifica manuale da parte di tester con disabilità almeno annualmente, e dopo ogni replatforming importante — la sostituzione di un sistema di fatturazione (Amdocs → CSG, o viceversa) è l'evento a rischio più elevato e giustifica una verifica manuale prima del lancio, non dopo.
Per il passaggio specifico da monitoraggio a verifica manuale, la nostra guida all'acquisto di soluzioni di monitoraggio copre le piattaforme che gestiscono il flusso di lavoro dalla scansione alla verifica end-to-end — Qualibooth, axe Monitor, Siteimprove e Level Access. Per le telecomunicazioni in particolare, si valuti la scelta su tre criteri: integrazione con il CI/CD (la maggior parte dei release train degli operatori utilizza Jenkins o GitLab CI, non GitHub Actions); se la rete di tester manuali della piattaforma include utenti RTT e utenti LIS di prima lingua — non tutte lo prevedono; e se la piattaforma supporta la verifica sia web che mobile nativo in un'unica dashboard, perché il portale e l'app non possono essere su cadenze separate.
Domande frequenti
Le domande che i team degli operatori pongono prima di impegnarsi.
Cos'è il CVAA e come si rapporta all'ADA?
Il 21st Century Communications and Video Accessibility Act (CVAA, 47 U.S.C. § 617) è una legge federale specifica per le telecomunicazioni applicata dall'FCC. Si applica ai servizi di comunicazione avanzata (ACS) — VoIP, messaggistica elettronica, videoconferenza interoperabile — e alle apparecchiature utilizzate per accedervi. L'ADA è una legge separata e più ampia applicata dal DOJ che copre in generale i siti web delle strutture aperte al pubblico. Gli operatori telefonici sono soggetti a entrambe: il CVAA per il servizio stesso, il Titolo III dell'ADA per il sito web e il punto vendita rivolti ai clienti. Un operatore deve superare i test specifici del CVAA E soddisfare WCAG 2.2 AA sulla propria interfaccia web e mobile.
Siamo tenuti a supportare il testo in tempo reale (RTT)?
Sì, negli Stati Uniti. Le norme FCC richiedono agli operatori wireless e ai produttori di terminali di supportare RTT (47 CFR § 67) come sostituto moderno del TTY. Le reti non sono più obbligate a supportare il TTY legacy, ma devono supportare RTT — e il percorso RTT deve funzionare end-to-end, anche tra operatori diversi e verso il punto di risposta alla pubblica sicurezza (PSAP / 911). Si tratta di un obbligo relativo alla rete e ai terminali, non al sito web, ma il portale clienti deve comunicare con precisione il supporto RTT per ogni dispositivo e ogni piano.
L'EAA si applica alla mia app per operatore mobile?
Quasi certamente. L'articolo 2(2)(b) dell'EAA cita i «servizi di comunicazione elettronica» come rientranti nell'ambito, e l'articolo 2(2)(c) cita le «apparecchiature terminali di consumo con capacità di elaborazione interattiva» — che la Commissione europea ha interpretato come comprensive dell'app rivolta ai clienti abbinata a tale apparecchiatura terminale. Qualsiasi operatore che venda SIM, dispositivi o VoIP nell'UE rientra nell'ambito, deve soddisfare EN 301 549 (che fa riferimento a WCAG 2.2 AA per le superfici web e mobile) e deve pubblicare una dichiarazione di accessibilità ai sensi dell'articolo 13.
E il supporto TTY — è ancora richiesto?
No, non sulle reti IP. L'FCC ha soppresso il requisito TTY wireless non appena RTT è diventato praticabile, e gli operatori possono ora utilizzare RTT in sostituzione del TTY sulle reti basate su IP. Il supporto TTY è ancora atteso sui circuiti TDM legacy dove rimangono in servizio, ma le nuove implementazioni (voce 5G, VoLTE, VoNR) devono supportare solo RTT. Il testo del portale clienti che recita ancora «solo TTY» dovrebbe essere aggiornato in «RTT (testo in tempo reale) — sostituisce il TTY» con una breve spiegazione della migrazione.
Come si rende accessibile la mappa delle interruzioni?
Due requisiti imprescindibili. In primo luogo, la mappa stessa deve avere un ruolo non decorativo e un'alternativa testuale; SVG puro su canvas senza aria-label non soddisfa WCAG 1.1.1. In secondo luogo — e più importante — è necessario pubblicare gli stessi dati sulle interruzioni come elenco testuale: CAP/regione, stato (risolto / in analisi / ripristinato), servizi interessati, tempo stimato di risoluzione. Gli utenti di tastiera, gli utenti di screen reader e gli utenti con connessioni a bassa larghezza di banda fanno affidamento sull'elenco, non sulla mappa. La mappa è un'integrazione; l'elenco è la fonte di verità.
Gli interpreti VRS rientrano nell'obbligo di accessibilità dell'operatore?
Gli interpreti del Video Relay Service (VRS) sono forniti da provider VRS certificati dall'FCC, non direttamente dagli operatori — e il servizio è finanziato dal Telecommunications Relay Services (TRS) Fund federale. L'obbligo dell'operatore è garantire che la propria rete e i propri dispositivi interoperino con VRS, che le comunicazioni nel portale clienti spieghino la disponibilità del VRS, e che i propri canali di assistenza offrano un percorso di richiesta di interprete LIS per i clienti sordi e ipoudenti. Il reperimento dell'interprete non è a carico dell'operatore; la reperibilità e l'interoperabilità lo sono.
Con quale frequenza un operatore dovrebbe verificare il proprio portale clienti?
La scansione automatizzata dovrebbe essere eseguita ad ogni deploy — i portali degli operatori cambiano settimanalmente, a volte quotidianamente, e un portale non monitorato andrà in deriva. A ciò si affianca un report automatizzato trimestrale sull'intera proprietà (portale, fatturazione, app, mappa delle interruzioni) e una verifica manuale annuale da parte di tester con disabilità, inclusi utenti RTT e utenti LIS di prima lingua. Dopo ogni replatforming importante — e in particolare dopo la sostituzione di un sistema di fatturazione (Amdocs, CSG) — è necessario commissionare una nuova verifica manuale prima del lancio, non dopo.
Tre passi successivi
Si scelga quello che corrisponde alla situazione attuale del proprio team.
-
Eseguire subito lo scanner gratuito
Uno scanner WCAG 2.2 gratuito live su qualsiasi URL pubblico — il portale clienti, la pagina di fatturazione, la mappa delle interruzioni. Il punto di partenza migliore se non si dispone di una baseline attuale per le superfici pubbliche.
-
Leggere le normative in parallelo
La nostra guida all'EAA e la guida al Titolo III dell'ADA illustrano cosa richiede ciascuna normativa ai siti web e alle app rivolti agli operatori — e dove si sovrappongono CVAA, EAA articolo 2 e WCAG 2.2.
-
Commissionare una verifica manuale
Si legga la nostra guida per commissionare una verifica manuale da parte di tester con disabilità — cosa richiedere, come pianificare il budget, e quali piattaforme includono una rete di tester reali con utenti RTT e LIS di prima lingua rispetto a quelle che la esternalizzano.