Una aplicación puede funcionar correctamente, cargar rápido y presentar una interfaz atractiva y, aun así, resultar imposible de utilizar para parte de sus usuarios.

Puede ocurrir, por ejemplo, que una persona no consiga completar un formulario utilizando el teclado, que un lector de pantalla no anuncie correctamente un botón o que un mensaje de error dependa exclusivamente del color para comunicar qué ha sucedido.

El testing de accesibilidad permite identificar este tipo de barreras antes de que afecten a las personas que utilizan el producto. Su propósito no consiste únicamente en superar una auditoría o cumplir una lista de requisitos técnicos, sino en comprobar que la aplicación puede percibirse, entenderse y manejarse mediante distintas formas de interacción.

También conocido como accessibility testing o a11y testing, este proceso combina revisiones automáticas, pruebas manuales, navegación con tecnologías de asistencia y evaluación de los flujos más importantes de la aplicación.

En este artículo veremos cómo organizar una revisión de accesibilidad, qué aspectos conviene comprobar y de qué manera puede integrarse en el desarrollo habitual sin convertirla en una tarea aislada al final del proyecto.

Qué es el testing de accesibilidad

El testing de accesibilidad es el proceso mediante el cual se evalúa si una web o aplicación puede ser utilizada por personas con diferentes capacidades, dispositivos y necesidades de acceso.

Esto incluye a personas con discapacidades visuales, auditivas, físicas, cognitivas, neurológicas o relacionadas con el habla. Sin embargo, muchas de las mejoras que se introducen gracias a la accesibilidad también benefician a quienes utilizan un dispositivo en condiciones poco favorables, tienen una lesión temporal, navegan con una conexión limitada o necesitan aumentar el tamaño del texto.

Durante una revisión de accesibilidad no basta con comprobar que los elementos aparecen en pantalla. También es necesario analizar si las personas pueden completar las acciones principales.

Algunas preguntas útiles son:

• ¿Puede recorrerse toda la interfaz utilizando únicamente el teclado?
• ¿Los botones tienen nombres comprensibles?
• ¿El foco se muestra de manera visible?
• ¿Los campos de formulario tienen etiquetas correctamente asociadas?
• ¿Los mensajes de error explican cómo solucionar el problema?
• ¿La aplicación sigue siendo usable al ampliar el contenido?
• ¿Las actualizaciones dinámicas son detectadas por un lector de pantalla?
• ¿La información continúa siendo comprensible sin distinguir determinados colores?

Estas comprobaciones muestran que la accesibilidad no depende de un único atributo HTML ni de una herramienta concreta. Es una cualidad transversal que afecta al diseño, al contenido, al desarrollo y al comportamiento de la interfaz.

Por qué se utiliza el término a11y

La abreviatura a11y procede de la palabra inglesa accessibility. La primera y la última letra se mantienen, mientras que las once letras intermedias se sustituyen por el número 11.

Por este motivo, en documentación técnica y repositorios es habitual encontrar expresiones como:

• A11y testing.
• A11y audit.
• A11y checklist.
• A11y automation.
• A11y guidelines.

El término es útil para etiquetar tareas o configuraciones técnicas, pero no debería reducir la accesibilidad a una responsabilidad exclusiva del equipo de desarrollo.

Una etiqueta poco clara, una jerarquía visual confusa o un mensaje de error ambiguo también pueden generar barreras. Por eso es importante que diseño, desarrollo, contenido y QA compartan criterios desde el inicio.

Qué estándares sirven como referencia

El marco de referencia más utilizado para evaluar la accesibilidad web son las Web Content Accessibility Guidelines, conocidas como WCAG.

Estas directrices se organizan alrededor de cuatro principios fundamentales:

1. Perceptible: la información debe poder presentarse de formas que las personas puedan percibir.
2. Operable: la navegación y los controles deben poder manejarse con diferentes métodos de interacción.
3. Comprensible: el contenido y el funcionamiento de la interfaz deben resultar claros y predecibles.
4. Robusto: la aplicación debe ser compatible con navegadores, dispositivos y tecnologías de asistencia.

