Le régime d'accessibilité des télécoms en 2026
Deux régulateurs, deux lois, une surface opérationnelle.
Aux États-Unis, le 21st Century Communications and Video Accessibility Act — le CVAA, codifié à 47 U.S.C. § 617 — impose des obligations d'accessibilité spécifiques aux services de communications avancés (ACS) : VoIP, messagerie électronique et visioconférence interopérable. Ces obligations sont indépendantes de l'obligation plus générale au titre de l'ADA Title III applicable aux sites web des lieux d'accueil public. Consultez notre guide ADA Title III pour le cadre plus large — le CVAA est la surcouche spécifique aux télécommunications.
L'application par la FCC de la réglementation d'accessibilité dans les télécoms s'est renforcée depuis 2022. La Commission a établi des règles sur le texte en temps réel (RTT) et la migration hors du TTY hérité sur les réseaux IP ; sur les performances du service de relais vidéo (VRS) et du service téléphonique sous-titré (CTS) ; et sur les indices de compatibilité avec les aides auditives (HAC) pour les terminaux. Le bureau d'application publie des décrets de consentement nommant les opérateurs qui n'ont pas respecté l'interopérabilité RTT ou les dépôts de déclarations d'accessibilité — ils sont publics et lus par les avocats des plaignants.
Dans l'Union européenne, l'Acte européen sur l'accessibilité contraint les opérateurs de deux côtés. L'article 2(2)(b) nomme les « services de communications électroniques » — voix, SMS, messagerie IP — comme relevant de son champ d'application. L'article 2(2)(c) couvre les « équipements terminaux grand public dotés de capacités informatiques interactives » — terminaux, routeurs, décodeurs — ce qui inclut les équipements CPE fournis par l'opérateur et les applications qui les configurent. EN 301 549 est le standard de conformité, et il référence WCAG 2.2 AA pour les surfaces web et mobiles.
Et WCAG 2.2 AA lui-même s'applique toujours à chaque site web et application mobile orientés clients — portail de facturation, boutique en ligne, base de connaissances d'assistance, applications iOS et Android natives. Le CVAA et l'EAA ne remplacent pas WCAG ; ils ajoutent des obligations spécifiques aux télécoms sur une base de référence que vous devez toujours respecter pour le site web lui-même. La liste de contrôle ci-dessous est structurée autour de cette surcouche : WCAG 2.2 AA sur chaque ligne, avec les notes CVAA/EAA spécifiques indiquées là où elles s'appliquent.
Liste de contrôle de 30 points WCAG 2.2 AA + CVAA pour les télécoms
Six surfaces × cinq vérifications. Imprimez-la, cochez-la, puis auditez-la.
-
01 Gestion du compte et des services
-
02 Facturation et paiements
-
03 Services de communication
-
04 Commande d'équipements et d'appareils
-
05 Pannes et assistance
-
06 Fonctionnalités réseau et quotas
Notes sur les plateformes — principaux éditeurs télécoms
Là où la liste de contrôle se traduit concrètement en code, par pile éditeur.
Amdocs / CSG (facturation et gestion clients)
Les portails en libre-service construits sur Amdocs CES et CSG Ascendon sont livrés avec des valeurs par défaut fonctionnelles mais font l'objet de personnalisations importantes par les agences. Les échecs récurrents sont l'écran de résumé de facture (rendu comme une grille de div positionnée plutôt qu'un tableau sémantique) et l'assistant de changement de forfait (étapes sans marqueur aria-current, de sorte que les utilisateurs de lecteurs d'écran ne peuvent pas savoir à quelle étape ils se trouvent). Les deux sont corrigeables dans la couche de personnalisation sans toucher au code éditeur. Demandez à votre intégrateur de système un rapport de conformité VPAT/EN 301 549 sur votre déploiement spécifique, pas sur le produit standard.
Salesforce Communications Cloud / Oracle Communications (CRM)
Les portails ancrés sur CRM héritent de la base Lightning ou Redwood sous-jacente, qui est correcte. La surface de personnalisation est là où les choses se dégradent — des composants Lightning Web Components composés sans région aria-live sur les vues panier et suivi des commandes, des pages Apex personnalisées qui contournent la gestion du focus de la plateforme, et des thèmes de sites communautaires qui écrasent l'indicateur de focus. Auditez le thème communautaire/portail séparément de la plateforme, et traitez tout build « Salesforce headless » comme un storefront React personnalisé pour les besoins de l'audit.
Cisco Webex · Microsoft Teams · Zoom Phone (plateformes UC)
Les plateformes de communications unifiées publient leurs propres VPAT et ont investi massivement dans le sous-titrage, l'épinglage ASL et la prise en charge RTT — la surface que vous devez réellement auditer est l'intégration. Les applications Webex/Teams/Zoom personnalisées à la marque de l'opérateur enveloppent le SDK éditeur dans votre propre interface, et c'est cette interface qui concentre les problèmes : un clavier intégré qui n'annonce pas les changements d'état d'appel, une liste de contacts rendue comme une grille de div, un indicateur de présence transmis par couleur seule. Appuyez-vous sur la déclaration d'accessibilité de l'éditeur pour le moteur sous-jacent, mais auditez votre couche d'habillage.
Twilio · Vonage · RingCentral (particularités des interfaces CPaaS)
Les prestataires CPaaS fournissent des tableaux de bord et des composants intégrables de qualité variable. Les tableaux de bord eux-mêmes (Twilio Console, Vonage Dashboard, RingCentral Admin) sont généralement corrects. Les composants intégrables — widgets click-to-call, salles vidéo, extraits de fenêtre de chat — sont là où les opérateurs et intégrateurs échouent le plus souvent. Traitez tout composant JS fourni par un éditeur comme une injection DOM tierce : il doit être audité avec la même liste de contrôle que votre propre code, car il s'affiche dans votre page, sous votre domaine et sous votre responsabilité.
Applications opérateurs intégrées (iOS + Android natif)
Le mobile natif est là où la contrainte de l'EAA est la plus forte — l'article 2(2)(c) couvre les applications qui configurent les équipements terminaux grand public, et les régulateurs des États membres auditent activement les principales applications opérateurs. Les échecs récurrents sont les boutons icône seule sans étiquette (pas de contentDescription sur Android, pas d'accessibilityLabel sur iOS), les modales personnalisées dans l'application qui ne piègent pas le focus, et les carrousels d'intégration qui n'annoncent jamais les changements de diapositive. Consultez notre guide sur les API d'accessibilité mobile native pour les patterns spécifiques à chaque plateforme — TalkBack, VoiceOver, Switch Control — que votre équipe QA doit tester sur de vrais appareils, pas seulement sur le simulateur.
Le cycle de surveillance + audit
Une correction ponctuelle ne survit pas à un train de livraisons opérateur.
Les parcs opérateurs évoluent en permanence. Le marketing déploie une bannière tarifaire le mardi, l'équipe OSS/BSS livre une mise à jour du moteur de facturation le jeudi, et les applications iOS/Android natives sortent une version toutes les deux semaines. Une correction d'accessibilité ponctuelle dure à peu près jusqu'au prochain déploiement — c'est pourquoi les équipes opérateurs qui tiennent la ligne le font en trois couches, pas une.
Premièrement, lancez un scanner WCAG 2.2 gratuit sur votre portail client, votre flux de facturation et votre carte des pannes dès aujourd'hui pour établir une référence. Deuxièmement, branchez une surveillance automatisée continue sur chaque build de prévisualisation et chaque déploiement en production — c'est la couche qui détecte les régressions avant qu'elles n'atteignent le client (et avant que la file de plaintes de la FCC ne le fasse). Troisièmement, commandez un audit manuel par des testeurs en situation de handicap au moins une fois par an et après tout changement majeur de plateforme — le remplacement d'un système de facturation (Amdocs → CSG, ou vice versa) est l'événement à risque le plus élevé et justifie un audit manuel avant le lancement, pas après.
Pour le passage spécifique de la surveillance à l'audit manuel, notre guide d'achat sur la surveillance couvre les plateformes qui gèrent le flux analyse-vers-audit de bout en bout — Qualibooth, axe Monitor, Siteimprove et Level Access. Pour les télécoms spécifiquement, pondérez votre choix sur trois critères : l'intégration à votre CI/CD (la plupart des trains de livraison opérateur utilisent Jenkins ou GitLab CI, pas GitHub Actions) ; si le réseau de testeurs manuels de la plateforme inclut des utilisateurs RTT et des utilisateurs privilégiant la langue des signes — ce n'est pas le cas de toutes ; et si la plateforme prend en charge l'audit web et mobile natif sous un seul tableau de bord, car votre portail et votre application ne peuvent pas être sur des cycles séparés.
FAQ
Les questions que les équipes opérateurs posent avant de s'engager.
Qu'est-ce que le CVAA et quel est son rapport avec l'ADA ?
Le 21st Century Communications and Video Accessibility Act (CVAA, 47 U.S.C. § 617) est une loi fédérale spécifique aux télécommunications appliquée par la FCC. Il s'applique aux services de communications avancés (ACS) — VoIP, messagerie électronique, visioconférence interopérable — et aux équipements utilisés pour y accéder. L'ADA est une loi distincte et plus large, appliquée par le DOJ, qui couvre généralement les sites web des lieux d'accueil public. Les opérateurs télécoms sont soumis aux deux : le CVAA pour le service lui-même, l'ADA Title III pour le site web et le point de vente orientés clients. Un opérateur doit satisfaire aux tests spécifiques au CVAA ET respecter WCAG 2.2 AA sur son interface web et mobile.
Sommes-nous tenus de prendre en charge le texte en temps réel (RTT) ?
Oui, aux États-Unis. Les règles de la FCC imposent aux opérateurs sans fil et aux fabricants de terminaux de prendre en charge le RTT (47 CFR § 67) en remplacement moderne du TTY. Les réseaux n'ont plus à prendre en charge le TTY hérité, mais doivent prendre en charge le RTT — et le chemin RTT doit fonctionner de bout en bout, y compris entre opérateurs et vers le centre d'appels d'urgence (PSAP / 911). Il s'agit d'une obligation réseau et terminaux, pas d'une obligation de site web, mais votre portail client doit indiquer avec précision la prise en charge RTT par appareil et par forfait.
L'EAA couvre-t-il mon application d'opérateur mobile ?
Presque certainement. L'article 2(2)(b) de l'EAA nomme les « services de communications électroniques » comme relevant de son champ d'application, et l'article 2(2)(c) nomme les « équipements terminaux grand public dotés de capacités informatiques interactives » — ce que la Commission européenne a interprété comme couvrant l'application mobile orientée clients associée à cet équipement terminal. Tout opérateur vendant des cartes SIM, des appareils ou du VoIP dans l'UE est dans le champ d'application, doit satisfaire à EN 301 549 (qui référence WCAG 2.2 AA pour le web et le mobile) et doit publier une déclaration d'accessibilité conformément à l'article 13.
Et la prise en charge du TTY — est-elle toujours requise ?
Non, pas sur les réseaux IP. La FCC a supprimé l'obligation TTY sans fil une fois le RTT viable, et les opérateurs peuvent désormais utiliser le RTT à la place du TTY sur les réseaux IP. La prise en charge du TTY est encore attendue sur les circuits TDM hérités là où ils restent en service, mais les nouvelles infrastructures (voix 5G, VoLTE, VoNR) n'ont besoin que de prendre en charge le RTT. Les textes du portail client indiquant encore « TTY uniquement » doivent être mis à jour en « RTT (texte en temps réel) — remplace le TTY » avec une brève explication de la transition.
Comment rendre la carte des pannes accessible ?
Deux éléments non négociables. Premièrement, la carte elle-même doit avoir un rôle non décoratif et une alternative textuelle ; un SVG pur sur canvas sans aria-label ne satisfait pas au critère WCAG 1.1.1. Deuxièmement — et plus important — vous devez publier les mêmes données de panne sous forme de liste textuelle : code postal/région, statut (résolu / en cours d'investigation / rétabli), services affectés, délai estimé de résolution. Les utilisateurs de clavier, les utilisateurs de lecteurs d'écran et les utilisateurs en faible bande passante se fient à la liste, pas à la carte. La carte est un enrichissement ; la liste est la source de vérité.
Les interprètes VRS font-ils partie de l'obligation d'accessibilité de l'opérateur ?
Les interprètes du Video Relay Service (VRS) sont fournis par des prestataires VRS certifiés par la FCC, pas directement par les opérateurs — et le service est financé par le fonds fédéral Telecommunications Relay Services (TRS). L'obligation de l'opérateur est de s'assurer que son réseau et ses appareils sont interopérables avec le VRS, que les informations sur le portail client expliquent la disponibilité du VRS, et que les propres canaux d'assistance de l'opérateur proposent un parcours de demande d'interprète en langue des signes pour les clients sourds et malentendants. La fourniture de l'interprète n'incombe pas à l'opérateur ; la découvrabilité et l'interopérabilité, si.
À quelle fréquence un opérateur doit-il auditer son portail client ?
L'analyse automatisée doit s'exécuter à chaque déploiement — les portails opérateurs changent chaque semaine, parfois chaque jour, et un portail non surveillé va dériver. Complétez cela par un rapport automatisé trimestriel sur l'ensemble de la propriété (portail, facturation, application, carte des pannes) et un audit manuel annuel par des testeurs en situation de handicap, dont des utilisateurs RTT et des utilisateurs privilégiant la langue des signes. Après toute refonte majeure ou changement de plateforme — et surtout après le remplacement d'un système de facturation (Amdocs, CSG) — commandez un audit manuel avant le lancement, pas après.
Trois prochaines étapes
Choisissez celle qui correspond à la situation actuelle de votre équipe opérateur.
-
Lancer le scanner gratuit maintenant
Un scanner WCAG 2.2 gratuit en direct sur n'importe quelle URL publique — votre portail client, votre page de facturation, votre carte des pannes. Le meilleur point de départ si vous n'avez pas de référence actuelle sur les surfaces publiques.
-
Lire les réglementations côte à côte
Notre guide EAA et notre guide ADA Title III couvrent ce que chaque loi exige des sites web et applications orientés opérateurs — et là où CVAA, EAA article 2 et WCAG 2.2 se recoupent.
-
Commander un audit manuel
Lisez notre guide pour commander un audit manuel par des testeurs en situation de handicap — ce qu'il faut demander, quel budget prévoir, et quelles plateformes incluent un vrai réseau de testeurs avec des utilisateurs RTT et des utilisateurs privilégiant la langue des signes, par opposition à celles qui sous-traitent.