Casi todos los programas de accesibilidad que se auditan registran el mismo dato: un noventa y tantos por ciento de los desarrolladores de frontend afirman «probar con un lector de pantalla». Si se les pide una demostración, la demostración suele ser siempre la misma: tres pulsaciones de tecla — encender, navegar con tabulador por la página, apagar. Eso no es una prueba. Es marcar una casilla.

La razón por la que ocurre esto es estructural, no por dejadez. Un lector de pantalla no es una herramienta que pueda adoptarse como si fuera un nuevo linter. Es un modelo de interacción diferente con su propio estado modal, su propia gramática de atajos y un conjunto de convenciones que solo tienen sentido después de haberlo utilizado durante varias horas de trabajo real. Hasta que no se supera ese umbral, la herramienta dice casi nada — y, peor aún, dice cosas erróneas, porque los anuncios que se escuchan dependen del modo del lector, del árbol de accesibilidad del navegador y de la capa IME de la plataforma de maneras que no son evidentes desde fuera.

La fluidez, a efectos de este artículo, es el punto en el que se puede entregar a un compañero un componente defectuoso, tomar su teclado y reproducir el fallo con el lector de pantalla activo — sin mirar la pantalla, sin consultar una hoja de referencia rápida y sin empeorar el anuncio respecto a cómo sonaría en un uso real. La familiaridad es el punto en el que se ha oído un lector de pantalla. La brecha entre ambas equivale a unas treinta o treinta y cinco horas de práctica deliberada.

El mercado cuenta con tres lectores de pantalla relevantes para el trabajo web en escritorio: NVDA en Windows, VoiceOver en macOS e iOS, y JAWS en Windows. Cada uno tiene una base de usuarios suficientemente amplia como para que ignorarlo suponga un riesgo real, y cada uno anuncia el mismo marcado de forma ligeramente diferente. Un desarrollador fluido puede manejar al menos dos de ellos.

La recomendación, tras observar a decenas de desarrolladores superar el umbral, es inequívoca: empezar con NVDA en Windows y VoiceOver en macOS. Ambos son gratuitos. Ambos vienen preinstalados (VoiceOver) o se instalan en menos de cinco minutos (NVDA). Ambos los utilizan suficientes usuarios reales — NVDA acumula aprox. el 65% de la cuota de mercado de lectores de pantalla en Windows según la encuesta WebAIM más reciente, VoiceOver domina el móvil y una parte significativa del escritorio macOS — como para que lo que se aprenda se transfiera de inmediato a fallos en los que se puede publicar una corrección. JAWS es la tercera herramienta, no la primera, aunque siga siendo el lector de pantalla con la mayor base instalada en entornos corporativos. Tres razones.

Las tres razones para posponer JAWS son pedagógicas, no políticas. En primer lugar, JAWS y NVDA comparten un modelo mental — el modo de exploración frente al modo de foco en Windows, el mismo prefijo de comando basado en Insert, el mismo búfer virtual — de modo que, una vez dominado NVDA, el noventa por ciento de los comandos de JAWS que se necesitan realmente son solo una búsqueda en el glosario. En segundo lugar, JAWS acumula décadas de inferencia «inteligente»: intenta corregir el marcado defectuoso antes de que el usuario lo escuche, lo que significa que un fallo que JAWS suaviza seguirá llegando a los usuarios de NVDA. El comportamiento deliberadamente conservador de NVDA lo convierte en el lector de referencia cuando se trata de aprender qué está roto. En tercer lugar, la fricción de licencia de JAWS — la activación, el modo de prueba de cuarenta minutos que notifica en cada reinicio — es una carga de aprendizaje que no es necesario asumir hasta que se disponga de confianza suficiente para afrontarla.

VoiceOver se combina con NVDA en lugar de competir con él porque los dos lectores representan los dos modelos de interacción dominantes. NVDA (y JAWS) utilizan el modelo de «cursor de PC»: un búfer virtual que dispone la página como un documento lineal y un foco separado que sigue el orden de tabulación. VoiceOver utiliza un único cursor de VoiceOver que se superpone al foco, navegado por el rotor y por las teclas VO+flecha. Un desarrollador fluido en solo uno de los modelos escribirá código que anuncia bien en su lector y mal en el otro. Aprender ambos a la vez es la única forma fiable de percibir la diferencia.