Los criterios de conformidad se dividen en los niveles A, AA y AAA. En numerosos proyectos se utiliza el nivel AA como objetivo principal, aunque el alcance debe adaptarse a las características del producto y a sus requisitos concretos.

Las WCAG proporcionan una base técnica muy valiosa, pero no sustituyen la evaluación de la experiencia real. Una aplicación puede cumplir determinados criterios y seguir presentando recorridos difíciles de comprender o interacciones innecesariamente complejas.

Accesibilidad web y aplicaciones móviles

Muchos principios de accesibilidad web también pueden trasladarse a aplicaciones móviles, aunque su implementación dependerá del sistema operativo y de los componentes nativos utilizados.

En una aplicación móvil conviene comprobar, entre otros aspectos:

• Compatibilidad con VoiceOver y TalkBack.
• Orden de exploración de los elementos.
• Etiquetas accesibles de botones e iconos.
• Tamaño de las áreas táctiles.
• Compatibilidad con tamaños de fuente mayores.
• Orientación de la pantalla.
• Alternativas a gestos complejos.
• Funcionamiento con teclado externo.
• Contraste y legibilidad.

Las diferencias entre ambos entornos son importantes. En el artículo sobre testing en aplicaciones móviles y sus diferencias frente al testing web se explican con más detalle las particularidades de dispositivos, sistemas operativos, permisos, gestos y tamaños de pantalla.

Por qué una herramienta automática no es suficiente

Las herramientas automáticas son útiles para detectar errores repetitivos y problemas que pueden reconocerse mediante reglas técnicas.

Por ejemplo, pueden localizar:

• Imágenes sin atributo alternativo.
• Campos sin etiquetas asociadas.
• Botones sin un nombre accesible.
• Identificadores duplicados.
• Determinadas combinaciones de color con contraste insuficiente.
• Atributos ARIA incorrectos.
• Elementos interactivos anidados de manera inadecuada.
• Algunos errores en la jerarquía del documento.

Sin embargo, una herramienta automática no siempre puede decidir si una descripción alternativa es apropiada, si el orden del foco resulta lógico o si un mensaje de error ayuda realmente a resolver el problema.

Tampoco puede experimentar un proceso de compra completo como lo haría una persona que navega con lector de pantalla.

Por eso, el resultado de Lighthouse, axe o WAVE debe interpretarse como una parte de la revisión, no como una certificación de accesibilidad. En la comparativa de herramientas para revisar la accesibilidad web con Lighthouse, axe y WAVE puedes consultar qué detecta cada solución y en qué momento del proceso conviene utilizarla.

Qué puede escapar a un análisis automático

Una aplicación podría no presentar errores automáticos graves y, aun así, contener problemas como los siguientes:

• Un botón anunciado como “Más información” sin contexto suficiente.
• Un menú cuyo orden de foco no coincide con el orden visual.
• Un modal que se abre, pero no recibe el foco.
• Un formulario que indica los errores únicamente mediante un borde rojo.
• Una tabla difícil de interpretar con lector de pantalla.
• Un aviso dinámico que aparece visualmente, pero no se anuncia.
• Un texto alternativo presente, aunque irrelevante o demasiado extenso.
• Un proceso que obliga a realizar demasiadas acciones para completar una tarea.

Estas situaciones requieren pruebas manuales y una interpretación humana del contexto.

Cómo hacer testing de accesibilidad paso a paso

No es necesario comenzar con una auditoría completa de toda la aplicación. Una revisión organizada de las pantallas y flujos principales puede revelar numerosos problemas desde las primeras fases.

1. Define el alcance de las pruebas

Antes de abrir una herramienta, identifica qué tareas son esenciales para el funcionamiento del producto.

En una tienda online, por ejemplo, deberían priorizarse:

