El régimen de accesibilidad en telecomunicaciones en 2026
Dos reguladores, dos leyes, una superficie operativa.
En Estados Unidos, la Ley de Accesibilidad de las Comunicaciones y el Vídeo del Siglo XXI — la CVAA, codificada en 47 U.S.C. § 617 — impone obligaciones específicas de accesibilidad a los servicios de comunicaciones avanzadas (ACS): VoIP, mensajería electrónica y videoconferencia interoperable. Estas obligaciones son independientes de la obligación más general del Título III de la ADA que se aplica a los sitios web de establecimientos de atención al público. Consulte nuestra guía sobre el Título III de la ADA para el marco general — la CVAA es la capa específica de telecomunicaciones que se superpone a él.
La aplicación de la FCC en materia de accesibilidad en telecomunicaciones se ha endurecido desde 2022. La Comisión ha establecido normas sobre el texto en tiempo real (RTT) y la migración del TTY heredado en redes IP; sobre el rendimiento del Servicio de Retransmisión de Vídeo (VRS) y el Servicio de Teléfono con Subtítulos (CTS); y sobre las calificaciones de compatibilidad con audífonos (HAC) para terminales. La oficina de aplicación publica decretos de consentimiento que nombran a los operadores que han incumplido con la interoperabilidad RTT o con la presentación de declaraciones de accesibilidad — estos son públicos y los leen los abogados de los demandantes.
En la Unión Europea, el Acta Europea de Accesibilidad vincula a los operadores desde dos ángulos. El artículo 2(2)(b) menciona los «servicios de comunicaciones electrónicas» — voz, SMS, mensajería basada en IP — como incluidos en el ámbito de aplicación. El artículo 2(2)(c) cubre los «equipos terminales de usuario con capacidad informática interactiva» — terminales, routers, decodificadores — lo que incluye los CPE suministrados por el operador y las aplicaciones que los configuran. EN 301 549 es la norma de conformidad y referencia WCAG 2.2 AA para las superficies web y móvil.
Y WCAG 2.2 AA en sí sigue aplicándose a todos los sitios web y aplicaciones móviles orientados al cliente — portal de facturación, tienda minorista, base de conocimiento de soporte, aplicaciones nativas de iOS y Android. La CVAA y la EAA no sustituyen a WCAG; superponen obligaciones específicas de telecomunicaciones sobre una línea base que aún debe cumplirse para el propio sitio web. La lista de verificación que aparece a continuación está estructurada en torno a esa superposición: WCAG 2.2 AA en cada fila, con notas específicas de CVAA/EAA indicadas donde corresponden.
Lista de verificación de 30 puntos WCAG 2.2 AA + CVAA para telecomunicaciones
Seis superficies × cinco verificaciones. Imprímala, márquela, luego audítela.
-
01 Gestión de cuenta y servicio
-
02 Facturación y pagos
-
03 Servicios de comunicación
-
04 Equipos y pedido de dispositivos
-
05 Averías y soporte
-
06 Funciones de red y cuotas
Notas de plataforma — principales proveedores para telecomunicaciones
Dónde aterriza realmente la lista de verificación en el código, por proveedor.
Amdocs / CSG (facturación y gestión de clientes)
Los portales de autoservicio construidos sobre Amdocs CES y CSG Ascendon se entregan con valores predeterminados funcionales pero con una personalización de agencia extensa. Los fallos recurrentes son la pantalla de resumen de factura (renderizada como una cuadrícula de div posicionado en lugar de una tabla semántica) y el asistente de cambio de plan (pasos sin un marcador aria-current, de modo que los usuarios de lectores de pantalla no pueden saber en qué paso se encuentran). Ambos son corregibles en la capa de personalización sin tocar el código del proveedor. Solicite a su integrador de sistemas un informe de conformidad VPAT/EN 301 549 sobre su despliegue específico, no sobre el producto estándar.
Salesforce Communications Cloud / Oracle Communications (CRM)
Los portales basados en CRM heredan la línea base de Lightning o Redwood subyacente, que es aceptable. La superficie de personalización es donde las cosas se rompen — Lightning Web Components compuestos sin una región aria-live en las vistas del carrito y el seguimiento de pedidos, páginas Apex personalizadas que evitan la gestión de foco de la plataforma y temas de sitios comunitarios que anulan el indicador de foco. Audite el tema de la comunidad/portal por separado de la plataforma, y trate cualquier construcción «headless Salesforce» como una tienda React personalizada a efectos de auditoría.
Cisco Webex · Microsoft Teams · Zoom Phone (plataformas UC)
Las plataformas de comunicaciones unificadas publican sus propios VPAT y han invertido mucho en subtitulado, fijación de intérprete ASL y compatibilidad RTT — la superficie que realmente hay que auditar es la incrustación. Las aplicaciones Webex/Teams/Zoom con marca del operador envuelven el SDK del proveedor en su propio chrome, y el chrome es donde surgen los problemas: un marcador de llamadas integrado que no anuncia los cambios de estado de la llamada, una lista de contactos renderizada como cuadrícula de div, un indicador de presencia transmitido solo por color. Confíe en la declaración de accesibilidad del proveedor para el motor subyacente, pero audite su propio wrapper.
Twilio · Vonage · RingCentral (peculiaridades de UI en CPaaS)
Los proveedores de CPaaS ofrecen paneles de control y componentes incrustables de calidad variable. Los paneles en sí (Twilio Console, Vonage Dashboard, RingCentral Admin) son generalmente aceptables. Los componentes incrustables — widgets de clic para llamar, salas de vídeo, fragmentos de ventana de chat — son donde los operadores e integradores fallan con más frecuencia. Trate cualquier fragmento de JS de un proveedor como una inyección de DOM de terceros: debe auditarse con la misma lista de verificación que su propio código, porque se renderiza en su página bajo su dominio y su responsabilidad.
Aplicaciones nativas del operador (iOS + Android nativo)
El móvil nativo es donde la mordida de la EAA es más aguda — el artículo 2(2)(c) cubre las aplicaciones que configuran equipos terminales de usuario, y los reguladores de los estados miembros están auditando activamente las principales aplicaciones de operadores. Los fallos recurrentes son los botones con solo icono sin etiqueta (sin contentDescription en Android, sin accessibilityLabel en iOS), los modales personalizados en la app que no atrapan el foco y los carruseles de incorporación que nunca anuncian los cambios de diapositiva. Consulte nuestra guía sobre API de accesibilidad nativa en móvil para los patrones específicos de la plataforma — TalkBack, VoiceOver, Switch Control — que su equipo de QA necesita probar en dispositivos reales, no solo en el simulador.
El ciclo de monitorización + auditoría
Una corrección puntual no sobrevive al tren de lanzamientos de un operador.
Los activos de los operadores cambian continuamente. Marketing publica un banner de tarifa el martes, el equipo OSS/BSS lanza una actualización del motor de facturación el jueves y las aplicaciones nativas de iOS/Android publican una versión cada dos semanas. Una corrección de accesibilidad puntual dura aproximadamente lo que el siguiente despliegue — por eso los equipos de operadores que mantienen el nivel lo hacen en tres capas, no en una.
En primer lugar, ejecute un escáner WCAG 2.2 gratuito contra su portal de atención al cliente, su flujo de facturación y su mapa de averías hoy para establecer una línea base. En segundo lugar, conecte una monitorización automatizada continua contra cada compilación de previsualización y cada despliegue en producción — esta es la capa que detecta las regresiones antes de que lleguen al cliente (y antes de que lo haga la cola de quejas de la FCC). En tercer lugar, encargue una auditoría manual por personas con discapacidad al menos una vez al año y después de cualquier cambio de plataforma importante — una sustitución del sistema de facturación (Amdocs → CSG, o viceversa) es el evento de mayor riesgo y justifica una auditoría manual antes del lanzamiento, no después.
Para el traspaso específico de monitorización + auditoría manual, nuestra guía de compra de monitorización cubre las plataformas que gestionan el flujo de trabajo de escaneo a auditoría de extremo a extremo — Qualibooth, axe Monitor, Siteimprove y Level Access. Para telecomunicaciones en particular, pondere su elección en tres criterios: integración con su CI/CD (la mayoría de los trenes de lanzamiento de operadores son Jenkins o GitLab CI, no GitHub Actions); si la red de auditores manuales de la plataforma incluye usuarios de RTT y usuarios con lengua de señas como primera lengua — no todas lo hacen; y si la plataforma admite auditoría tanto web como nativa móvil bajo un único panel, porque su portal y su aplicación no pueden estar en cadencias separadas.
Preguntas frecuentes
Las preguntas que los equipos de operadores hacen antes de comprometerse.
¿Qué es la CVAA y cómo se relaciona con la ADA?
La Ley de Accesibilidad de las Comunicaciones y el Vídeo del Siglo XXI (CVAA, 47 U.S.C. § 617) es una ley federal específica para telecomunicaciones aplicada por la FCC. Se aplica a los servicios de comunicaciones avanzadas (ACS) — VoIP, mensajería electrónica, videoconferencia interoperable — y a los equipos utilizados para acceder a ellos. La ADA es una ley separada y más amplia, aplicada por el DOJ, que cubre en general los sitios web de establecimientos de atención al público. Los operadores de telecomunicaciones están sujetos a ambas: la CVAA para el propio servicio y la ADA Título III para el sitio web y la tienda orientados al cliente. Un operador debe superar las pruebas específicas de la CVAA Y cumplir con WCAG 2.2 AA en su interfaz web y móvil.
¿Estamos obligados a admitir el texto en tiempo real (RTT)?
Sí, en Estados Unidos. Las normas de la FCC exigen que los operadores inalámbricos y los fabricantes de terminales admitan RTT (47 CFR § 67) como sustituto moderno del TTY. Las redes ya no tienen que admitir el TTY heredado, pero sí deben admitir RTT — y la ruta RTT debe funcionar de extremo a extremo, incluso entre operadores y hasta el punto de respuesta de seguridad pública (PSAP / 911). Esta es una obligación de red y terminal, no del sitio web, pero el portal de atención al cliente debe informar con precisión sobre la compatibilidad RTT por dispositivo y por plan.
¿Cubre la EAA la aplicación de mi operador móvil?
Casi con toda seguridad. El artículo 2(2)(b) de la EAA menciona los «servicios de comunicaciones electrónicas» como incluidos en el ámbito de aplicación, y el artículo 2(2)(c) menciona los «equipos terminales de usuario con capacidad informática interactiva» — lo que la Comisión Europea ha interpretado que abarca la aplicación orientada al cliente que se empareja con dicho equipo terminal. Cualquier operador que venda SIM, dispositivos o VoIP en la UE está dentro del ámbito de aplicación, debe cumplir con EN 301 549 (que referencia WCAG 2.2 AA para web y móvil) y debe publicar una declaración de accesibilidad conforme al artículo 13.
¿Y la compatibilidad con TTY — ¿sigue siendo obligatoria?
No, no en redes IP. La FCC eliminó el requisito de TTY inalámbrico una vez que RTT se volvió viable, y los operadores pueden ahora usar RTT en lugar de TTY en redes basadas en IP. La compatibilidad con TTY sigue siendo esperada en los circuitos TDM heredados donde aún están en servicio, pero las nuevas implantaciones (5G voice, VoLTE, VoNR) solo necesitan admitir RTT. El contenido del portal de atención al cliente que todavía diga «solo TTY» debe actualizarse a «RTT (texto en tiempo real) — sustituye al TTY» con una breve explicación de la migración.
¿Cómo hago accesible el mapa de averías?
Dos partes no negociables. En primer lugar, el propio mapa debe tener un rol no decorativo y una alternativa textual; un SVG puro sobre canvas sin aria-label no cumple con WCAG 1.1.1. En segundo lugar — y más importante — debe publicar los mismos datos de averías como lista de texto: código postal/región, estado (resuelto / en investigación / restaurado), servicios afectados, tiempo estimado de resolución. Los usuarios de teclado, los usuarios de lector de pantalla y los usuarios con conexiones de bajo ancho de banda dependen de la lista, no del mapa. El mapa es una mejora; la lista es la fuente de verdad.
¿Son los intérpretes de VRS parte de la obligación de accesibilidad del operador?
Los intérpretes del Servicio de Retransmisión de Vídeo (VRS) son proporcionados por proveedores de VRS certificados por la FCC, no directamente por los operadores — y el servicio está financiado por el Fondo federal de Servicios de Retransmisión de Telecomunicaciones (TRS). La obligación del operador es garantizar que su red y sus dispositivos sean interoperables con VRS, que las divulgaciones del portal de atención al cliente expliquen la disponibilidad del VRS y que los canales de soporte propios del operador ofrezcan una vía de solicitud de intérprete de lengua de señas para clientes sordos y con dificultades auditivas. La provisión del intérprete no recae sobre el operador; sí lo hacen la detectabilidad y la interoperabilidad.
¿Con qué frecuencia debe un operador auditar su portal de atención al cliente?
El escaneo automatizado debe ejecutarse en cada despliegue — los portales de operadores cambian semanalmente, a veces a diario, y un portal sin monitorización derivará. Combine eso con un informe automatizado trimestral sobre toda la propiedad (portal, facturación, app, mapa de averías) y una auditoría manual anual por personas con discapacidad, incluidos usuarios de RTT y usuarios con lengua de señas como primera lengua. Tras cualquier rediseño o cambio de plataforma importante — y especialmente tras la sustitución de un sistema de facturación (Amdocs, CSG) — encargue una nueva auditoría manual antes del lanzamiento, no después.
Tres pasos siguientes
Elija el que se ajusta a la situación actual de su equipo de operador.
-
Ejecute el escáner gratuito ahora
Un escáner WCAG 2.2 gratuito en directo contra cualquier URL pública — su portal de atención al cliente, su página de facturación, su mapa de averías. El mejor punto de partida si no tiene una línea base actual frente a las superficies públicas.
-
Lea las normativas una al lado de la otra
Nuestra guía sobre la EAA y la guía sobre el Título III de la ADA explican qué exige cada ley de los sitios web y las aplicaciones orientadas al operador — y dónde se superponen la CVAA, el artículo 2 de la EAA y WCAG 2.2.
-
Encargue una auditoría manual
Lea nuestra guía para encargar una auditoría manual por personas con discapacidad — qué solicitar, cuánto presupuestar y qué plataformas incluyen una red de auditores reales con usuarios de RTT y usuarios con lengua de señas como primera lengua frente a las que subcontratan esto.