La compatibilidad con lectores de pantalla significa que el contenido, los controles y la estructura de un sitio web pueden entenderse y manejarse por completo mediante una tecnología de asistencia que lee la página en voz alta o la envía a una línea braille, en lugar de mirándola. Eso depende mucho más de cómo esté escrito el HTML subyacente que de cualquier función o plugin concreto. Hacerlo bien significa atender a la vez la estructura semántica, el orden de lectura, el etiquetado y la operabilidad por teclado, no a cada uno por separado.
Cómo experimenta realmente una página un lector de pantalla
Un lector de pantalla no ve el diseño visual de la forma en que lo hace un usuario vidente. Construye su propio modelo de la página a partir de la estructura semántica del HTML: encabezados, puntos de referencia (como <nav>, <main>, <footer>), listas, etiquetas de formulario, texto de enlaces y el orden en que aparecen los elementos en el DOM. Un usuario puede saltar entre encabezados, listar todos los enlaces de una página o saltar al siguiente campo de formulario, todo sin necesidad de escanear visualmente la pantalla. Si un sitio está construido con una sopa de <div> sin sentido, encabezados usados por su estilo visual y no por la estructura real del documento, o contenido reordenado visualmente mediante CSS de una forma que no coincide con el orden real del DOM, todo ese modelo de navegación se rompe aunque la página se vea perfectamente normal para un visitante vidente.
Los hábitos que marcan la diferencia en la compatibilidad
Un puñado de hábitos a nivel de código explica la mayoría de los problemas reales con los lectores de pantalla. Un texto alternativo con sentido en las imágenes que transmiten información (y un texto alternativo vacío en las puramente decorativas) es el fallo más común, presente en la gran mayoría de las páginas: el estudio WebAIM Million de 2026 encontró que el 83,9% de las páginas de inicio tenía texto de bajo contraste como el fallo más común de todos, seguido de cerca por el texto alternativo ausente o deficiente y los campos de formulario sin etiquetar. Más allá del texto alternativo, los otros hábitos que más importan son: una estructura de encabezados lógica que no se salte niveles, campos de formulario con etiquetas asociadas mediante código y no solo texto de marcador de posición, un orden de foco visible y lógico al recorrer la página con la tecla Tab, y texto de enlace descriptivo (“lea nuestra guía de cumplimiento de la EAA” en lugar de “haga clic aquí”).
Dónde encaja ARIA y dónde no
Los atributos ARIA (Aplicaciones de Internet Enriquecidas y Accesibles) existen para describir componentes interactivos personalizados, como un panel de pestañas o un cuadro combinado, para los que el HTML nativo no tiene un elemento incorporado. La regla más importante es recurrir primero al HTML nativo: un elemento <button> real ya gestiona correctamente la activación por teclado, el foco y el anuncio de su rol, mientras que un <div> con estilos y un manejador de clic necesita que todo eso se reconstruya manualmente con ARIA y JavaScript, y es fácil equivocarse en detalles sutiles. El uso incorrecto de ARIA, como un rol que no coincide con el comportamiento real del elemento, es una fuente bien documentada de confusión para los lectores de pantalla; puede anunciar un control de forma incorrecta o hacerlo directamente inalcanzable por teclado, lo cual suele ser peor para el usuario que si no se hubiera añadido ningún ARIA.
Probar su propio sitio
Las herramientas automatizadas son una primera pasada razonable. Algo construido sobre el motor axe-core, muy utilizado, como axe DevTools de Deque, detectará rápidamente un buen número de problemas estructurales y de etiquetado, y se integra en el flujo de trabajo habitual de un desarrollador. Pero los escaneos automatizados en general solo detectan una parte de lo que realmente importa para un usuario real de tecnología de asistencia; cosas como si un orden de lectura tiene sentido lógico en voz alta, o si un mensaje de error realmente se anuncia cuando falla el envío de un formulario, requieren que alguien use la página de verdad con un lector de pantalla activado. Para sitios de WordPress en concreto, WebYes se centra en identificar y corregir directamente este tipo de problemas a nivel de código en lugar de enmascararlos con un overlay, lo cual es un enfoque razonable si su equipo se siente cómodo haciendo los cambios necesarios en la plantilla y el tema.
Qué pueden y qué no pueden hacer aquí los widgets de accesibilidad
Los widgets y las herramientas de overlay, incluidos los que tienen funciones asistidas por IA como la generación automática de texto alternativo y el etiquetado ARIA de Wawsome, pueden ayudar de verdad a cerrar algunas carencias, en particular en sitios donde corregir el código subyacente no es realista a corto plazo. Lo que en general no pueden hacer es reestructurar el orden fundamental del DOM de una página, reescribir asociaciones de formulario rotas en todas las plantillas de un sitio, o garantizar que cada widget interactivo personalizado se comporte correctamente con un lector de pantalla. Las encuestas independientes a profesionales de la accesibilidad han encontrado sistemáticamente un escepticismo real sobre hasta dónde llegan realmente las correcciones automatizadas de los overlays; una encuesta vinculada a WebAIM encontró que el 67% de los profesionales calificaba los overlays como “nada” o “poco” eficaces, un porcentaje que sube al 72% entre los encuestados que tienen ellos mismos alguna discapacidad. La conclusión realista es que un widget puede ser una capa dentro de una estrategia de compatibilidad, pero la compatibilidad real con lectores de pantalla depende en última instancia de las decisiones de código tomadas al construir el sitio.
Contenido dinámico y aplicaciones de página única
Los sitios modernos que actualizan contenido sin recargar la página por completo (una lista de productos filtrada, un total de carrito en vivo, un mensaje de validación de formulario en línea) necesitan un mecanismo específico para avisar a la tecnología de asistencia de que algo cambió, ya que un lector de pantalla no tiene forma de detectar por sí solo una actualización silenciosa del DOM. Las regiones activas de ARIA se encargan de esto: marcar un contenedor como aria-live="polite" (o, para mensajes urgentes como un error, aria-live="assertive") le indica al lector de pantalla que anuncie el contenido nuevo en cuanto aparece. Este es uno de los patrones que más se pasan por alto en los sitios modernos con mucho JavaScript, ya que un cambio puede verse completo y evidente para un usuario vidente que mira la pantalla, mientras resulta totalmente silencioso para alguien que escucha a través de un lector de pantalla.
Lectores de pantalla en móvil
Los mismos principios se aplican en el móvil, pero las herramientas son distintas: VoiceOver en iOS y TalkBack en Android funcionan mediante gestos y no con el teclado, usando deslizamientos para moverse entre elementos y toques para activarlos. Un sitio probado con un lector de pantalla de escritorio no queda automáticamente verificado en móvil, ya que el tamaño de los objetivos táctiles, los conflictos de gestos con interacciones de deslizamiento personalizadas (como un carrusel de imágenes) y los cambios de diseño específicos del móvil pueden introducir problemas que no aparecen en una pasada de escritorio. Si una parte importante de su tráfico es móvil, algo cierto hoy para la mayoría de los sitios de comercio electrónico y de consumo, una pasada de lector de pantalla en móvil merece su propio tiempo de prueba dedicado, en lugar de tratarse como algo secundario a las pruebas de escritorio.
Una rutina básica de pruebas para empezar
Active NVDA (gratuito) o VoiceOver (integrado en todos los Mac e iPhone), navegue por su página de inicio y por una página clave de conversión (como un checkout o un formulario de contacto) usando solo el teclado y los propios comandos de navegación del lector de pantalla, y anote dónde se queda atascado, dónde no oye nada anunciado o dónde oye algo que no tiene sentido. Ese ejercicio de treinta minutos, repetido tras cualquier cambio importante del sitio, sacará a la luz más problemas reales que la mayoría de los escaneos automatizados por sí solos.
También vale la pena integrar esto en su proceso de publicación en lugar de tratarlo como un ejercicio puntual. Un cambio de diseño o de plantilla que se ve bien visualmente puede romper en silencio la estructura de encabezados, el orden de foco o el anuncio de una región activa, y esas regresiones son mucho más baratas de detectar antes de publicar que después de que los usuarios reales empiecen a toparse con ellas. Incluso una versión ligera de esto, una persona dedicando veinte minutos con un lector de pantalla a las páginas que cambiaron, aplicada de forma constante antes de cada publicación, detecta una parte importante de las regresiones que de otro modo se acumularían sin que nadie se dé cuenta.