Si nunca corriste un test de accesibilidad en tu sitio, es muy probable que la primera vez te encuentres con cientos de errores acumulados. Aprender a prevenir, automatizar y priorizar arreglos de accesibilidad web es la forma más realista de mantener un producto inclusivo sin frenar tu empresa.

¿Por qué la accesibilidad debe estar desde el inicio del proyecto?

La accesibilidad no es una capa que se agrega al final. Tiene que vivir en cada etapa: investigación, wireframes, diseño, contenido y desarrollo.

En diseño, antes de implementar, conviene revisar:

• Si los contrastes elegidos cumplen con los estándares.
• Si la tipografía es legible o conviene cambiarla.
• Si la jerarquía de títulos, párrafos y bloques de texto está bien organizada.

Y no alcanza con hacerlo bien al comienzo. La accesibilidad tiene que sostenerse en el tiempo, y la mejor forma de lograrlo es automatizando.

¿Cuándo se debe pensar en la accesibilidad de un sitio? Desde el primer día del proyecto, en investigación, diseño, contenido y desarrollo. No al final.

¿Cómo automatizar tests de accesibilidad en tu pipeline?

La automatización te ahorra revisar a mano lo que una herramienta puede revisar por vos. Si todavía no tenés unit tests en tus componentes, podés sumarlos de a poco con Jest, Axe Core y React Testing Library.

Después, en los pipelines de despliegue, podés agregar chequeos automáticos con Axe o Lighthouse y definir un mínimo de conformidad para evitar que llegue a producción algo que no lo cumpla. No tenés que apuntar al 100 sobre 100 de Lighthouse: definí un umbral que puedas sostener, sea 70, 80 o 90.

¿Por qué los tests automáticos no alcanzan?

Porque hay cosas que solo se detectan con ojo humano. Por ejemplo, si rompiste el texto alternativo de una imagen, una máquina puede no notarlo, pero una revisión manual sí.

La frecuencia de los tests manuales depende del ritmo de tus lanzamientos. Si publicás cada tres meses, conviene chequear regresión en cada release y revisar también las nuevas features. Si el trabajo es mucho, dividí las páginas entre los miembros del equipo: vos revisás dos, tu compañero revisa otras dos.

¿Qué hacer cuando ya tenés cientos de errores acumulados?

Acá entra el caso de estudio de una empresa a la que llamaremos Mabel. Llevaba años funcionando sin haber corrido nunca un test de accesibilidad, y al hacerlo aparecieron alrededor de 200 errores. Frenar todo para arreglarlos es utópico, así que hay que actuar en dos pasos.

¿Cómo armar un backlog de accesibilidad útil?

El primer paso es agregar cada error como ticket al backlog. Sí, existe la sensación de que mandar algo al backlog es enterrarlo, como en ese meme de Star Wars donde el junior pregunta "pero lo vamos a hacer, ¿no?".

La realidad es otra: no se puede arreglar lo que no se sabe que existe. Exteriorizar el problema en un ticket hace que diseñadores, project managers y otros developers se enteren y compartan la responsabilidad. No implica arreglarlo mañana, pero sí que el equipo entero sepa y empiece a moverse.

¿Cómo priorizar qué error de accesibilidad arreglar primero?

La regla simple: mayor impacto y menor esfuerzo primero. Si olvidaste cambiar el color de un texto y eso hace fallar el contraste en 50 lugares, pero se arregla con una línea de código, ese ticket va al tope.

Después mezclá la prioridad así:

• Alto impacto y alto esfuerzo: agarrá uno de vez en cuando para avanzar con lo complejo.
• Bajo impacto y bajo esfuerzo: ideal para tardes de viernes relajadas.
• Bajo impacto y alto esfuerzo: el rectángulo de la tristeza. Reconsiderá si vale la pena tocarlo o dejalo descansar en el backlog para siempre.

¿Qué errores de accesibilidad son de alto impacto? Los que impiden navegar el sitio, como falta de foco al usar teclado o aria-labels mal aplicados que hacen que un lector de pantalla repita lo mismo en todos los links.

¿Cómo medir el impacto y el esfuerzo de cada arreglo?

Para medir impacto, usá sentido común y pruebas reales. Navegá el sitio solo con teclado: si no ves el foco, es alto impacto. Probá un lector de pantalla: si todos los links del menú dicen lo mismo porque el aria-label se usó mal, también es alto impacto.

En cambio, un contraste doble A en el @copyright 2022 del pie de página, cuando debería ser triple A, es bajo impacto. Falla, pero pasa.

El esfuerzo es más difícil de estimar desde afuera, porque depende del código y de la deuda técnica acumulada. Solo vos, que conocés tu codebase y tu repositorio de GitHub, podés saber si cambiar un color de fondo es una línea o implica reestructurar medio sitio.

Por eso conviene construir accesibilidad desde cero siempre que sea posible: evita despertarte un día con 200 tickets nuevos en la cara.

¿En qué punto está hoy la accesibilidad de tu proyecto y cuál sería el primer ticket que mandarías al backlog? Contame en los comentarios.