Cumplimiento de audio WCAG 2.2 en WordPress: Guía 2026

El audio en WordPress debe satisfacer al menos cuatro criterios de éxito WCAG 2.2: 1.4.2 Control de Audio, 2.1.1 Teclado, 2.5.8 Tamaño del Objetivo (nuevo en 2.2) y 4.1.2 Nombre, Rol, Valor. La Ley Europea de Accesibilidad, en vigor desde el 28 de junio de 2025, convierte esto en una obligación legal para cualquier sitio que atienda a clientes de la UE. El reproductor de audio predeterminado de WordPress y la mayoría de plugins de audio de terceros incumplen varios de estos requisitos sin modificaciones.

Esta guía es la lista de verificación práctica que usamos en Mementor al auditar sitios WordPress para conformidad con WCAG 2.2. Cubrimos los dos aspectos del audio: el audio como contenido con sus propias reglas de accesibilidad, y el audio como herramienta de accesibilidad para el contenido textual.

Por qué el cumplimiento de audio es urgente en 2026

Tres factores convergieron en 2025 para convertir esto en un tema prioritario. La LEA comenzó su aplicación el 28 de junio de 2025. El informe WebAIM Million 2025 detectó fallos WCAG en el 96,3% de las páginas de inicio analizadas. Los litigios por la ADA en Estados Unidos siguieron en aumento, con sitios WordPress presentes de forma destacada en los más de 4.000 casos de accesibilidad web presentados durante el año.

El patrón que vemos en nuestras auditorías es siempre el mismo. Los propietarios de sitios asumen que su tema gestiona la accesibilidad. El tema hereda lo que entrega el plugin de audio. Y el plugin entrega botones demasiado pequeños, controles deslizantes que atrapan a los usuarios de teclado y ratios de contraste que no superan la primera comprobación manual.

La lista de verificación WCAG 2.2 completa para audio

Ocho criterios de éxito afectan directamente al audio en un sitio WordPress. La tabla siguiente muestra qué significa cada uno en la práctica, qué hace bien o mal el reproductor de audio predeterminado de WordPress, y cómo lo gestiona el reproductor de TTSWP. Los criterios marcados como NUEVO llegaron con WCAG 2.2 en octubre de 2023.

La página de Requisitos de Accesibilidad de Medios del W3C es la fuente de referencia para estos criterios. Nos centramos en los ocho anteriores porque se aplican directamente a los reproductores de audio. Los subtítulos (1.2.2) y la audiodescripción (1.2.3) también son relevantes, pero se aplican al vídeo, no a la narración de audio pura.

La excepción de alternativa de medios para texto

Esta es la regla que el noventa y cinco por ciento de los artículos sobre cumplimiento pasan por alto. WCAG define una alternativa de medios para texto como aquella que no presenta más información de la que ya contiene el texto. Cuando la narración TTS lee un artículo existente, el audio es una alternativa de medios para el texto de la página. El propio texto de la página es la transcripción.

Esto significa que una versión en audio de un artículo generada con TTS no necesita un archivo de transcripción separado. WebAIM lo explica con claridad. La condición es que el audio debe estar claramente identificado como alternativa de medios, para que los usuarios sepan que no pierden información si lo omiten. Un encabezado como «Escucha este artículo» o un reproductor etiquetado como «Versión en audio de esta entrada» cumple este requisito.

La excepción no se aplica si el audio añade comentarios, fondos musicales con significado o secciones que no aparecen en el texto. La narración pura del contenido de la página sí cumple el requisito. Aplicamos esta norma con frecuencia cuando asesoramos a clientes editoriales que temen que añadir audio genere nuevas obligaciones de transcripción.

Las novedades de WCAG 2.2 para audio

Tres nuevos criterios de Nivel AA afectan directamente a los reproductores de audio.

2.5.8 Tamaño del Objetivo (Mínimo)

