Revisar una web con un lector de pantalla puede resultar desconcertante la primera vez. Al activar VoiceOver o NVDA, el ordenador empieza a anunciar encabezados, enlaces, botones, imágenes, regiones y estados que normalmente interpretamos de manera visual.

Sin embargo, no es necesario dominar todos sus comandos para realizar una primera revisión útil. Con unas pocas acciones podemos detectar barreras importantes relacionadas con la estructura de la página, la navegación mediante teclado, los formularios, los componentes interactivos o los mensajes que aparecen dinámicamente.

El objetivo no consiste simplemente en comprobar si el lector de pantalla pronuncia el contenido. Una revisión adecuada debe ayudarnos a responder una pregunta mucho más importante: ¿puede una persona comprender la página, desplazarse por ella y completar sus tareas sin depender de la vista?

En esta guía veremos cómo revisar accesibilidad de forma básica utilizando VoiceOver en macOS y NVDA en Windows. También repasaremos qué elementos conviene comprobar, qué errores aparecen con mayor frecuencia y cómo documentarlos para facilitar su corrección.

Esta prueba no sustituye una auditoría completa ni la participación de personas que utilizan lectores de pantalla habitualmente. Aun así, incorporarla al proceso de desarrollo es un paso importante para crear productos digitales de mayor calidad. Para entender mejor este enfoque, también puedes consultar por qué la accesibilidad web es una parte esencial del desarrollo de una página.

Qué es un lector de pantalla y cómo interpreta una web

Un lector de pantalla es una aplicación que transforma la información digital en voz sintetizada o en una salida compatible con una línea braille.

Aunque solemos decir que estas herramientas “leen la pantalla”, su funcionamiento es algo más complejo. El lector no se limita a pronunciar el texto visible, sino que recibe información proporcionada por el sistema operativo, el navegador y el árbol de accesibilidad de la página.

Este árbol representa los elementos mediante propiedades como:

• El nombre accesible.
• El rol del elemento.
• Su estado actual.
• Su valor.
• Las acciones disponibles.
• La relación con otros controles.
• Su posición dentro de la estructura.

Por ejemplo, un botón representado visualmente mediante una lupa podría anunciarse como “Buscar, botón”. En ese mensaje encontramos dos datos fundamentales: el nombre del control y su función.

Si el botón no dispone de un nombre accesible, el lector podría anunciar simplemente “botón”. La persona sabría que puede activar algo, pero no qué acción se producirá al hacerlo.

Esta diferencia explica por qué una interfaz que parece evidente visualmente puede resultar confusa cuando se utiliza con tecnologías de asistencia.

Escuchar una web no es lo mismo que probarla

Una revisión no debería limitarse a activar el lector y dejar que pronuncie el contenido desde el principio hasta el final. También es necesario interactuar con la página.

Durante la prueba debemos intentar responder preguntas como estas:

• ¿Puedo identificar el propósito de la página?
• ¿Comprendo cómo está organizada?
• ¿Puedo localizar el contenido principal?
• ¿Los encabezados permiten saltar entre secciones?
• ¿Los enlaces explican adónde conducen?
• ¿Los botones comunican qué acción realizan?
• ¿Los formularios indican qué información necesitan?
• ¿Los mensajes de error se anuncian?
• ¿Puedo abrir y cerrar los componentes interactivos?
• ¿El foco se desplaza de manera lógica?
• ¿Recibo una confirmación después de completar una acción?

La accesibilidad no depende únicamente de que el contenido sea leído. También requiere que la experiencia sea comprensible, operable y predecible.

Cómo preparar una revisión con lector de pantalla

Antes de activar VoiceOver o NVDA, conviene definir qué tarea vamos a comprobar. Intentar revisar una aplicación completa durante una primera sesión puede resultar abrumador y producir observaciones poco concretas.

Podemos empezar con un recorrido sencillo, por ejemplo:

1. Acceder a la página principal.
2. Abrir el menú de navegación.
3. Entrar en una sección.
4. Localizar un artículo o producto.
5. Completar un formulario.
6. Provocar un error de validación.
7. Confirmar que la acción se ha realizado.

En una tienda en línea, el recorrido podría consistir en localizar un producto y añadirlo al carrito. En una web corporativa, podríamos revisar el formulario de contacto. En un blog, la tarea podría ser encontrar una categoría, abrir un artículo y navegar por sus apartados.