• La búsqueda de productos.
• La aplicación de filtros.
• La consulta de una ficha.
• La incorporación al carrito.
• El inicio de sesión.
• El proceso de compra.
• La introducción de datos personales.
• La selección del método de pago.
• La confirmación del pedido.

En otro tipo de aplicación, los flujos prioritarios podrían ser el registro, la edición de un perfil, la creación de contenido, la reserva de una cita o el envío de un formulario.

Probar solamente la página de inicio proporciona una imagen incompleta. Los problemas más importantes suelen aparecer en componentes dinámicos, formularios, menús, validaciones y cambios de estado.

Incluye estados alternativos

Cada flujo debe revisarse tanto en condiciones ideales como en situaciones de error.

Incluye, al menos:

• Formularios vacíos.
• Datos con formato incorrecto.
• Resultados sin contenido.
• Errores de servidor.
• Estados de carga.
• Sesiones caducadas.
• Botones deshabilitados.
• Confirmaciones.
• Avisos temporales.
• Contenido actualizado dinámicamente.

Una interfaz puede ser accesible en su estado inicial y dejar de serlo después de una interacción.

2. Revisa la estructura semántica

El HTML semántico permite que navegadores y tecnologías de asistencia comprendan la función de cada elemento.

Siempre que sea posible, utiliza elementos nativos como:

• <button> para acciones.
• <a> para enlaces.
• <label> para identificar campos.
• <nav> para zonas de navegación.
• <main> para el contenido principal.
• <header> y <footer> para regiones estructurales.
• <ul> y <ol> para listas.
• <table> para datos tabulares.

Un <div> con un evento de clic puede parecer visualmente un botón, pero no incorpora automáticamente su comportamiento de teclado, su semántica ni su exposición al árbol de accesibilidad.

Comprueba la jerarquía de encabezados

Los encabezados permiten comprender la organización de una página y facilitan la navegación mediante lectores de pantalla.

La estructura debería reflejar la relación entre los contenidos:

• Un h1 para el título principal.
• Encabezados h2 para las secciones.
• Encabezados h3 para las subsecciones.
• Encabezados h4 para divisiones internas cuando sean necesarias.

No deben elegirse por su tamaño visual. La apariencia puede modificarse mediante CSS, mientras que el nivel del encabezado debe expresar su posición dentro de la estructura.

3. Navega utilizando únicamente el teclado

La prueba de teclado es una de las revisiones manuales más sencillas y productivas.

Recorre la aplicación utilizando:

• Tab para avanzar.
• Shift + Tab para retroceder.
• Enter para activar enlaces y determinadas acciones.
• La barra espaciadora para botones, casillas u otros controles.
• Las flechas para componentes como pestañas, menús o grupos de opciones.
• Escape para cerrar elementos superpuestos cuando corresponda.

Durante el recorrido, comprueba que todos los controles reciben el foco y pueden activarse sin utilizar el ratón.

Qué debes observar durante la prueba

Presta atención a los siguientes aspectos:

• El orden del foco coincide con la secuencia lógica de lectura.
• No se omite ningún elemento interactivo.
• El foco no se desplaza hacia componentes invisibles.
• El indicador visual se distingue con claridad.
• No existen zonas en las que el teclado quede atrapado.
• Los menús pueden abrirse y cerrarse.
• Los controles personalizados responden a las teclas esperadas.
• Es posible completar la acción principal de la pantalla.

Esta prueba también ayuda a identificar problemas relacionados con el diseño responsive. Al reducir el espacio disponible, algunos controles pueden cambiar de posición, desaparecer o alterar su orden. La guía sobre testing responsive en distintos tamaños de pantalla amplía las comprobaciones necesarias en estos escenarios.

Revisión del foco en un modal

Cuando se abre un modal, el foco debería desplazarse a un elemento lógico de su interior, como el encabezado o el primer control disponible.

Mientras el diálogo permanece abierto, la navegación no debería continuar por el contenido situado detrás. Al cerrarlo, el foco debería regresar al botón o enlace que lo abrió.

Si no se gestiona correctamente, una persona puede perder su posición dentro de la interfaz o continuar navegando por elementos que visualmente no están disponibles.

