Vista previa del lector de pantalla

Pega HTML para ver cómo un lector de pantalla lo linealizaría y lo anunciaría. Comprueba tus textos alternativos, tus encabezados y tus atributos ARIA.

Salida del lector de pantalla

Pega HTML y haz clic en Analizar.
📚 Bases científicas y fuentes

Para quién está diseñada esta herramienta

Los lectores de pantalla son una tecnología de asistencia esencial para las personas ciegas o con una deficiencia visual importante. Según el Informe mundial sobre la visión de la OMS (2019), al menos 2200 millones de personas en el mundo sufren una deficiencia visual, de las cuales cerca de 43 millones son ciegas. La encuesta WebAIM Screen Reader Survey (2024) constata sistemáticamente que la gran mayoría de los usuarios de lectores de pantalla son personas con discapacidad, siendo la ceguera la razón más frecuente. Desarrolladores, diseñadores y creadores de contenido usan esta herramienta para previsualizar cómo interpretarán su HTML las tecnologías de asistencia, lo que ayuda a detectar textos alternativos que faltan, estructuras de títulos incorrectas, botones y campos sin nombre accesible, y usos erróneos de ARIA, antes de que los encuentren los usuarios finales.

Cómo funciona esta herramienta

Esta herramienta analiza tu HTML mediante el DOMParser nativo del navegador (ningún dato sale de tu dispositivo) y luego recorre el árbol de accesibilidad para construir un orden de lectura linealizado. Comprueba la presencia de textos alternativos en las imágenes, la coherencia de los niveles de título, los enlaces y botones sin nombre accesible, los roles y etiquetas ARIA, así como los campos de formulario sin etiqueta asociada.