Realizar primero el recorrido visualmente ayuda a entender cuál debería ser el comportamiento esperado. Después podemos repetirlo utilizando el teclado y la información anunciada por el lector.

Utiliza un entorno de prueba concreto

Para que los resultados puedan reproducirse, es importante anotar:

• Sistema operativo.
• Navegador.
• Lector de pantalla.
• Versión de cada herramienta.
• URL revisada.
• Fecha de la prueba.

Los lectores de pantalla no se comportan exactamente igual en todos los navegadores. Por eso, indicar la combinación utilizada facilita que el equipo pueda comprobar el problema en las mismas condiciones.

Empieza utilizando también la pantalla

No es necesario cerrar los ojos para probar una web con lector de pantalla. De hecho, durante las primeras revisiones es recomendable observar qué elemento tiene el foco y relacionarlo con lo que anuncia la herramienta.

Cerrar los ojos no reproduce automáticamente la experiencia de una persona ciega que lleva años utilizando estas tecnologías. El objetivo de la prueba no es simular una discapacidad, sino comprender qué información ofrece la interfaz cuando no podemos depender exclusivamente de su presentación visual.

Cómo revisar una web con VoiceOver en macOS

VoiceOver está integrado en macOS, por lo que no es necesario instalar ninguna aplicación adicional.

Para activarlo podemos utilizar:

Comando + F5

Dependiendo de la configuración del teclado, puede ser necesario añadir la tecla Fn. La misma combinación permite desactivarlo.

VoiceOver utiliza unas teclas modificadoras conocidas como teclas VO. De manera predeterminada suelen ser:

Control + Opción

Los comandos básicos para iniciar la revisión son:

• VO + flecha derecha: avanzar al elemento siguiente.
• VO + flecha izquierda: volver al elemento anterior.
• VO + barra espaciadora: activar el elemento seleccionado.
• VO + U: abrir el rotor de VoiceOver.

Con estos comandos ya es posible realizar una primera exploración.

Primer recorrido con VoiceOver

Al cargar la página, conviene escuchar qué información anuncia inicialmente. Deberíamos poder identificar el título del documento y empezar a recorrer su contenido de forma coherente.

Durante el recorrido hay que prestar atención a cómo se anuncian:

• Encabezados.
• Regiones.
• Enlaces.
• Botones.
• Imágenes.
• Listas.
• Campos de formulario.
• Estados expandidos o contraídos.
• Mensajes de confirmación.

No es necesario memorizar todo lo que pronuncia VoiceOver. Lo importante es detectar cuándo la información resulta insuficiente, repetitiva, incorrecta o difícil de comprender.

Utilizar el rotor para revisar la estructura

El rotor de VoiceOver permite consultar diferentes categorías de elementos. Se abre mediante:

VO + U

Después podemos desplazarnos entre categorías, como encabezados, enlaces, controles de formulario o regiones.

Esta función es especialmente útil porque reproduce una forma habitual de navegar: en lugar de escuchar todo el documento, la persona puede consultar directamente la lista de encabezados o enlaces.

Si la lista de encabezados no permite comprender el contenido, probablemente la estructura de la página necesita una revisión.

Cómo revisar una web con NVDA en Windows

NVDA es un lector de pantalla gratuito y de código abierto para Windows. Se utiliza habitualmente con navegadores como Firefox o Chrome.

Después de instalarlo, puede iniciarse desde el acceso directo del escritorio o desde el menú de aplicaciones.

NVDA permite recorrer la página mediante las flechas, pero también incluye comandos rápidos para localizar tipos concretos de elementos:

• H: encabezado siguiente.
• Mayúsculas + H: encabezado anterior.
• 1 a 6: encabezado siguiente del nivel indicado.
• K: enlace siguiente.
• B: botón siguiente.
• F: campo de formulario siguiente.
• D: región siguiente.
• T: tabla siguiente.
• Tabulador: siguiente elemento interactivo.
• Mayúsculas + Tabulador: elemento interactivo anterior.
• Intro o barra espaciadora: activar el control, según el contexto.

Estos atajos permiten revisar rápidamente si la página dispone de una estructura semántica útil.

Qué información debería anunciar NVDA

Al llegar a un control, NVDA debería comunicar su nombre, su función y, cuando corresponda, su estado.

Un desplegable podría anunciar algo similar a:

“Categoría, cuadro combinado, contraído”.