Cada control interactivo necesita un área de toque de al menos 24 por 24 píxeles CSS. Este es el criterio que hace fallar a más plugins de audio para WordPress. En nuestras auditorías de sitios con plugins de audio de terceros, los botones de avance y retroceso están sistemáticamente por debajo del umbral. Los diseñadores priorizaron la compacidad antes de que WCAG 2.2 introdujera la regla de 24 píxeles, y pocos responsables de plugins se han puesto al día. Los estilos del tema predeterminado a veces reducen aún más el tamaño de los objetivos.

La solución suele ser añadir padding, no aumentar el tamaño del icono. Un icono SVG de 16 píxeles dentro de un botón con 4 píxeles de padding en cada lado alcanza el umbral de 24 píxeles sin cambiar el aspecto visual.

2.4.11 Foco No Oculto

Las barras de audio fijas en la parte inferior de la página tapan el elemento en el que está el foco del usuario de teclado. Si un enlace enfocado queda detrás de la barra, el criterio falla. La solución es hacer la barra descartable, dejar espacio por encima del elemento enfocado, o usar scroll-padding-bottom en el documento para que los elementos enfocados permanezcan visibles.

2.5.7 Movimientos de Arrastre

Las barras de desplazamiento personalizadas y los controles de volumen que solo funcionan con arrastre no superan este criterio. Toda interacción de arrastre necesita una alternativa con un solo puntero. Hacer clic para posicionar en una barra de progreso cumple el requisito. También lo hace el control mediante teclas de flecha en un role="slider" correctamente implementado.

Fallos habituales de audio en WordPress detectados en auditorías reales

Los mismos patrones se repiten en los sitios de nuestros clientes. Estos son los cuatro fallos más frecuentes.

El bloque <audio> predeterminado de WordPress renderiza el reproductor nativo del navegador. Los controles de audio nativos tienen un largo historial de comportamiento inconsistente con los lectores de pantalla, y el control del cabezal de reproducción con las teclas de flecha varía entre Chrome, Firefox y Safari. Los usuarios de NVDA o JAWS suelen escuchar las marcas de tiempo pero no pueden mover la posición de forma fiable con el teclado. La solución es envolver el audio en un reproductor personalizado que exponga role="slider" con los atributos de valor ARIA correspondientes.

Los reproductores de los plugins incluyen botones por debajo del umbral de 24 píxeles. El diseñador priorizó la compacidad antes de que WCAG 2.2 introdujera la regla. Los temas luego sobreescriben los estilos del plugin, a veces empeorando el resultado y a veces mejorándolo.

Las barras de audio fijas ocultan el contenido enfocado. Hemos comprobado este fallo en todos los sitios que usan un reproductor fijo en el pie de página sin haber probado la navegación por teclado.

El contraste de las formas de onda está sistemáticamente por debajo de 4.5:1. A los diseñadores les encanta la onda gris suave sobre fondo blanco. Los lectores de pantalla no se ven afectados, pero los usuarios con baja visión sí, y el criterio 1.4.3 falla.

Cómo construir un reproductor de audio accesible: lista de verificación técnica

1. Envuelve el reproductor en role="region" con un aria-label descriptivo.
2. Usa un elemento <button> real para reproducir, pausar, saltar y silenciar. Nunca un <div> con un manejador de clic.
3. Añade aria-pressed en el botón de reproducción para exponer el estado de alternancia.
4. Da a cada control un área mínima de 24 por 24 píxeles CSS usando padding.
5. Configura el scrubber y el volumen con role="slider" e incluye aria-valuemin, aria-valuemax y aria-valuenow, con respuesta a las teclas de flecha.
6. Habilita clic para posicionar en el scrubber como alternativa sin arrastre.
7. Verifica el contraste de cada elemento de texto e icono con significado a un mínimo de 4.5:1.
8. Asegúrate de que los anillos de foco sean visibles y no estén recortados por reglas de desbordamiento.
9. Si el reproductor es fijo, deja espacio de foco por encima o hazlo descartable.
10. Etiqueta los reproductores de narración TTS como «Versión en audio de este artículo» para que la excepción de alternativa de medios se aplique correctamente.

Un botón de reproducción accesible básico tiene este aspecto.