4. Comprueba que el foco sea visible

Un control puede recibir el foco técnicamente sin mostrarlo de manera perceptible.

Esto sucede con frecuencia cuando se elimina el contorno predeterminado del navegador mediante CSS sin proporcionar una alternativa.

El indicador debe:

• Distinguirse del fondo.
• Rodear o identificar claramente el elemento activo.
• Mantenerse visible en distintos estados.
• Aparecer en enlaces, botones, campos y controles personalizados.

No es necesario conservar exactamente el estilo predeterminado del navegador, pero cualquier sustitución debe resultar igual o más visible.

5. Prueba la aplicación con un lector de pantalla

Una revisión inicial con lector de pantalla permite descubrir problemas que no son evidentes mediante una inspección visual.

Algunas opciones habituales son:

• VoiceOver en macOS e iOS.
• NVDA en Windows.
• Narrador en Windows.
• TalkBack en Android.

No es necesario dominar todas las funciones desde la primera prueba. Puede comenzarse recorriendo una pantalla sencilla y escuchando cómo se anuncian sus elementos.

En la guía sobre cómo revisar una web con lector de pantalla de forma básica encontrarás un proceso más detallado para comenzar con VoiceOver y NVDA.

Qué escuchar durante la navegación

Comprueba si el lector de pantalla comunica correctamente:

• El título de la página.
• Los encabezados.
• Los enlaces.
• Los botones.
• Las etiquetas de los campos.
• Los estados seleccionados.
• Los controles expandidos o contraídos.
• Los errores.
• Los avisos dinámicos.
• Las imágenes informativas.

Un botón con un icono de lupa, por ejemplo, debería anunciarse como “Buscar” y no simplemente como “botón” o con el nombre del archivo del icono.

Navega por diferentes categorías

No limites la prueba a recorrer la página de manera lineal. Los lectores de pantalla permiten desplazarse por encabezados, enlaces, regiones, campos y otros tipos de elemento.

Esta navegación ayuda a comprobar si la estructura programática coincide con la organización visual.

Un texto que parece un título podría no estar marcado como encabezado. Del mismo modo, un grupo que visualmente parece una lista podría haberse construido con elementos sin relación semántica.

6. Evalúa nombres, roles, estados y valores

Cada componente interactivo debe comunicar qué es, cómo se llama y en qué estado se encuentra.

Por ejemplo:

• Un botón debe tener un nombre identificable.
• Una casilla debe comunicar si está marcada.
• Un acordeón debe informar de si está expandido.
• Una pestaña debe indicar si está seleccionada.
• Un campo obligatorio debe expresar esa condición.
• Un control deshabilitado debe anunciarse como no disponible.

Los elementos HTML nativos ya proporcionan buena parte de esta información. Los componentes personalizados requieren más trabajo, ya que deben reproducir tanto la semántica como el comportamiento de teclado esperado.

Utiliza ARIA únicamente cuando sea necesario

ARIA permite añadir información al árbol de accesibilidad, pero no sustituye al HTML semántico.

Añadir role="button" a un <div> no le proporciona automáticamente comportamiento de teclado, foco ni activación mediante la barra espaciadora. Todo ello tendría que implementarse y mantenerse manualmente.

Por eso, la primera opción debería ser siempre utilizar el elemento nativo adecuado.

7. Revisa los formularios

Los formularios concentran una parte importante de los problemas de accesibilidad.

Para cada campo, comprueba que:

• Existe una etiqueta visible.
• La etiqueta está asociada programáticamente.
• Las instrucciones aparecen antes de que sean necesarias.
• Los campos obligatorios se identifican de forma accesible.
• El texto de ayuda está relacionado con el control.
• Los errores no dependen únicamente del color.
• Los datos introducidos no desaparecen sin necesidad.
• El mensaje explica cómo resolver el problema.

Un placeholder no debería sustituir a la etiqueta. Desaparece al escribir, puede presentar un contraste insuficiente y obliga a recordar qué información se solicitaba.