Después de abrirlo, su estado debería cambiar a:

“Categoría, cuadro combinado, expandido”.

Si el lector no informa de esa modificación, una persona podría no saber si la acción se ha completado.

Este principio también se aplica a:

• Menús.
• Acordeones.
• Pestañas.
• Casillas de verificación.
• Botones de opción.
• Ventanas modales.
• Reproductores multimedia.
• Carruseles.
• Selectores de fecha.
• Notificaciones.

Qué comprobar durante una revisión básica

Una prueba ordenada ayuda a no pasar por alto los elementos más importantes. Podemos dividirla en diferentes áreas.

Revisar el título y las regiones principales

Cada página debería tener un título descriptivo en la pestaña del navegador. Este título permite identificar el contenido cuando existen varias pestañas abiertas y ayuda a confirmar que la navegación ha conducido al destino esperado.

Títulos como “Inicio”, “Nueva página” o “Documento sin título” aportan muy poco contexto.

También conviene comprobar que el lector reconoce las regiones principales de la página:

• Cabecera.
• Navegación.
• Buscador.
• Contenido principal.
• Información complementaria.
• Pie de página.

Estas regiones permiten saltar entre zonas importantes sin recorrer todos los elementos intermedios.

Comprobar la jerarquía de encabezados

Los encabezados permiten entender cómo se distribuye la información. Una persona usuaria de lector de pantalla puede recorrerlos para obtener una visión general antes de leer el contenido completo.

Durante la revisión debemos comprobar:

• Si existe un encabezado principal descriptivo.
• Si los títulos representan el contenido de cada sección.
• Si la jerarquía tiene sentido.
• Si existen encabezados vacíos.
• Si se utilizan encabezados solo para modificar el tamaño del texto.
• Si faltan títulos en contenidos extensos.

No todos los saltos de nivel generan necesariamente una barrera, pero la estructura global debería ser lógica. El problema aparece cuando los encabezados no reflejan la relación entre las distintas partes de la página.

Revisar el orden del foco con el teclado

Después de analizar la estructura, debemos recorrer los elementos interactivos mediante Tabulador.

El foco debería seguir una secuencia previsible y acompañar el orden lógico del contenido. Si salta de la cabecera al pie de página y después vuelve al contenido principal, la navegación resultará difícil de seguir.

Hay que detectar especialmente:

• Controles que no reciben el foco.
• Elementos ocultos que sí lo reciben.
• Saltos inesperados.
• Foco atrapado dentro de un componente.
• Pérdida del foco después de una acción.
• Orden diferente al contenido visual.
• Componentes que solo pueden utilizarse con ratón.

La navegación mediante lector de pantalla y la navegación por teclado están estrechamente relacionadas. Para profundizar en esta parte de la revisión, puedes consultar la guía sobre focus visible y accesibilidad mediante teclado.

Comprobar el enlace para saltar al contenido

Las páginas con una cabecera extensa deberían ofrecer un enlace para evitar los bloques repetidos de navegación.

Normalmente, este enlace aparece al pulsar Tabulador por primera vez y tiene un texto como “Saltar al contenido principal”.

Debemos comprobar que:

1. Recibe el foco al comenzar la navegación.
2. Su texto describe correctamente la función.
3. Es visible cuando tiene el foco.
4. Traslada el punto de navegación al contenido principal.
5. No se limita a desplazar visualmente la página.

Un enlace de salto correctamente implementado ahorra tener que recorrer el logotipo, el buscador y todos los elementos del menú en cada nueva página.

Analizar los enlaces fuera de contexto

Una prueba muy útil consiste en abrir la lista de enlaces y escuchar sus nombres sin el texto que los rodea.

Expresiones como “haz clic aquí”, “más información”, “ver” o “leer más” pueden resultar ambiguas cuando aparecen aisladas.

Un enlace debería permitir anticipar su destino. Por ejemplo, “Consultar las tarifas de mantenimiento” es más informativo que “Ver más”.

También hay que comprobar si varios enlaces con el mismo texto conducen a destinos diferentes. Esta situación obliga a interpretar el contexto de cada uno y puede dificultar la navegación.

En el artículo sobre cómo escribir links accesibles y por qué conviene evitar “haz clic aquí” encontrarás más ejemplos aplicados a contenidos e interfaces.

Diferenciar correctamente enlaces y botones

La apariencia visual no determina la semántica de un control.