Referencias científicas

  • WebAIM (2024). «Screen Reader User Survey #10 Results.» webaim.org · La mayor encuesta continua sobre los modos de uso de los lectores de pantalla, las combinaciones de navegadores y los obstáculos a la accesibilidad. Constata sistemáticamente que los títulos y las referencias (landmarks) son las principales estrategias de navegación de los usuarios.
  • Organización Mundial de la Salud (2019). Informe mundial sobre la visión. · Informa de que al menos 2200 millones de personas en el mundo sufren una deficiencia visual de cerca o de lejos, de las cuales unos 43 millones son ciegas.
  • Power, C., Freire, A., Petrie, H. y Swallow, D. (2012). «Guidelines are only half of the story: Accessibility problems encountered by blind users on the web.» Proceedings of the SIGCHI Conference on Human Factors in Computing Systems (CHI '12). · Constató que una parte importante de los problemas de accesibilidad que encuentran los usuarios ciegos no los cubrían las WCAG por sí solas, subrayando la necesidad de una revisión manual y pruebas con lector de pantalla.
  • Lazar, J., Allen, A., Kleinman, J. y Malarkey, C. (2007). «What frustrates screen reader users on the web: A study of 100 blind users.» International Journal of Human-Computer Interaction, 22(3), 247–269. · Identificó los textos alternativos que faltan, los campos de formulario sin etiqueta y las etiquetas de enlace engañosas entre las principales frustraciones reportadas por los usuarios ciegos.
  • W3C WAI (2023). «WAI-ARIA Authoring Practices 1.2.» · Define cómo deben usarse los roles, estados y propiedades para hacer accesible el contenido dinámico a las tecnologías de asistencia.

Aviso

Esta herramienta proporciona una aproximación simplificada de la salida de un lector de pantalla basada en el árbol de accesibilidad HTML. Los lectores de pantalla reales (NVDA, JAWS, VoiceOver, TalkBack) difieren en cómo anuncian el contenido, gestionan los atributos ARIA e interactúan con los widgets dinámicos. Esta vista previa no sustituye las pruebas con lectores de pantalla reales y usuarios reales. Está pensada para detectar problemas habituales temprano en el proceso de redacción.

Una breve historia de los estándares de accesibilidad web

La accesibilidad en la web se rige por una pequeña pila de estándares de la Iniciativa de Accesibilidad Web W3C (WAI), más las leyes nacionales que los referencian. WCAG 1.0 se publicó en mayo de 1999, la primera guía formal sobre cómo hacer accesible el contenido web. Era en gran medida centrada en HTML y rápidamente quedó desactualizada. WCAG 2.0 (diciembre de 2008) fue una reescritura importante organizada en torno a cuatro principios (Perceptible, Operable, Comprensible, Robusto) y tres niveles de conformidad (A, AA, AAA). Se convirtió en un estándar ISO (ISO/IEC 40500) en 2012 y es el objetivo de conformidad que la mayoría de las leyes aún referencian. WCAG 2.1 (junio de 2018) añadió 17 nuevos criterios de éxito cubriendo móvil, baja visión y discapacidades cognitivas. WCAG 2.2 (octubre de 2023) añadió 9 más, notablemente 2.4.11 Foco No Oscurecido y 3.3.8 Autenticación Accesible. WAI-ARIA 1.0 se finalizó en marzo de 2014; 1.2 en junio de 2023 es la Recomendación actual. En el lado legal, la Actualización Sección 508 de EE.UU. (enero de 2018) incorporó WCAG 2.0 AA en la contratación federal de EE.UU. La Ley Europea de Accesibilidad (Directiva 2019/882) entró en vigor el 28 de junio de 2025, requiriendo que la mayoría de los productos digitales orientados al consumidor en la UE cumplan con los estándares de accesibilidad. La mayoría de los países referencian WCAG, así que construir para WCAG 2.2 AA es el objetivo práctico para cualquier producto global hoy.

El panorama de lectores de pantalla hoy

El WebAIM Screen Reader User Survey #10 (2024) es la fuente canónica sobre qué lectores de pantalla la gente realmente usa. Cinco productos dominan escritorio, móvil y ChromeOS.

  • JAWS (Freedom Scientific, primer lanzamiento 1989) es el líder comercial de larga data en Windows. Cuesta ~$1000+. WebAIM 2024 lo encuentra como el lector de pantalla principal para alrededor del 40% de los encuestados, ligeramente por debajo de NVDA.
  • NVDA (NV Access, primer lanzamiento 2006, escrito en Python) es la alternativa de código abierto para Windows. Gratis. WebAIM 2024 lo reporta como el lector de pantalla principal más usado, alrededor del 47% de los encuestados. El crecimiento de NVDA de una herramienta de nicho a líder del mercado en 15 años es una de las grandes historias de éxito de código abierto en tecnología asistiva.
  • VoiceOver (Apple, 2005 en macOS, 2009 en iOS) viene integrado en cada Mac, iPhone, iPad, Apple Watch, Apple TV. Es el lector de pantalla móvil más usado. Estrechamente integrado con Safari y el rotor iOS para navegación.
  • TalkBack (Google, 2009 en Android) es el equivalente Android. Código abierto desde Android 4. Usa gestos y el menú de navegación.
  • ChromeVox (Google, 2012) y Narrator (Microsoft, 2000, modernizado en Windows 10) completan el panorama. Cada uno tiene una base de usuarios pequeña pero leal.

Una sola página puede ser anunciada de manera diferente por cada producto. Las páginas robustas prueban limpiamente en al menos dos: usualmente NVDA + Firefox o Chrome, y VoiceOver + Safari.

Cuándo recurrir a esta herramienta

  • Auditorías previas al lanzamiento. Pega una página clave (página principal, formulario de registro, checkout) y lee la salida linealizada en voz alta. Si no tiene sentido para ti, no tendrá sentido para un usuario de lector de pantalla.
  • Revisiones de código. Antes de fusionar un PR con cambios significativos de marcado, pega el HTML renderizado y confirma que los encabezados, puntos de referencia y texto alternativo sobrevivieron intactos.
  • Verificación de transferencia de diseño. Los diseñadores pueden pegar su HTML final para confirmar que la jerarquía visual coincide con la jerarquía semántica. Una página que parece un encabezado debería serlo también en el DOM.
  • Enseñar accesibilidad. Muestra a una clase o equipo lo que un lector de pantalla realmente recibe. La brecha entre el diseño visual y la salida linealizada es a menudo la primera vez que los desarrolladores no discapacitados entienden por qué importa el HTML semántico.
  • Verificaciones de cumplimiento con WCAG. Verificaciones rápidas para los cuatro criterios más violados: 1.1.1 Contenido no textual (texto alternativo), 1.3.1 Información y relaciones (estructura semántica), 2.4.4 Propósito del enlace, 4.1.2 Nombre, rol, valor.
  • Verificaciones de sitio CMS / no-code. Los editores visuales a menudo producen divs en lugar de encabezados o enlaces sin texto. Pega el HTML publicado, ve qué se coló.
  • Accesibilidad de plantillas de email. Los emails HTML son notoriamente difíciles de hacer accesibles. Usa la vista previa para verificar el texto alternativo en cada imagen, orden adecuado de encabezados y flujo de lectura legible.

Errores comunes que los lectores de pantalla exponen

  • Texto alternativo faltante o inútil. alt="image", alt="photo", alt="logo" son apenas mejor que nada. Lazar et al. (2007) identificaron el texto alternativo faltante como la principal frustración de los usuarios web ciegos. Escribe texto alternativo que transmita el propósito de la imagen en el contexto circundante, o usa alt="" para imágenes puramente decorativas para que el lector de pantalla las salte.
  • Niveles de encabezado que saltan o reinician. Ir de h1 a h3 saltando h2 confunde la navegación. Usar múltiples elementos h1 en la misma página (un patrón bastante común en diseño basado en componentes) rompe el esquema del documento por el que navegan los usuarios de lectores de pantalla. WebAIM 2024 encuentra que los encabezados son la estrategia de navegación más común para los usuarios de lectores de pantalla.
  • Divitis. Envolver texto clicable en <div> con un manejador de clic en lugar de usar <button> o <a> significa sin soporte de teclado, sin anillo de foco, sin anuncio de rol. Siempre empieza desde HTML semántico y añade ARIA solo cuando ningún elemento nativo encaje.
  • ARIA usado donde HTML serviría. Primera regla de ARIA (según las Prácticas de Autoría WAI-ARIA del W3C): «si puedes usar un elemento HTML nativo... hazlo». <button role="button"> es redundante; <div role="button"> es una señal de que deberías usar un botón real en su lugar.
  • ARIA usado incorrectamente. aria-hidden="true" en un elemento focusable lo hace invisible a los lectores de pantalla pero aún focusable con teclado, una receta para un orden de tabulación desorientador. role="button" sin tabindex="0" y manejadores de teclado no hace nada útil.
  • Campos de formulario sin etiquetas. Un <input> sin una <label>, aria-label o aria-labelledby asociado se anuncia como «edit, blank» sin contexto. El texto del placeholder no es un sustituto, desaparece al enfocar y a menudo falla en contraste.
  • Enlaces «click here» y «read more». Los usuarios de lectores de pantalla a menudo navegan al pedir la lista de todos los enlaces en la página. «Click here» solo no les dice nada. Haz que el texto del enlace describa el destino: «Lee la encuesta WebAIM 2024» vence a «Lee más aquí».
  • Eliminar estilos de foco. outline: none sin un indicador de foco de reemplazo es uno de los criterios WCAG más violados (2.4.7 Foco Visible). Los usuarios de teclado, incluyendo muchos usuarios de lectores de pantalla, necesitan ver dónde está el foco.

ARIA en un vistazo: qué hace cada tipo de rol

  • Roles de punto de referencia (banner, navigation, main, complementary, contentinfo, search) dividen la página en regiones entre las que un usuario de lector de pantalla puede saltar. La mayoría tiene equivalentes HTML nativos (<header>, <nav>, <main>, <aside>, <footer>). Usa el elemento nativo primero.
  • Roles de widget (button, checkbox, combobox, menu, tabpanel, etc.) describen controles interactivos. Los roles de widget implican patrones de interacción de teclado que la Guía de Prácticas de Autoría ARIA del W3C (APG) documenta en detalle. Si no puedes coincidir con la especificación APG exactamente, prefiere HTML nativo.
  • Roles de estructura de documento (article, list, listitem, row, cell, etc.) describen contenido no interactivo. La mayoría también tiene equivalentes HTML nativos. Úsalos solo cuando el elemento nativo no esté disponible (e.g., construir una cuadrícula de datos personalizada donde <table> no encaje).
  • Regiones en vivo (aria-live="polite", aria-live="assertive", role="status", role="alert") le dicen a los lectores de pantalla que anuncien actualizaciones dinámicas sin mover el foco. Usado para mensajes de chat, errores de formulario, estados de carga. El uso excesivo causa fatiga de notificación; reserva assertive para emergencias genuinas como estados de error.

Más preguntas frecuentes

¿Coincide esta vista previa con lo que NVDA / JAWS / VoiceOver realmente dirán?

Se aproxima. Esta herramienta lee el árbol de accesibilidad del navegador (la misma estructura que usan los lectores de pantalla) y produce una versión linealizada de lo que se anunciaría. Los lectores de pantalla reales añaden comportamientos específicos del producto: anuncios de cambios de foco, navegación de tablas, encabezados de tabla, conteos de elementos de lista, manejo de la cortesía ARIA-live, configuraciones de verbosidad personalizadas. Trata la vista previa como una primera verificación de cordura; para lanzamientos en producción, prueba con al menos un lector de pantalla real en los sistemas operativos que usa tu audiencia.

¿Cuál es la diferencia entre WCAG y ARIA?

WCAG (Pautas de Accesibilidad para el Contenido Web) es una lista de requisitos: «cada contenido no textual debe tener una alternativa textual». Te dice qué lograr pero no siempre cómo. ARIA (Accessible Rich Internet Applications) es una de las herramientas para cumplir con WCAG: un conjunto de atributos HTML (roles, estados, propiedades) que exponen la semántica a la tecnología asistiva cuando el HTML nativo es insuficiente. Puedes cumplir con WCAG sin ARIA en absoluto si tu HTML es lo suficientemente semántico. ARIA es para los casos donde no lo es.

¿Cómo escribo buen texto alternativo?

Tres reglas del Árbol de Decisión alt del W3C: (1) Si la imagen es puramente decorativa, usa alt="" para que el lector de pantalla la salte por completo. (2) Si la imagen transmite información que no está ya en el texto circundante, describe esa información de manera concisa (típicamente bajo 125 caracteres). (3) Si la imagen es funcional (e.g., un logo que enlaza a la página principal o un botón de icono), describe la acción en lugar de la apariencia. «Buscar» vence a «icono de lupa». Evita «imagen de...», «foto de...», los lectores de pantalla ya anuncian que el elemento es una imagen.

Mi sitio usa divs por todas partes. ¿Por dónde empiezo?

Empieza añadiendo los cinco elementos de punto de referencia: <header>, <nav>, <main>, <aside>, <footer>. Luego reemplaza los divs clicables con <button> (para acciones) o <a> (para navegación). Luego audita los encabezados: cada página debería tener un <h1> y el resto en orden anidado. Estos tres pasos arreglan quizás el 70% de los problemas de accesibilidad en un sitio típico cargado de divs. ARIA y la gestión de foco JavaScript vienen después, una vez que la base semántica está en su lugar.

¿Se envía el HTML que pego aquí a algún lugar?

No. El análisis usa el DOMParser integrado del navegador y el análisis se ejecuta enteramente del lado del cliente. Abre la pestaña Red en DevTools y haz clic en Analizar, verás cero solicitudes salientes durante la linealización. Seguro para plantillas internas, páginas no lanzadas o HTML que contenga datos de clientes.

Herramientas relacionadas

Comprobador de encabezamientos WCAG Recursos de accesibilidad Generador de paletas de colores accesibles Verificador de contraste de colores