La accesibilidad es más que una puntuación de Lighthouse

Introducción

Una puntuación alta de accesibilidad en Lighthouse puede resultar tranquilizadora. Un equipo ejecuta la auditoría, la página obtiene 100 y todas las comprobaciones que contribuyen a la puntuación aparecen en verde. En ese momento es fácil interpretar el resultado como una afirmación más amplia sobre el producto: el sitio es accesible.

Eso no es exactamente lo que dice el número.

Lighthouse es útil porque puede inspeccionar una página con rapidez y de forma consistente. Aplica un conjunto definido de comprobaciones automatizadas, identifica patrones conocidos que pueden crear barreras y puede volver a ejecutarse cada vez que cambia el producto. Para los equipos de desarrollo, esa capacidad de repetición es una de sus principales fortalezas.

La limitación está simplemente en el alcance. La puntuación refleja las auditorías de accesibilidad que Lighthouse puede evaluar automáticamente. Las auditorías manuales no contribuyen al número y Google deja claro que incluso una puntuación de 100 no garantiza que una página sea accesible.

Esta diferencia importa porque las pruebas automatizadas y la evaluación de accesibilidad no son lo mismo. Una herramienta puede inspeccionar código y patrones técnicos reconocibles. Una evaluación completa también tiene que considerar la secuencia, el contexto, el significado, la interacción y si las personas pueden utilizar realmente la experiencia como se espera.

Una puntuación de 100 en Lighthouse significa que la página superó las auditorías automatizadas de accesibilidad incluidas en esa puntuación. No significa que la página haya sido evaluada por completo desde el punto de vista de la accesibilidad.

En este artículo veremos qué representa realmente una puntuación de accesibilidad de Lighthouse, dónde resultan especialmente útiles las pruebas automatizadas, dónde comienzan sus límites y cómo es un proceso de evaluación de accesibilidad más completo.

Si quieres conocer los tipos de barreras que estos métodos buscan detectar, puedes comenzar por Los problemas de accesibilidad más comunes que encontramos en los sitios web.

Qué evalúa realmente Lighthouse

Lighthouse no mide la accesibilidad como un porcentaje de la experiencia completa.

Su puntuación se calcula a partir de un conjunto definido de auditorías automatizadas. Cada auditoría puntuada se supera o no, y esos resultados se combinan utilizando distintos pesos según el impacto estimado de cada una.

Por eso, una puntuación de 92 no debería interpretarse como “este sitio web es un 92 % accesible”. Significa que la página obtuvo un determinado resultado en las auditorías de accesibilidad de Lighthouse que eran aplicables y que forman parte de su modelo de puntuación.

Estas comprobaciones pueden analizar condiciones técnicas como si determinados elementos interactivos tienen un nombre accesible, si los atributos ARIA son válidos para sus roles, si algunas relaciones estructurales están expresadas correctamente o si ciertos problemas de contraste pueden detectarse mediante programación.

Lighthouse también incluye orientación para auditorías manuales en cuestiones que la automatización no puede resolver. Esas comprobaciones son útiles, pero no afectan a la puntuación numérica.

Por tanto, el número responde a una pregunta relativamente limitada:

¿Cómo se comportó esta página frente a las auditorías automatizadas de accesibilidad que Lighthouse puede puntuar?

No responde a una pregunta mucho más amplia:

¿Pueden las personas con diferentes discapacidades percibir, comprender, navegar y utilizar correctamente la experiencia?

No son enfoques que compitan entre sí. Una práctica madura de accesibilidad utiliza ambos.

En qué son buenas las herramientas automatizadas de accesibilidad

La automatización funciona especialmente bien cuando una condición puede definirse con suficiente claridad como para que el software la inspeccione de forma fiable.

Si una página contiene decenas de botones y algunos no tienen un nombre accesible, una herramienta puede detectar ese patrón más rápido que una persona revisando cada control manualmente. Si el mismo error de implementación aparece en cientos de páginas, un escaneo automatizado puede revelar su alcance. Si un cambio de código elimina una relación que antes era válida, una comprobación en CI puede detectar la regresión antes de que llegue a producción.

Ahí es donde las pruebas automatizadas de accesibilidad se ganan su lugar: son rápidas, repetibles, consistentes y pueden ejecutarse a una escala que sería poco práctica de reproducir manualmente.

Los equipos pueden utilizarlas durante el desarrollo, en pull requests, dentro de procesos de integración continua, después de modificar componentes o para revisar grandes conjuntos de páginas. W3C también señala que las herramientas de evaluación pueden ahorrar tiempo, ayudar a identificar posibles barreras y apoyar distintos roles a lo largo del diseño y el desarrollo.

La cuestión importante no es que la automatización sea débil. Es que algunas preguntas de accesibilidad no pueden expresarse de forma fiable como reglas automatizadas.

Las herramientas automatizadas son valiosas porque pueden inspeccionar condiciones técnicas definidas con rapidez y consistencia, pero su campo de análisis es necesariamente limitado.