Un enlace se utiliza para navegar a otra página, recurso o ubicación. Un botón ejecuta una acción dentro de la interfaz, como guardar, enviar, eliminar, abrir o cerrar.

Durante la prueba debemos escuchar cómo se anuncia cada elemento y comprobar que coincide con su comportamiento.

Un control visual con apariencia de botón que se anuncia como enlace puede generar expectativas incorrectas. Del mismo modo, un elemento construido con un div podría no anunciarse como interactivo ni responder adecuadamente al teclado.

Revisar las imágenes y sus alternativas textuales

Las imágenes informativas necesitan una alternativa que comunique su finalidad. Sin embargo, las imágenes decorativas deberían ignorarse para evitar ruido innecesario.

Durante la revisión conviene preguntarse:

• ¿La imagen transmite información?
• ¿Su contenido ya aparece explicado cerca?
• ¿Funciona como enlace?
• ¿Es puramente decorativa?
• ¿Contiene texto importante?
• ¿La descripción aporta información útil?

Si el lector pronuncia nombres como “cabecera-final-dos-jota-pe-ge”, probablemente está accediendo al nombre del archivo porque no existe una alternativa adecuada.

La descripción no debe reproducir todos los detalles visuales. Debe comunicar lo necesario para comprender el papel de la imagen dentro de la página.

Revisar botones formados únicamente por iconos

Los iconos de búsqueda, cierre, favoritos, descarga o menú necesitan un nombre accesible cuando actúan como controles.

Un botón representado mediante una “X” debería anunciarse como “Cerrar”, no como “equis”, “imagen” o simplemente “botón”.

El icono visual puede ocultarse a las tecnologías de asistencia mientras el botón conserva un nombre comprensible. Este patrón se explica con más detalle en la guía sobre iconos accesibles, aria-hidden y nombres accesibles.

Probar los formularios

Los formularios son una de las áreas donde aparecen más barreras. Para revisarlos, podemos avanzar directamente entre los campos sin leer previamente las instrucciones de la página.

Cada control debería anunciarse de forma comprensible, por ejemplo:

• “Nombre, edición”.
• “Correo electrónico, obligatorio, edición”.
• “Acepto la política de privacidad, casilla no marcada”.
• “Provincia, cuadro combinado”.

Hay que comprobar:

• Que todos los campos tengan una etiqueta.
• Que los campos obligatorios se identifiquen.
• Que las instrucciones estén relacionadas con el control correspondiente.
• Que las casillas y botones de opción tengan nombres claros.
• Que los grupos de opciones dispongan de una pregunta o leyenda.
• Que los textos de ayuda sean accesibles.
• Que el orden de navegación sea lógico.

El texto de ejemplo situado dentro de un campo no sustituye una etiqueta. El placeholder desaparece cuando empezamos a escribir y puede no proporcionar contexto suficiente.

Provocar errores de validación

No debemos comprobar únicamente el caso correcto. También es necesario enviar el formulario vacío o introducir datos incorrectos.

Cuando se produce un error, hay que verificar:

1. Si se anuncia que el formulario no se ha podido enviar.
2. Si se identifican los campos afectados.
3. Si el mensaje explica qué ha ocurrido.
4. Si indica cómo corregirlo.
5. Si el foco se mantiene en una posición comprensible.
6. Si los datos válidos introducidos previamente se conservan.
7. Si la identificación del error no depende solo del color.

Un mensaje como “El formulario contiene errores” resulta poco útil si no sabemos dónde están. Es preferible proporcionar instrucciones concretas, como “Introduce una dirección de correo electrónico válida”.

Probar menús, desplegables y componentes personalizados

Los componentes personalizados suelen concentrar muchos problemas de accesibilidad. Visualmente pueden parecer un control conocido, pero su comportamiento semántico o de teclado puede ser completamente diferente.

Hay que comprobar:

• Si el componente recibe el foco.
• Si se anuncia su nombre.
• Si se comunica su función.
• Si informa de su estado.
• Si puede abrirse mediante teclado.
• Si puede cerrarse con Escape, cuando corresponde.
• Si las flechas permiten recorrer las opciones.
• Si el foco se mantiene dentro del flujo esperado.

Siempre que una selección sencilla pueda resolverse con un elemento HTML nativo, suele ser preferible evitar un componente personalizado innecesariamente complejo. La comparación entre dropdown, select y combobox desde el punto de vista de la accesibilidad ayuda a entender cuándo utilizar cada opción.