Redacta mensajes de error comprensibles

Mensajes como “Error”, “Valor no válido” o “Campo incorrecto” ofrecen poca ayuda.

Es preferible utilizar textos concretos:

Introduce una dirección de correo con el formato nombre@dominio.com.

La contraseña debe incluir al menos ocho caracteres y un número.

Selecciona una fecha posterior al día de hoy.

La redacción también forma parte de la accesibilidad. El artículo sobre microcopy accesible para botones, mensajes de ayuda y textos de error explica cómo escribir instrucciones más claras y reducir la carga cognitiva durante la interacción.

Gestiona correctamente el foco después de un error

Cuando un formulario contiene varios errores, puede mostrarse un resumen al inicio y mover el foco hacia él después del envío.

Cada mensaje del resumen debería enlazar con el campo correspondiente. De esta forma, la persona puede comprender qué ha ocurrido y desplazarse directamente hasta el control que necesita corregir.

8. Comprueba el contraste y el uso del color

El color no debe ser el único recurso empleado para comunicar información.

Un campo incorrecto marcado únicamente con un borde rojo puede pasar desapercibido para una persona que no distingue esa diferencia cromática. Es preferible acompañarlo de un mensaje y, cuando sea útil, de un icono.

También deben revisarse:

• Texto sobre fondos sólidos.
• Texto situado sobre imágenes.
• Enlaces dentro de párrafos.
• Iconos informativos.
• Bordes de campos.
• Estados de botones.
• Indicadores de foco.
• Gráficos y visualizaciones.
• Mensajes de éxito y error.

No basta con validar los colores del sistema de diseño de forma aislada. La combinación final puede verse afectada por transparencias, degradados, imágenes o estados interactivos.

9. Amplía el contenido

Prueba la aplicación modificando el zoom del navegador y aumentando el tamaño del texto configurado por el sistema.

Observa si:

• Los textos se cortan.
• Los elementos se superponen.
• Los botones pierden sus etiquetas.
• Aparece desplazamiento horizontal innecesario.
• Los modales quedan fuera de la pantalla.
• Las acciones principales desaparecen.
• Los campos dejan de ser legibles.
• El orden visual pierde coherencia.

Una aplicación adaptable debe soportar algo más que diferentes anchos de dispositivo. También tiene que responder correctamente a las preferencias de lectura de cada persona.

10. Revisa imágenes, iconos y contenido multimedia

Las imágenes informativas necesitan una alternativa textual que explique su función dentro del contexto.

Una imagen decorativa, en cambio, debería poder ignorarse para evitar ruido innecesario durante la navegación.

El texto alternativo no debe describir cada detalle de manera automática. Su contenido dependerá de la información que la imagen aporta en esa página.

En el caso de vídeos y audios, comprueba la disponibilidad de:

• Subtítulos.
• Transcripciones.
• Controles utilizables con teclado.
• Nombres accesibles para los botones.
• Alternativas para información exclusivamente visual.
• Posibilidad de pausar movimientos o animaciones.

Los iconos incluidos dentro de un botón también deben revisarse. Si el botón ya tiene un nombre accesible, el icono puede considerarse decorativo para impedir que se anuncie dos veces.

Cómo automatizar las pruebas de accesibilidad

La automatización permite detectar determinadas regresiones antes de publicar una nueva versión.

Herramientas como axe pueden integrarse con entornos de pruebas end-to-end y ejecutarse dentro del sistema de integración continua.

Un ejemplo con Playwright podría ser:

import { test, expect } from '@playwright/test';
import AxeBuilder from '@axe-core/playwright';

test('la página no presenta incidencias automáticas', async ({ page }) => {
  await page.goto('/');

  const results = await new AxeBuilder({ page })
    .withTags(['wcag2a', 'wcag2aa', 'wcag21aa', 'wcag22aa'])
    .analyze();

  expect(results.violations).toEqual([]);
});