El programa de la primera semana tiene una única regla: apagar el monitor. No atenuarlo, no minimizarlo, no «cerraré los ojos» — apagarlo físicamente, o cubrirlo con un trozo de cartón si el monitor es el único en la sala. El objetivo es eliminar la posibilidad de hacer trampa. El instinto de un desarrollador con visión, en el momento en que el lector de pantalla dice algo confuso, es echar un vistazo a la pantalla y resolver la ambigüedad visualmente. Ese instinto es la razón principal por la que «he probado con un lector de pantalla» no detecta los fallos reales.

Se recomienda planificar tres sesiones de unos noventa minutos cada una en la primera semana, con al menos un día entre sesiones para que la memoria muscular tenga tiempo de consolidarse. Cada sesión tiene una tarea. La primera construye la gramática básica de comandos. La segunda fuerza una interacción real. La tercera prueba la retención bajo una pequeña dosis de estrés.

Las semanas segunda a cuarta de práctica deberían sumar unas veinte horas de trabajo — dos sesiones de noventa minutos a la semana, más un uso incidental mientras se realiza el trabajo habitual. El objetivo en este tramo es interiorizar las dos cosas que más confunden a los usuarios nuevos de lectores de pantalla: la distinción entre el modo de exploración y el modo de foco, y la diferencia entre lo que ve el rotor y lo que ve el orden de tabulación.

La confusión más frecuente en la segunda semana es el momento en que un desarrollador pulsa una tecla de flecha en NVDA, espera que se mueva el búfer virtual y en cambio escucha cómo el cuadro combinado con foco abre su lista de opciones. Eso es el paso del modo de exploración al modo de foco de forma automática porque el foco ha aterrizado en un elemento que NVDA clasifica como widget de «aplicación». Los desarrolladores nuevos lo interpretan como un mal funcionamiento del lector. No lo es — es el lector haciendo exactamente lo que pide la especificación. Una vez que se ha escuchado diez o quince veces, deja de sorprender; hasta entonces, hay que prever sorprenderse aproximadamente cada dos sesiones.

El patrón de la tercera semana son los formularios. Se recomienda construir una página de prueba privada con ocho o diez controles: un campo de texto obligatorio con un error en línea, un selector de fecha, una lista de selección múltiple, una casilla de verificación con estilos personalizados, un botón deshabilitado que se activa, un botón de alternancia «mostrar contraseña», un campo de número de teléfono con un selector de prefijo de país y un botón de envío que activa un resumen de validación del servidor. Monitor apagado, navegar por él cinco veces — primero con NVDA en modo de exploración, luego NVDA en modo de foco, luego NVDA de nuevo con el ajuste de anuncio detallado activado (Insert+Z, más información en la sección cinco), luego VoiceOver con el rotor, luego VoiceOver sin el rotor. El mismo formulario sonará diferente las cinco veces. Eso es lo que se siente la fluidez desde dentro: percibir que el mismo marcado cuenta cinco historias distintas, y ser capaz de predecir de antemano cuál se reproducirá.

La cuarta semana es la navegación. Tomar un sitio real y complejo — un portal de documentación, un panel de trabajo, una página de categoría de comercio electrónico — e intentar encontrar una información concreta usando solo atajos del lector de pantalla. Usar H para saltar a los encabezados. Usar D (NVDA) o VO+U y luego «Puntos de referencia» (VoiceOver) para saltar a los landmarks. Usar del 1 al 6 para saltar a un nivel de encabezado concreto. Al final de la cuarta semana, los atajos de navegación deberían ser reflejos en lugar de elecciones conscientes, igual que ya lo son el tabulador y el tabulador+mayúsculas.

Una vez que los comandos en modo usuario son reflejos, el siguiente salto es hacia las superficies orientadas al desarrollador de cada lector. Estos son los modos y atajos que los manuales entierran — en parte porque están dirigidos a desarrolladores, en parte porque son suficientemente ruidosos como para que un usuario habitual no los quiera activados. Tres merecen conocerse de inmediato.

Dos hábitos adicionales ahorrarán más tiempo que cualquier atajo individual. En primer lugar, mantener el visor de voz de NVDA anclado en un segundo monitor (o en un rincón del único monitor) mientras se desarrolla. El registro literal de cada anuncio es para el trabajo con lectores de pantalla lo que la consola de herramientas de desarrollo es para JavaScript: la diferencia entre adivinar y saber. En segundo lugar, aprender a leer el árbol de accesibilidad en las herramientas de desarrollo del navegador — el panel de accesibilidad de Chrome, el inspector de accesibilidad de Firefox, la pestaña de auditoría de Safari. El lector anuncia lo que contiene el árbol de accesibilidad, no lo que contiene el DOM, y los dos difieren con suficiente frecuencia como para que no sea posible depurar regiones activas, ARIA o Shadow DOM sin leer el árbol directamente.