Revisar ventanas modales

Cuando se abre una ventana modal, el lector debería anunciar su aparición y el foco debería trasladarse a su interior.

Mientras la ventana permanezca abierta:

• El foco no debería pasar al contenido situado detrás.
• El título del diálogo debería anunciarse.
• El botón de cierre debería tener un nombre comprensible.
• La tecla Escape debería cerrarla cuando ese comportamiento sea apropiado.
• Al cerrarla, el foco debería volver al elemento que la abrió.

Si el foco desaparece o vuelve al principio de la página, la persona tendrá que reconstruir su contexto de navegación.

Comprobar los mensajes y cambios dinámicos

Muchas aplicaciones actualizan contenido sin recargar la página. Esto ocurre al añadir un producto al carrito, guardar una configuración, aplicar un filtro o enviar un formulario.

La modificación visual no garantiza que el lector de pantalla reciba la información.

Debemos comprobar si se anuncian mensajes como:

• “Producto añadido al carrito”.
• “Configuración guardada”.
• “Se han encontrado doce resultados”.
• “El archivo se está subiendo”.
• “No se ha podido completar la operación”.

Los indicadores de carga también deben comunicar qué está ocurriendo sin depender únicamente de una animación. En la guía para crear loaders animados accesibles con CSS se muestran ejemplos de mensajes de estado y elementos decorativos ocultos correctamente al lector.

Errores frecuentes que podemos detectar rápidamente

Una prueba de pocos minutos puede descubrir problemas de gran impacto, como:

• Botones sin nombre accesible.
• Enlaces ambiguos o repetidos.
• Imágenes que anuncian el nombre del archivo.
• Formularios sin etiquetas.
• Campos obligatorios no identificados.
• Menús que no comunican si están abiertos o cerrados.
• Encabezados vacíos o desordenados.
• Elementos que solo funcionan con ratón.
• Controles ocultos que reciben el foco.
• Modales de los que no se puede salir.
• Foco que desaparece después de una acción.
• Mensajes de error que no se anuncian.
• Cambios de estado comunicados únicamente mediante color.
• Contenido dinámico que pasa inadvertido.
• Textos e iconos anunciados de forma duplicada.
• Carruseles automáticos que interrumpen la lectura.

Detectar un error no significa que debamos conocer inmediatamente su solución técnica. Durante la evaluación es preferible describir primero el comportamiento observado.

Por ejemplo:

“Después de activar el botón Añadir al carrito, NVDA no anuncia ninguna confirmación.”

Esta observación es más útil que indicar directamente que falta un atributo concreto sin haber analizado la implementación.

Cómo documentar los problemas encontrados

Un informe de accesibilidad debe permitir que otra persona reproduzca el problema.

Cada incidencia debería incluir:

1. Página o URL afectada.
2. Sistema operativo.
3. Navegador.
4. Lector de pantalla y versión.
5. Pasos para reproducir el error.
6. Resultado obtenido.
7. Resultado esperado.
8. Impacto para la persona usuaria.
9. Captura, vídeo o grabación, cuando resulte útil.

Ejemplo de incidencia

Problema: el botón del buscador no tiene un nombre accesible.

Pasos para reproducirlo:

1. Abrir la página principal.
2. Activar NVDA.
3. Pulsar Tabulador hasta llegar al icono de búsqueda.

Resultado obtenido: NVDA anuncia “botón”.

Resultado esperado: NVDA debería anunciar “Buscar, botón”.

Impacto: una persona que no puede ver el icono no dispone de información suficiente para identificar la función del control.

Este formato evita descripciones genéricas como “el buscador no es accesible” y proporciona al equipo información práctica para comprobar y corregir la barrera.

No intentar resolver todos los problemas con ARIA

ARIA permite añadir roles, propiedades y estados a determinados componentes. Sin embargo, utilizarlo incorrectamente puede empeorar la experiencia.

Siempre que sea posible, debemos partir de elementos HTML nativos:

• <button> para ejecutar acciones.
• <a> para navegar.
• <input> para introducir datos.
• <select> para seleccionar una opción.
• Encabezados reales para estructurar el contenido.
• <main> para identificar el contenido principal.
• <nav> para las zonas de navegación.

Estos elementos ya incorporan semántica y comportamientos que los navegadores pueden comunicar a las tecnologías de asistencia.

