VoiceOver no funciona en WordPress de forma confiable porque el editor de bloques (Gutenberg) tiene problemas documentados con la navegación por teclado, el anuncio de contenido dinámico y el manejo de foco en modals. Los issues #18537 y #35122 del repositorio oficial de WordPress en GitHub registran estos comportamientos desde hace años, y en 2026 varios siguen sin resolución completa.
En 30 segundos
- VoiceOver es el lector de pantalla nativo de Apple (Mac e iOS), gratuito y activable con Cmd+F5. Es la herramienta principal que usan personas ciegas o con baja visión para navegar sitios WordPress.
- El editor de bloques tiene bugs conocidos: el block picker no anuncia sugerencias, las arrow keys pueden cerrar dropdowns inesperadamente, y el contenido dinámico no se lee en macOS Sonoma.
- VoiceOver funciona bien únicamente con Safari en macOS. En Firefox o Chrome el soporte es parcial o directamente roto.
- El plugin WP Accessibility corrige varios problemas de ARIA y navegación por teclado sin necesidad de tocar código.
- Para auditar tu sitio usá Lighthouse o axe DevTools en Safari, no en Chrome, o los resultados van a ser distintos a lo que ve un usuario real con VoiceOver.
Qué es VoiceOver y por qué importa en WordPress
VoiceOver es el lector de pantalla que Apple incluye en macOS, iOS y iPadOS sin costo adicional. No es un plugin ni un software de terceros: viene integrado en el sistema operativo y lo usan personas ciegas, con baja visión o con discapacidades motoras que no pueden usar mouse. Se activa en Mac con Cmd+F5 y lee en voz alta el contenido de la pantalla, los elementos interactivos y el estado de la interfaz.
Lo que hace especial a VoiceOver (y lo que lo diferencia de NVDA o JAWS en Windows) es que es el estándar de facto para testing de accesibilidad en dispositivos Apple, que tienen una cuota de mercado significativa en Argentina y Latinoamérica. Si tu sitio WordPress no funciona con VoiceOver, estás dejando afuera a una porción concreta de usuarios.
Desde el punto de vista normativo, las WCAG 2.2 (Web Content Accessibility Guidelines) publicadas por la W3C establecen criterios de éxito que, en la práctica, se verifican con lectores de pantalla como VoiceOver. No es un tema de buenas intenciones: en muchos países ya hay regulaciones que obligan a que los sitios web sean accesibles (AODA en Canadá, Section 508 en EE.UU., y normativa en proceso en varios países de la región).
Problemas más comunes de VoiceOver no funciona en WordPress
Si instalaste WordPress en algún momento y lo probaste con VoiceOver, probablemente te topaste con alguno de estos:
- Menús responsive sin anuncio de estado: el navigation block colapsa en móvil pero VoiceOver no siempre anuncia si el menú está abierto o cerrado. El botón hamburgesa carece de aria-label descriptivo en muchos temas.
- Arrow keys que cierran modals: dentro de un dropdown o modal, las flechas de teclado que un usuario de VoiceOver usa para explorar terminan cerrando el elemento. El foco «escapa» sin aviso.
- Contenido dinámico no anunciado: cuando cargás resultados de búsqueda, paginación AJAX o mensajes de error por JavaScript, VoiceOver no los lee a menos que uses aria-live correctamente.
- Campos de formulario sin etiqueta: muchos themes y page builders generan inputs donde el placeholder hace las veces de label. Cuando VoiceOver enfoca el campo, el placeholder desaparece y no hay label accesible que lo reemplace.
- aria-invalid leído de forma confusa: según la documentación de la W3C, aria-invalid=»true» debe combinarse con aria-describedby apuntando al mensaje de error. Sin eso, VoiceOver solo dice «inválido» sin contexto.
Nada de esto es exclusivo de WordPress, pero la combinación de themes de terceros, plugins de formularios y el editor de bloques lo convierte en un campo minado. Lo explicamos a fondo en nuestro artículo sobre la comunidad de WordPress y sus recursos.
Problemas específicos en el editor de bloques (Gutenberg)
Ponele que sos un editor de contenidos que usa VoiceOver para cargar artículos en WordPress. Abrís el block picker con la barra «/» y empezás a escribir «imagen». Gutenberg muestra sugerencias visuales, pero VoiceOver no anuncia nada. Tenés que adivinar si hay resultados o no.
Ese es el issue GitHub #18537, abierto desde 2019 y todavía con casos sin resolver en 2026. No es el único. El issue #35122 documenta problemas de keyboard navigation donde las arrow keys producen comportamientos inesperados: en vez de mover el foco al siguiente elemento, cierran el panel abierto o mueven el cursor fuera del área de edición.
En macOS Sonoma (2023) el problema se complicó más. El handoff entre VoiceOver y Safari cambió algunos comportamientos de foco, y ciertos elementos del editor que antes se leían empezaron a quedar mudos. ¿Alguien verificó esto antes del release de Sonoma? Por los issues abiertos, parece que no de forma sistemática.
Lo que sí mejoró en Gutenberg durante 2025-2026 es el soporte de landmarks semánticos: el editor ahora tiene regiones ARIA mejor definidas que antes. Pero eso no resuelve los bugs de interacción específicos.
Navegadores y limitaciones: Safari, Chrome o Firefox
Acá viene algo que mucha gente no sabe y que explica por qué los tests de accesibilidad dan resultados distintos según el navegador que usés.
VoiceOver solo funciona completo con Safari en macOS. El soporte en Firefox es parcial. En Chrome es limitado. Opera tiene algo, pero es inconsistente. Esto no es una preferencia de Apple: es que VoiceOver usa las APIs de accesibilidad del sistema operativo, y Safari tiene integración nativa con esas APIs que los otros navegadores no replican igual.
| Navegador | Compatibilidad con VoiceOver (macOS) | Recomendado para testing |
|---|---|---|
| Safari | Completa | Sí, es el estándar |
| Firefox | Parcial (mejora con cada versión) | Solo como referencia secundaria |
| Chrome | Limitada | No para VoiceOver |
| Opera | Inconsistente | No |
La consecuencia práctica es que si auditás tu WordPress con Lighthouse en Chrome, los resultados de accesibilidad no van a reflejar la experiencia real de un usuario con VoiceOver. Usá Safari para las pruebas manuales. Sobre eso hablamos en crear landing pages accesibles.
Cómo verificar si tu WordPress es compatible con VoiceOver
El proceso no es complicado, pero requiere un poco de tiempo la primera vez.
Paso a paso en macOS
- Activar VoiceOver: Cmd+F5 en Mac, o ir a Preferencias del Sistema > Accesibilidad > VoiceOver. En iOS/iPadOS: Configuración > Accesibilidad > VoiceOver.
- Abrir tu sitio en Safari (no en Chrome). Navegá con Tab para moverte entre elementos interactivos y con las flechas para leer el contenido.
- Usar el Rotor: girá dos dedos en el trackpad para activar el menú Rotor de VoiceOver. Desde ahí podés navegar por headings, links, formularios y landmarks. Si tu sitio tiene estructura semántica correcta, la navegación va a ser fluida.
- Probar el menú de navegación: abrí el menú hamburguesa si lo hay. Fijate si VoiceOver anuncia «menú abierto» y «menú cerrado» al interactuar.
- Testear formularios: enfocá cada campo. VoiceOver debe leer la etiqueta del campo (no el placeholder). Si solo escuchás «campo de texto» sin descripción, hay un problema de accesibilidad.
Herramientas de auditoría complementarias
Lighthouse en Safari (sí, también existe) o axe DevTools como extensión del browser te dan un reporte automatizado. Lighthouse corre desde DevTools y tiene una pestaña específica de Accessibility que puntúa de 0 a 100. Apuntá a 90+, pero recordá que las herramientas automáticas solo detectan el 30-40% de los problemas de accesibilidad. El resto se encuentra con testing manual.
Cuando buscás un tema en WordPress.org, filtrá por la etiqueta «Accessibility Ready». Es un criterio de revisión formal: los temas con esa etiqueta pasaron por un proceso de verificación que incluye compatibilidad con lectores de pantalla. No garantiza el 100%, pero es un buen punto de partida.
Soluciones y mejores prácticas para que VoiceOver funcione
Si encontraste problemas en tu auditoría, las soluciones dependen de dónde está el error.
ARIA correctamente implementado
Según la documentación de MDN sobre ARIA, las implementaciones incorrectas son peores que no usar ARIA. El patrón más común en WordPress es usar aria-invalid sin el mensaje asociado. La forma correcta:
- aria-invalid=»true» en el input con error
- aria-describedby apuntando al ID del mensaje de error
- role=»alert» en el contenedor del mensaje para que VoiceOver lo anuncie automáticamente
Para contenido dinámico (resultados de búsqueda, notificaciones, cambios de estado), usá aria-live=»polite» para contenido no urgente y aria-live=»assertive» para errores críticos. El atributo le dice a VoiceOver que hay contenido nuevo sin que el usuario lo solicite.
Landmarks y estructura semántica
Los landmarks HTML5 son el equivalente de un mapa para VoiceOver. Si tu theme usa `
Revisá que tu theme no tenga múltiples `
Formularios: la zona de mayor riesgo
Cada input necesita un `
Plugins y temas para mejorar la accesibilidad en WordPress
El plugin WP Accessibility resuelve varios problemas con una sola instalación: agrega skip links, arregla el contraste de los textos de los links, añade lang attribute al elemento HTML, y corrige algunos problemas de ARIA en temas que no lo implementan bien. No es mágico (no va a solucionar bugs del editor de Gutenberg), pero sí resuelve los problemas más frecuentes del frontend público.
Para temas, buscá en WordPress.org con el filtro «Accessibility Ready». Temas como Twenty Twenty-Four (el tema oficial 2024, que sigue siendo referencia en 2026) implementan correctamente los landmarks y la navegación por teclado. Si vas a arrancar un proyecto nuevo, partí de una base accesible es infinitamente más fácil que corregir un tema roto después.
| Solución | Qué resuelve | Dificultad de implementación |
|---|---|---|
| Plugin WP Accessibility | Skip links, ARIA básico, contraste, lang | Baja (instalar y configurar) |
| Temas con etiqueta «Accessibility Ready» | Estructura semántica base | Baja (elegir bien desde el principio) |
| Implementación manual de ARIA | Casos específicos: formularios, modals, alerts | Media (requiere conocer ARIA) |
| Testing con VoiceOver + Safari | Detectar problemas reales de UX | Media (requiere tiempo y práctica) |
| axe DevTools / Lighthouse | Auditoría automatizada (30-40% de issues) | Baja (extensión de navegador) |
Si el sitio tiene formularios complejos o un WooCommerce con checkout, el testing manual con VoiceOver es inevitable. Las herramientas automáticas no van a encontrar el problema del campo sin label si el label existe en el DOM pero está asociado con el id incorrecto.
Qué está confirmado y qué no
- Confirmado: Los issues #18537 y #35122 de Gutenberg están abiertos y documentan bugs reales con VoiceOver en el editor de bloques.
- Confirmado: VoiceOver solo funciona completo con Safari en macOS. No es un rumor ni una preferencia.
- Confirmado: El plugin WP Accessibility resuelve problemas de accesibilidad del frontend público sin necesitar código custom.
- Confirmado: Los temas con etiqueta «Accessibility Ready» en WordPress.org pasaron una revisión formal de accesibilidad.
- Sin confirmar / en proceso: No hay un roadmap público de Automattic con fechas concretas para resolver todos los issues de VoiceOver en Gutenberg. Algunas mejoras llegan con cada release, pero el trabajo está en curso sin fecha de cierre.
- Sin confirmar: El impacto exacto de macOS Sonoma en el comportamiento de VoiceOver con el editor no tiene documentación oficial de WordPress. Los reportes son de usuarios en los issues de GitHub.
Errores comunes al intentar hacer WordPress accesible para VoiceOver
Auditar con Chrome en vez de Safari
Ya lo mencioné pero vale repetirlo porque es el error más frecuente: si corrés Lighthouse en Chrome y el score de accesibilidad es 95, eso no significa que VoiceOver funcione bien en tu sitio. Chrome y VoiceOver no se llevan bien. El testing real de VoiceOver se hace en Safari, sin excepciones.
Usar placeholder como etiqueta de formulario
Esto pasa mucho en diseños minimalistas donde el placeholder dice «Tu nombre» o «Email». Visualmente se ve limpio. Para VoiceOver, cuando el usuario enfoca el campo, no hay etiqueta accesible. Y cuando empieza a escribir, el placeholder desaparece y el campo queda sin identificación. El `
Agregar ARIA «por las dudas» sin entender cómo funciona
Hay una tentación de agregarle role=»button» a todo lo que parece un botón, o aria-label a todo elemento. El problema es que ARIA incorrecto es peor que nada. Si marcás un `
Preguntas Frecuentes
¿Por qué VoiceOver no funciona con mi sitio WordPress?
Los problemas más comunes son: formularios sin labels accesibles, contenido dinámico sin aria-live, menús sin anuncio de estado, y estructura HTML sin landmarks semánticos. Si usás el editor de Gutenberg, hay bugs adicionales documentados en los issues de GitHub que afectan la navegación por teclado dentro del editor.
¿Qué navegador debo usar para testear VoiceOver en WordPress?
Safari en macOS. VoiceOver tiene integración nativa con Safari a través de las APIs de accesibilidad del sistema operativo. En Chrome o Firefox el comportamiento es parcial o inconsistente, y los resultados no reflejan la experiencia real de un usuario con VoiceOver.
¿Cómo hago que WordPress sea compatible con VoiceOver?
Empezá por instalar el plugin WP Accessibility, que resuelve los problemas más frecuentes del frontend. Después elegí un tema con etiqueta «Accessibility Ready» en WordPress.org. Para formularios, verificá que cada input tenga un `
¿Por qué VoiceOver cierra mi menú dropdown en WordPress?
Es un bug documentado en el repositorio de Gutenberg: las arrow keys que VoiceOver usa para navegar entre elementos interfieren con los eventos de teclado del componente del menú. El foco «escapa» del dropdown sin que el usuario lo indique. La solución correcta involucra manejar el evento keydown en el componente y asegurarse de que las arrow keys no propaguen eventos que cierren el elemento.
¿Cómo pruebo mi sitio WordPress con VoiceOver paso a paso?
Activá VoiceOver con Cmd+F5 en Mac, abrí tu sitio en Safari y navegá con Tab entre elementos interactivos. Usá el Rotor (dos dedos girando en el trackpad) para navegar por headings y landmarks. Probá abrir y cerrar el menú, completar un formulario, y activar cualquier elemento interactivo. Si escuchás «sin etiqueta», «botón» sin descripción o el foco se pierde en algún punto, tenés problemas que corregir.
Conclusión
VoiceOver no funciona en WordPress de forma confiable no es un problema que se resuelva con un plugin mágico. Hay capas: bugs en el editor de Gutenberg que el equipo de WordPress está corrigiendo de forma incremental, problemas de implementación en themes y plugins de terceros, y errores de ARIA que aparecen cuando el código se escribe sin testing con lectores de pantalla.
Lo que podés hacer ahora es concreto: instalar WP Accessibility, auditar con axe DevTools en Safari, corregir los formularios sin labels, y si estás eligiendo un tema nuevo, que tenga la etiqueta «Accessibility Ready». Para el editor de Gutenberg, los bugs documentados van mejorando con cada versión de WordPress, así que mantener el core actualizado es parte de la solución (no la única, pero sí una).
El tema de la accesibilidad tiene más impacto del que parece: no solo mejora la experiencia de usuarios con discapacidades, sino que un sitio con buena estructura semántica y navegación por teclado también es mejor para SEO y para usuarios en dispositivos táctiles. Y si tu sitio tiene un checkout de WooCommerce, empezar a ignorar esto en 2026 es un riesgo legal que no vale la pena correr.