<div role="region" aria-label="Article audio player">
  <button type="button"
          aria-pressed="false"
          aria-label="Play article narration"
          style="min-width:24px;min-height:24px;padding:8px">
    <svg aria-hidden="true" width="16" height="16">...</svg>
  </button>
  <input type="range"
         aria-label="Playback position"
         min="0" max="100" value="0">
</div>

Esa es la estructura base. Dale estilo al botón, oculta los elementos visuales nativos del range si quieres una pista personalizada, pero mantén la semántica subyacente.

Cómo la narración TTS mejora el cumplimiento WCAG en general

El audio no es solo contenido al que hay que hacer accesible. Es en sí mismo una función de accesibilidad. La Organización Mundial de la Salud estima que 1.300 millones de personas, alrededor del 16% de la población mundial, viven con alguna discapacidad significativa. Muchas de ellas se benefician del acceso multimodal al contenido de texto: personas con dislexia, TDAH, baja visión y diversas discapacidades cognitivas leen con mayor comodidad cuando el audio acompaña al texto.

Añadir narración de texto a voz es una de las pocas inversiones en accesibilidad que beneficia a los usuarios antes de superar una auditoría. Añadir TTS a WordPress lleva menos de 15 minutos con el plugin Texto a Voz – TTSWP. El reproductor incluye de serie valores predeterminados conformes con WCAG 2.1 AA, objetivos de 24 píxeles o más, compatibilidad con teclado y roles ARIA correctos.

La carga mínima en tiempo de ejecución es de aproximadamente 35 a 40 KB comprimidos con gzip (151 KB sin minificar), cubriendo tanto la lógica del reproductor en JavaScript como el CSS compartido. Ejecutamos GTmetrix en un artículo publicado con el reproductor activo y obtuvimos una Nota A con un 93% de Rendimiento, un 99% de Estructura, Largest Contentful Paint en 1,3 segundos, Total Blocking Time en 46 milisegundos y Cumulative Layout Shift en cero. El bundle se carga de forma diferida solo en las páginas que contienen el reproductor, por lo que las páginas estáticas sin audio no añaden ninguna carga adicional.

La documentación de accesibilidad está en nuestra página de confianza y accesibilidad. La narración usa el motor generativo de ElevenLabs, que mejora la prosodia lo suficiente como para que los oyentes terminen los artículos en lugar de abandonarlos ante una lectura robótica.

La Ley Europea de Accesibilidad en la práctica

La LEA entró en vigor el 28 de junio de 2025. Los nuevos servicios digitales lanzados al mercado de la UE después de esa fecha deben cumplirla ya. Los servicios existentes tienen hasta el 28 de junio de 2030 para adaptarse completamente. La directiva se aplica a cualquier empresa que atienda a clientes de la UE, independientemente de dónde esté establecida.

La norma técnica a la que hace referencia la LEA es EN 301 549. La versión armonizada actual (V3.2.1, agosto de 2021) se basa en WCAG 2.1 Nivel AA. El borrador V4.1.0 publicado en noviembre de 2025 actualiza las cláusulas 9, 10 y 11 para alinearse con WCAG 2.2, con la armonización definitiva prevista para 2026. Hasta que esa actualización se publique en el Diario Oficial de la UE, WCAG 2.1 AA sigue siendo el mínimo legalmente vinculante. Aun así, recomendamos apuntar a WCAG 2.2 desde ahora, ya que la transición está a meses de distancia, no a años.

Las sanciones varían según el estado miembro. Alemania y Francia cuentan con la infraestructura de aplicación más activa, con autoridades nacionales de accesibilidad con competencias para investigar reclamaciones e imponer multas. Hemos visto a clientes alemanes recibir reclamaciones formales de usuarios finales pocos meses después de la fecha de entrada en vigor, generalmente relacionadas con componentes de audio y formularios. Las reclamaciones llegan antes que las multas, por lo que un plazo de corrección de treinta días suele ser alcanzable si el equipo está preparado.

Cómo verificar el cumplimiento