Esta prueba puede ejecutarse con cada cambio relevante para detectar problemas como controles sin nombre, relaciones incorrectas o determinadas incidencias de contraste.

Analiza la interfaz en diferentes estados

No ejecutes el análisis únicamente después de cargar la página.

También deberían comprobarse:

• El modal abierto.
• El menú desplegado.
• El formulario con errores.
• La tabla cargada con datos.
• Una notificación visible.
• El segundo paso de un proceso.
• La pantalla de confirmación.

La estructura accesible puede cambiar después de cada interacción.

Combina automatización y revisión manual

El debate entre pruebas manuales y automáticas no debería plantearse como una elección excluyente.

La automatización ofrece rapidez, repetibilidad y capacidad para detectar regresiones. La revisión manual permite interpretar el contexto, evaluar la navegación y comprobar la experiencia con tecnologías de asistencia.

En la comparativa entre QA manual y testing automatizado puedes consultar cuándo conviene aplicar cada enfoque y cómo combinarlos dentro de una estrategia de calidad.

Cómo integrar la accesibilidad en el desarrollo

La accesibilidad resulta más efectiva cuando se trabaja desde el inicio y no como una revisión independiente antes del lanzamiento.

Durante el diseño

El equipo debería definir:

• Contrastes.
• Estados de foco.
• Estados de error.
• Jerarquía de contenido.
• Comportamiento con texto ampliado.
• Áreas táctiles.
• Alternativas a gestos.
• Funcionamiento de modales.
• Mensajes de ayuda.

Estas decisiones pueden documentarse dentro del sistema de diseño para que no dependan de interpretaciones individuales.

Durante el desarrollo

Pueden incorporarse:

• Componentes semánticos reutilizables.
• Linters.
• Pruebas unitarias.
• Pruebas end-to-end.
• Análisis con axe.
• Historias de Storybook.
• Revisiones de teclado.
• Inspecciones del árbol de accesibilidad.

Corregir un componente compartido suele tener un impacto mayor que solucionar el mismo problema por separado en cada pantalla.

Durante la revisión de código

La revisión debería incluir preguntas como:

• ¿Se está utilizando el elemento HTML adecuado?
• ¿El componente tiene un nombre accesible?
• ¿Puede manejarse con teclado?
• ¿El estado se comunica correctamente?
• ¿El foco se gestiona al abrir y cerrar el componente?
• ¿Los errores son comprensibles?
• ¿La actualización dinámica se anuncia?
• ¿Es realmente necesario utilizar ARIA?

Antes de publicar

Antes de un lanzamiento importante, combina:

1. Análisis automático.
2. Navegación completa con teclado.
3. Pruebas con lector de pantalla.
4. Comprobación de contraste.
5. Revisión de formularios.
6. Pruebas con zoom y texto ampliado.
7. Evaluación de contenido dinámico.
8. Pruebas de los flujos críticos.

Esta revisión no debe limitarse a comprobar pantallas aisladas. Lo importante es confirmar que las tareas principales pueden completarse de principio a fin.

Cómo documentar una incidencia de accesibilidad

Una incidencia debe explicar el problema de manera reproducible.

Incluye:

• Página o pantalla afectada.
• Navegador y dispositivo.
• Tecnología de asistencia utilizada.
• Pasos para reproducirlo.
• Resultado actual.
• Resultado esperado.
• Componente afectado.
• Gravedad.
• Evidencias visuales o grabaciones.
• Recomendación de corrección.

Ejemplo de incidencia

El foco no entra en el modal de confirmación

Pasos para reproducirlo:

1. Navegar hasta el botón “Eliminar cuenta”.
2. Activarlo mediante Enter.
3. Pulsar Tab después de que se abra el modal.

Resultado actual: el foco continúa desplazándose por el contenido situado detrás del diálogo.

Resultado esperado: el foco debe entrar en el modal, permanecer dentro mientras esté abierto y regresar al botón “Eliminar cuenta” después de cerrarlo.

Una descripción de este tipo facilita la corrección y permite verificar posteriormente si el comportamiento se ha solucionado.