Convertir un div en botón obliga a reproducir manualmente el foco, la activación mediante teclado, el rol y los diferentes estados. Por eso, antes de preguntarnos qué atributo ARIA falta, conviene analizar si el problema puede resolverse con HTML semántico.

Lista de comprobación rápida

Para realizar una revisión inicial podemos seguir esta secuencia:

1. Activar VoiceOver o NVDA.
2. Confirmar que el título de la página es descriptivo.
3. Recorrer las regiones principales.
4. Navegar por los encabezados.
5. Consultar la lista de enlaces.
6. Revisar botones e iconos interactivos.
7. Recorrer todos los controles con Tabulador.
8. Comprobar el orden y la visibilidad del foco.
9. Revisar las imágenes y sus alternativas.
10. Completar el formulario principal.
11. Provocar errores de validación.
12. Abrir y cerrar menús, desplegables y modales.
13. Confirmar que los cambios dinámicos se anuncian.
14. Comprobar que no existen bloqueos de teclado.
15. Documentar los problemas con pasos reproducibles.

Esta lista no cubre todos los requisitos de accesibilidad, pero permite detectar muchas barreras importantes antes de publicar una página o una nueva funcionalidad.

Preguntas frecuentes sobre lectores de pantalla

¿Es suficiente probar una web únicamente con VoiceOver o NVDA?

No. Cada combinación de sistema operativo, navegador y lector de pantalla puede producir resultados diferentes.

VoiceOver es especialmente relevante en dispositivos de Apple, mientras que NVDA es una referencia habitual en Windows. Para una primera revisión podemos elegir una combinación principal, pero los recorridos críticos deberían probarse en más de un entorno.

Además, las pruebas con lector de pantalla deben complementarse con navegación por teclado, herramientas automáticas, revisión manual del código y, siempre que sea posible, pruebas con personas usuarias.

¿Necesito cerrar los ojos para revisar la web?

No. Cerrar los ojos no convierte la prueba en una simulación realista de la experiencia de una persona ciega.

Durante las primeras revisiones es recomendable observar la pantalla para identificar qué elemento recibe el foco y relacionarlo con la información anunciada. A medida que adquiramos experiencia, podemos intentar completar determinados recorridos basándonos únicamente en el audio.

Lo importante es evaluar si la interfaz proporciona la información necesaria, no intentar imitar una experiencia que requiere aprendizaje y práctica continuada.

¿Las herramientas automáticas detectan los mismos problemas?

No. Las herramientas automáticas pueden detectar determinados errores, como imágenes sin alternativa, campos sin etiquetas identificables o algunos problemas de contraste.

Sin embargo, no pueden valorar de manera fiable si:

• Una descripción de imagen es útil.
• El orden de lectura resulta comprensible.
• Un enlace tiene sentido en su contexto.
• El mensaje de error explica cómo resolver el problema.
• El foco se desplaza al lugar adecuado.
• Una actualización dinámica se anuncia en el momento correcto.

La automatización es un apoyo valioso, pero no sustituye la revisión manual.

Escuchar la interfaz cambia nuestra forma de diseñarla

Utilizar un lector de pantalla transforma nuestra percepción de una web. Elementos que visualmente parecían evidentes pueden convertirse en botones anónimos, instrucciones incompletas o recorridos difíciles de seguir.

Esta experiencia también demuestra que la accesibilidad no es una capa que pueda añadirse al final del proyecto. Depende de decisiones tomadas durante el diseño, la redacción, el desarrollo y el testing: utilizar HTML semántico, escribir enlaces descriptivos, mantener un orden lógico, etiquetar correctamente los formularios y comunicar los cambios de estado.

Una revisión básica con VoiceOver o NVDA no convierte automáticamente una web en accesible. Tampoco sustituye la experiencia de las personas que utilizan estas herramientas cada día. Sin embargo, ayuda a detectar barreras que podrían llegar a producción y nos permite tomar decisiones más conscientes.

La pregunta final no debería ser solamente “¿el lector de pantalla anuncia este elemento?”, sino: “¿una persona puede comprenderlo, utilizarlo y completar su objetivo con autonomía?”

Cuando incorporamos esta pregunta al proceso de desarrollo, dejamos de tratar la accesibilidad como una lista de requisitos aislados y empezamos a entenderla como una parte esencial de la calidad de cualquier producto digital.