Las herramientas automáticas detectan entre el 30 y el 40% de los problemas. Las pruebas manuales son imprescindibles para el resto, especialmente la interacción por teclado y el contraste significativo en estados dinámicos.

• NVDA en Windows con Chrome y Firefox. Gratuito.
• JAWS en Windows para las expectativas de clientes empresariales.
• VoiceOver en macOS e iOS. Incluido en el sistema.
• TalkBack en Android. Incluido en el sistema.
• axe DevTools, extensión de navegador para análisis automatizados.
• Lighthouse en Chrome DevTools para comprobaciones rápidas.
• Navegación solo con teclado. Desconecta el ratón y opera cada control del reproductor.

La navegación solo con teclado es la prueba de mayor impacto. Si el reproductor funciona sin ratón, la mayor parte de WCAG 2.2 ya está cubierta.

Preguntas frecuentes

¿WCAG 2.2 exige subtítulos para los podcasts de audio?

No. Los subtítulos (1.2.2) se aplican al vídeo pregrabado con audio sincronizado. Para el contenido solo de audio, como los podcasts, el criterio relevante es el 1.2.1, que exige una alternativa en texto, ya sea una transcripción o un resumen detallado. Los subtítulos y las transcripciones tienen propósitos distintos. Un podcast necesita la transcripción. Un tutorial en vídeo necesita tanto subtítulos como audiodescripción para la información solo visual.

¿La reproducción automática de audio es ilegal bajo la LEA?

No es ilegal, pero sí está restringida. El criterio WCAG 1.4.2 Control de Audio, al que la LEA hace referencia a través de EN 301 549, exige que cualquier audio que se reproduzca automáticamente durante más de tres segundos ofrezca un control de pausa, detención o volumen independiente. La reproducción automática sin ese control incumple el Nivel A y constituye un hallazgo de no conformidad. La mayoría de los organismos de control lo tratan como una infracción clara, no como un caso límite.

¿Necesito una transcripción si tengo una versión en audio de mi artículo?

Normalmente no. Cuando el audio es una narración directa del texto del artículo y no añade información nueva, el propio texto del artículo es la transcripción según la definición de «alternativa de medios para texto» de WCAG. Etiqueta claramente el reproductor como versión en audio del artículo y la excepción se aplica. Si el audio incluye comentarios, música con significado o secciones que no están en el texto, sí necesitas una transcripción separada.

¿Cuál es el tamaño mínimo de botón para reproductores de audio en WCAG 2.2?

Los objetivos interactivos deben medir al menos 24 por 24 píxeles CSS según el criterio de éxito 2.5.8 Tamaño del Objetivo (Mínimo) de Nivel AA. El objetivo incluye el padding, por lo que un icono de 16 píxeles con 4 píxeles de padding en cada lado cumple el requisito. Existen excepciones para los enlaces en línea dentro del texto y los controles determinados por el agente de usuario, pero los botones independientes del reproductor no tienen excepción y deben alcanzar el umbral.

¿WCAG 2.2 se aplica a los sitios alojados en WordPress.com?

Sí. WCAG se aplica a cualquier contenido web independientemente de la plataforma de alojamiento. Los sitios en WordPress.com tienen la misma exposición legal bajo la LEA, la ADA y las leyes nacionales equivalentes que WordPress autogestionado. El modelo de alojamiento no cambia la obligación. Lo que cambia es el control que tiene el propietario del sitio sobre el marcado del reproductor. Los planes Business y Commerce de WordPress.com permiten plugins personalizados; los planes inferiores, no.

Por dónde empezar

Elige una entrada de tu sitio, haz una navegación solo con teclado del reproductor de audio y comprueba cada botón contra la regla de 24 píxeles. Esa única auditoría revela si tu configuración actual está cerca o lejos de cumplir con WCAG 2.2. A partir de ahí, la decisión es corregir el reproductor existente o reemplazarlo por uno que ya cumpla los requisitos de serie. Nuestra documentación de accesibilidad cubre la configuración que recomendamos para sitios con presión regulatoria de la LEA.