Errores frecuentes durante el testing de accesibilidad

Considerar suficiente una puntuación automática

Una puntuación alta no garantiza que la aplicación pueda utilizarse correctamente con teclado o lector de pantalla.

Probar únicamente la página de inicio

Los problemas más graves suelen aparecer en formularios, menús, filtros, ventanas modales y procesos con varios pasos.

Añadir ARIA sin comprender su comportamiento

Los atributos incorrectos pueden introducir información contradictoria y empeorar la experiencia.

Eliminar el indicador de foco

Ocultarlo por motivos estéticos impide que muchas personas sepan qué elemento está activo.

Comunicar información solo mediante color

Los errores, estados y resultados deben expresarse mediante más de una señal.

Revisar la accesibilidad al final

Las correcciones estructurales resultan más costosas cuando el diseño y los componentes ya están consolidados.

Checklist básica de testing de accesibilidad

Antes de publicar una funcionalidad, comprueba al menos lo siguiente:

• La página tiene un título descriptivo.
• Existe un h1 coherente.
• Los encabezados reflejan la estructura.
• Los controles utilizan elementos semánticos.
• Todos los elementos interactivos funcionan con teclado.
• El foco es visible.
• No existen trampas de teclado.
• Los botones y enlaces tienen nombres claros.
• Los formularios utilizan etiquetas asociadas.
• Los errores explican cómo resolver el problema.
• La información no depende únicamente del color.
• Las imágenes tienen alternativas adecuadas.
• La interfaz continúa siendo usable con zoom.
• Los modales gestionan correctamente el foco.
• Las actualizaciones dinámicas pueden percibirse.
• Se ha ejecutado una comprobación automática.
• Los recorridos principales se han probado manualmente.

Esta lista no sustituye una auditoría completa, pero proporciona una base útil para incorporar el a11y testing al trabajo habitual.

Preguntas frecuentes sobre testing de accesibilidad

¿Una aplicación es accesible si no presenta errores en Lighthouse o axe?

No necesariamente. Estas herramientas detectan determinadas incidencias automáticas, pero no pueden evaluar por completo la claridad del contenido, el orden lógico del foco, la navegación con teclado o la experiencia con un lector de pantalla.

El resultado automático debe considerarse un punto de partida.

¿Es necesario probar con un lector de pantalla?

Sí, al menos en los recorridos más importantes.

Una revisión básica permite detectar problemas relacionados con nombres accesibles, orden de lectura, estados, mensajes dinámicos y estructuras semánticas que no siempre son visibles al inspeccionar la interfaz.

¿Cuándo debería comenzar el testing de accesibilidad?

Desde las primeras decisiones de diseño y desarrollo.

Definir componentes accesibles, estados de foco, mensajes de error y patrones de navegación desde el inicio evita tener que realizar correcciones estructurales cuando el producto ya está avanzado.

La accesibilidad como parte de la calidad del producto

El testing de accesibilidad no debería entenderse como una comprobación secundaria que se realiza únicamente para cumplir un requisito.

Su finalidad es comprobar si las personas pueden utilizar una aplicación de manera autónoma, independientemente del dispositivo, la tecnología de asistencia o el método de interacción que necesiten.

Un formulario con mensajes claros beneficia a quien utiliza un lector de pantalla, pero también a quien está cansado o tiene prisa. Un foco visible ayuda a las personas que navegan con teclado y a quienes temporalmente no pueden utilizar un ratón. Una interfaz adaptable mejora la experiencia de quienes amplían el texto y de quienes trabajan en pantallas pequeñas.

Por eso, la accesibilidad forma parte de la calidad general del producto.

Las herramientas automáticas pueden indicar si existen determinados errores técnicos. Sin embargo, solo una estrategia que combine diseño inclusivo, HTML semántico, automatización, pruebas manuales y evaluación con tecnologías de asistencia permite responder a la pregunta más importante:

¿Puede utilizar esta aplicación quien necesita utilizarla?