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.