Lo que las herramientas automatizadas no pueden comprender

El límite se vuelve más claro cuando la pregunta deja de ser si algo existe o cumple una regla técnica y pasa a ser si tiene sentido dentro de su contexto.

Texto alternativo significativo

Un escáner puede identificar una imagen sin atributo alt y señalar algunas alternativas claramente sospechosas. Lo que no puede decidir de forma fiable en todos los casos es si la descripción comunica lo que realmente importa sobre esa imagen dentro de su contexto específico.

Una fotografía utilizada de manera decorativa puede no necesitar ninguna descripción hablada. La misma fotografía, dentro de un artículo sobre detalles arquitectónicos, puede requerir una descripción significativa. Un gráfico quizá necesite comunicar sus datos, no una enumeración literal de formas y colores.

La presencia técnica de un texto alternativo es solo una parte de la cuestión. Su utilidad depende de por qué está ahí la imagen.

Orden de lectura lógico

El software puede inspeccionar el DOM, la semántica y el árbol de accesibilidad, pero una experiencia puede seguir resultando confusa cuando el orden en que se presenta la información deja de reflejar la secuencia prevista.

Los diseños modernos suelen reorganizar contenido entre distintos breakpoints. Los componentes se expanden y contraen, aparecen modales y puede insertarse contenido de forma dinámica. En esos casos, para comprender si la secuencia resulta coherente puede ser necesario recorrer realmente la interfaz como lo haría una persona.

Lenguaje comprensible

Un campo puede tener una etiqueta técnicamente correcta y aun así dejar dudas sobre qué información se espera. Un mensaje de error puede estar correctamente asociado con un campo y, sin embargo, no explicar cómo resolver el problema. Las instrucciones pueden cumplir los requisitos estructurales y continuar siendo innecesariamente difíciles de seguir.

El software puede analizar ciertas características lingüísticas, pero no puede determinar de forma fiable si un mensaje es suficientemente claro para su público.

Comportamiento lógico del foco

Una prueba automatizada puede determinar que un elemento puede recibir el foco. Eso dice muy poco sobre si el foco se desplaza al lugar correcto después de una interacción.

Cuando se cierra un modal, ¿vuelve el foco al control que lo abrió? Cuando aparece contenido nuevo, ¿la persona entiende dónde se encuentra? Si alguien recorre una interfaz compleja con Tab, ¿la secuencia sigue la lógica de la tarea o salta de forma impredecible entre controles sin relación?

Estas preguntas tienen que ver con el comportamiento a lo largo del tiempo, no solo con la existencia de un elemento que pueda recibir foco.

Contexto

Muchas decisiones de accesibilidad dependen de las relaciones entre los elementos.

Un enlace llamado “Saber más” puede resultar comprensible dentro de un párrafo y ser ambiguo cuando se repite en una cuadrícula de tarjetas. Un botón puede tener un nombre accesible técnicamente válido y aun así resultar confuso dentro de la tarea. Un encabezado puede existir semánticamente pero no describir correctamente la sección que introduce.

El contexto cambia lo que significa que algo sea “correcto”.

Calidad de la interacción

Quizá esta sea la diferencia más amplia.

Las herramientas no se desorientan cuando el foco se mueve de forma inesperada. No tienen dificultades para interpretar un flujo de autenticación complicado. No necesitan recordar información mostrada tres pasos antes ni decidir si un proceso exige un esfuerzo innecesario.

Por eso, un producto puede superar muchas comprobaciones técnicas y seguir creando barreras importantes durante el uso.

Aquí es donde la accesibilidad empieza a solaparse con la usabilidad y la experiencia de usuario. Como vimos en Accesibilidad, usabilidad y experiencia de usuario: ¿cuál es la diferencia?, cumplir requisitos técnicos y ofrecer una buena experiencia son objetivos relacionados, pero no intercambiables.

Superar las pruebas automatizadas no significa cumplir WCAG

Muchas auditorías de accesibilidad de Lighthouse están directamente relacionadas con aspectos cubiertos por WCAG. Superarlas aporta información útil, pero no demuestra conformidad con WCAG.

En WCAG explicado sin jerga técnica, describimos los criterios de conformidad como requisitos verificables. La distinción importante es que verificable no significa automáticamente verificable.

Algunos requisitos pueden evaluarse en gran medida mediante software. Otros dependen del criterio humano, y muchos necesitan una combinación de ambos. W3C es claro al respecto: las herramientas de evaluación pueden apoyar una revisión de accesibilidad, pero ninguna herramienta por sí sola puede determinar si un sitio cumple los estándares de accesibilidad.

La conformidad también implica algo más que obtener un informe limpio. Importa el alcance de la evaluación, los criterios de conformidad aplicables, el nivel de conformidad que se declara y si esos requisitos se cumplen en todo el contenido incluido en el alcance.