Conviene señalar ahora una confusión que consume horas en las semanas dos y tres: el modo de lectura frente al modo de foco no es el mismo eje que «la página es interactiva» frente a «la página es un documento». NVDA cambia automáticamente al modo de foco cuando el foco aterriza en un control con role=“application”, en un contenteditable o en ciertos widgets personalizados que el lector clasifica heurísticamente como interactivos — independientemente de si la página es mayoritariamente estática. Por el contrario, una aplicación de página única muy interactiva cuyo elemento raíz es un landmark main y cuyos widgets son botones nativos bien marcados permanecerá en modo de exploración durante casi toda la sesión del usuario. El modo es una propiedad del elemento con foco, no de la página.

Las cifras siguientes provienen de un seguimiento informal de unos ochenta desarrolladores — ingenieros de frontend, responsables de QA, especialistas en accesibilidad en formación — a lo largo de tres años de talleres corporativos y tutorías individuales. No son un estudio de investigación. Son suficientemente fiables como para planificar. Dos supuestos: práctica deliberada (monitor apagado, tareas reales, no «dejé NVDA en segundo plano mientras programaba») y un emparejamiento de lector fijo (NVDA en Windows y VoiceOver en macOS).

«Semifluido» es el destino realista para la mayoría de los desarrolladores con visión y es, en términos prácticos, todo lo que se necesita para contribuir bien a un producto accesible. La fluidez genuina — el nivel en el que se podría sustituir razonablemente a un usuario habitual de lector de pantalla durante una revisión de usabilidad — se acerca a las ciento cincuenta horas y a un año de práctica incidental, y la mayoría de los desarrolladores en activo no la necesitan. El objetivo debe ser la semifluencia, planificar las cuarenta horas y aceptar que cualquier cosa más allá viene de hacer el trabajo habitual con un lector activo y disposición para frenar el ritmo.

Una última referencia para fijar expectativas de forma honesta: los desarrolladores que se estancan, en nuestra experiencia, lo hacen entre las diez y las veinte horas. La causa es casi siempre la misma — dejan de apagar el monitor. Se dicen a sí mismos que ahora son «suficientemente buenos» para probar con la pantalla encendida, el lector de pantalla activo en segundo plano y la confirmación visual disponible siempre que el audio sea ambiguo. No lo son. Las dieciséis horas entre «útil» y «cómodo» requieren el monitor apagado porque en ese tramo los anuncios del lector se convierten en información en lugar de ruido. Sin esa presión, el cerebro vuelve a apoyarse en la visión y la voz del lector se convierte en ruido de fondo. Si el progreso se ralentiza, casi siempre es el monitor.

La razón por la que «probar con un lector de pantalla» produce resultados tan débiles en el sector no es que la herramienta sea difícil de aprender — cuarenta horas no son realmente mucho tiempo — sino que el aprendizaje resulta incómodo de una forma concreta. Apagar el monitor hace que un desarrollador con visión se sienta torpe de un modo inusual en nuestra profesión. Estamos acostumbrados a ser quienes resuelven las cosas; el lector de pantalla nos convierte, durante unas horas seguidas, en principiantes de nuevo. Esa incomodidad, y no las combinaciones de teclas, es el obstáculo real.

El camino para superarlo es el descrito anteriormente: NVDA y VoiceOver, tres sesiones en la primera semana con el monitor apagado, formularios y modos en las semanas dos a cuatro, atajos en modo desarrollador en cuanto los atajos en modo usuario sean reflejos, cuarenta horas en total antes de poder considerarse de confianza para una revisión seria previa al lanzamiento. Nada de esto es novedoso. Lo que el sector no ha hecho es tratarlo como trabajo — planificar las horas, defenderlas frente a otras obligaciones, aceptar que las primeras diez de esas horas parecerán inútiles hasta que de repente dejen de serlo.

Si se desarrolla para el frontend, la versión de uno mismo al otro lado de esas cuarenta horas es un ingeniero sustancialmente mejor que la que empezó, de maneras que se manifestarán no solo en el trabajo de accesibilidad, sino también en la comprensión del orden de foco, de la mejora progresiva, de lo que el navegador realmente hace bajo el capó. El lector de pantalla es la lección de sistemas distribuidos más económica al alcance de cualquier persona que escriba para la web. El precio es el monitor apagado y unos cuantos fines de semana.