Esta diferencia cobra especial importancia cuando un informe de Lighthouse se presenta a responsables o clientes como evidencia de cumplimiento. Puede apoyar una revisión de accesibilidad, pero no constituye por sí solo una auditoría de accesibilidad ni un informe de conformidad con WCAG.

La accesibilidad requiere distintos tipos de pruebas

Un proceso más sólido no sustituye la automatización por un único método alternativo. Combina varias formas de evaluación porque cada una permite descubrir algo diferente.

Pruebas automatizadas

Las comprobaciones automatizadas son ideales para condiciones técnicas repetibles. Pueden identificar problemas comunes detectables, revisar muchas páginas con rapidez, encontrar regresiones y ofrecer feedback inmediato durante el desarrollo.

Esta es la capa que debería ejecutarse con frecuencia. Los problemas evidentes que una máquina puede detectar no deberían esperar a que una persona especialista los encuentre manualmente.

Inspección manual

La revisión manual añade interpretación.

Una persona con experiencia puede evaluar si los encabezados representan la estructura real del contenido, si los textos alternativos son significativos, si las etiquetas e instrucciones proporcionan suficiente información, si los cambios responsive conservan el contenido y si la página sigue teniendo sentido como una experiencia coherente.

También es el momento en que las advertencias de las herramientas automatizadas pueden investigarse dentro de su contexto en lugar de aceptarse o descartarse sin más.

Pruebas con teclado

Utilizar la interfaz sin ratón revela comportamientos que una inspección estática puede pasar por alto fácilmente.

¿Se puede llegar a todos los controles interactivos? ¿El indicador de foco es visible? ¿El foco avanza en un orden lógico? ¿Es posible entrar y salir de componentes complejos? ¿Funcionan los menús, diálogos y controles personalizados sin utilizar un dispositivo apuntador?

Las comprobaciones preliminares de accesibilidad de W3C incluyen precisamente este tipo de cuestiones porque requieren interacción real con la página.

Pruebas con tecnologías de asistencia

Las pruebas con tecnologías de asistencia analizan cómo se expone la implementación a través de las herramientas que las personas utilizan para acceder a productos digitales.

Dependiendo del producto y del alcance de la revisión, esto puede incluir lectores de pantalla, ampliación de pantalla, entrada por voz u otros métodos de interacción.

El objetivo no es simplemente confirmar que un lector de pantalla anuncia algo. La pregunta más útil es si los roles, nombres, estados, relaciones, navegación y cambios de la interfaz se comunican de una forma que permita utilizar realmente el producto.

Pruebas con usuarios

Las personas con discapacidad pueden revelar barreras que ni una herramienta automatizada ni una revisión experta muestran de la misma manera.

Aportan sus propias estrategias, expectativas, tecnologías de asistencia y formas de completar tareas. Observar esas interacciones puede descubrir fricciones que el equipo del producto ni siquiera sabía que debía buscar.

Las pruebas con usuarios también tienen límites. Un número reducido de participantes no puede representar todas las discapacidades, tecnologías, contextos o estrategias de interacción. Por eso W3C recomienda combinar la participación de usuarios con evaluaciones basadas en estándares, en lugar de tratar una como sustituto de la otra.

La evaluación de accesibilidad se vuelve más completa cuando las comprobaciones automatizadas se combinan con inspección manual, pruebas de interacción, tecnologías de asistencia y experiencia real de usuarios.

Utiliza la automatización como red de seguridad, no como veredicto

El papel más sólido de las pruebas automatizadas de accesibilidad no está al final de un proyecto, cuando alguien busca un número que confirme que el trabajo está terminado. Está a lo largo de todo el ciclo de vida del producto.

Ejecuta comprobaciones automatizadas mientras se construyen los componentes. Ejecútalas cuando cambia el código y antes de desplegar. Úsalas para evitar que regresen problemas conocidos y para revisar a una escala que sería poco práctica manualmente.

Después, dedica el tiempo que la automatización ahorra a las preguntas que esta no puede responder.

Esta es también la razón por la que la accesibilidad debería formar parte del diseño web desde el primer día. Las pruebas funcionan mejor cuando forman parte de una práctica de accesibilidad más amplia, que comienza con las decisiones de diseño y continúa durante la implementación, el contenido, el control de calidad y el uso real.

Una auditoría de accesibilidad seria debería dejar clara su metodología. Debería distinguir los hallazgos producidos automáticamente de los identificados mediante revisión manual, explicar qué se probó con teclado y tecnologías de asistencia, definir el alcance de la evaluación y ser explícita sobre lo que no se probó.

Ese nivel de transparencia resulta mucho más útil que una sola puntuación.

El objetivo no es sustituir Lighthouse. Es colocar Lighthouse en el lugar que le corresponde: una capa valiosa dentro de una práctica de accesibilidad mucho más amplia.

Una puntuación puede decirte qué encontró una herramienta. Una evaluación de accesibilidad adecuada tiene que responder algo más importante: si las personas pueden utilizar realmente el producto.